GMS 2 Room Transition Effects

Binsk

Member
If you want smooth room transition effects in your game, look no further. This extension provides you with all you need to get going quickly as well as for designing your own transitions with ease!

Purchase

You can purchase the extension at any one of the following sites:

GameMaker Marketplace [$1.99]
Upset Baby Games [$0.99 crypto only]
Itch.IO Store [$1.00]

Initial Setup

There is none! Simply call room_goto_transition to switch rooms while using a transition effect. The function takes an enum value from ROOM_TRANSITION to specify which transition you would like to use, the length of transition in seconds, and whether or not the room you are entering should freeze for the length of the transition or not.

Features

This extension is made to be as simple to use as possible but feature rich as well. Here are some highlights:
  • Over 40 transitions included out of the box
  • Instance freezing can make the game wait for the transition. Handles deactivated instances and physics objects perfectly fine.
  • Adding your own transitions is a piece of cake. Your transition code is automatically provided with a snapshot of each room, a surface to render to, and the percentage through the transition.
  • System handles difficult situations with ease. If you change screen sizes between rooms or even don't use the application surface, the system can still function just fine.
  • No setup required! Just pop in the extension and call the room_goto_transition function out-of-the-box!
  • Transitions are handled in realtime not game time. Lag, or changing FPS mid-way through your project doesn't alter the transitions at all.
Platform Support / Resources

This system is programmed in native GML with all systems in mind. It has not been tested on mobile or browser exports at this time, however.

Development

Is there something here you need or want? Came a cross a bug? Let me know! I actively maintain all my extensions for the lifetime of the product they are targeted for.

Video

Take a look at the built-in transition effects. Also, I was obviously bored when making this video.

 
Last edited:

Binsk

Member
Just a small bump to say that it is now listed on GameMaker's store as well. It seems they fixed whatever issue was going on.
 

Binsk

Member
Small update today addresses a bug that rendered semi-transparent objects oddly during the transition.
 

Binsk

Member
Another small update, this one just for the heck of it.

Added 7 new built-in transition effects (remember, you can still add your own if I'm missing one!):
  1. Fade-to-black, fades to black between rooms (requested by a customer)
  2. Page flip (left / right), simulates a simple page flipping effect
  3. Spin (left / right), spins the screen and smoothly transitions during the spin
  4. Drops, spawns a number of circles that expand and flood the screen with the new room
  5. Pixelate, pixelates the screen between rooms
 

Binsk

Member
I adjusted it to work through the compatability scripts a couple updates ago. Should work fine for 2.3.
 

kburkhart84

Firehammer Games
Got it! Paid $5 in itch since it seemed worth it. It is working as advertised in my project as well.

I have some suggestions.

With 2.3, you can move assets anywhere you would like. In my stuff, I put everything into better organized folders, all under the FHGames folder. This keeps these things together and doesn't get in the way when you import the package. You also might find it better to have the "internal" transitions be in a single script file, but since they can be modified by the user as well, that's up to you. If you follow my below suggestion though, they would need to be put in a single file. You can region them off if you want to for organization.

Also, see this code..
Code:
// Due to GMS2.3 changes we needed to switch from script IDs to 'method' structures. This now requires
    // we manually switch for each script:
    switch (argument[1]){
        case ROOM_TRANSITION.fade_to_black:
            ubg_transition_obj.target_effect = ubg_transition_fade_to_black;
        break;
If you take a look at my fhEase code, it is very similar to yours, doing a different function based on the argument. Instead of enums, I used macros, but it works exactly the same. The way I handled it(to avoid that massive switch/case() was to declare the functions as methods, but have it be a global array of methods. Then, you can use the enum to index the array.
Code:
#macro FHMAXEASE_ELASTICIN 28
#macro FHMAXEASE_ELASTICOUT 29
#macro FHMAXEASE_ELASTICINOUT 30
#endregion
__fhEaseFunctions[FHMAXEASE_LINEAR] = function(time, start, change)
{
    return (change * time) + start;
}
Code:
if(equation < 0 || equation > FHMAXEASE_ELASTICINOUT)
        throw("Attempted to call fhMaxEase with an invalid equation argument");
    var func = global.__fhEaseFunctions[equation];
    return func(amount, startvalue, endvalue - startvalue);
If you want me to elaborate more on this, feel free to ask.
 

Binsk

Member
Got it! Paid $5 in itch since it seemed worth it. It is working as advertised in my project as well.

I have some suggestions.

With 2.3, you can move assets anywhere you would like. In my stuff, I put everything into better organized folders, all under the FHGames folder. This keeps these things together and doesn't get in the way when you import the package. You also might find it better to have the "internal" transitions be in a single script file, but since they can be modified by the user as well, that's up to you. If you follow my below suggestion though, they would need to be put in a single file. You can region them off if you want to for organization.

Also, see this code..
Code:
// Due to GMS2.3 changes we needed to switch from script IDs to 'method' structures. This now requires
    // we manually switch for each script:
    switch (argument[1]){
        case ROOM_TRANSITION.fade_to_black:
            ubg_transition_obj.target_effect = ubg_transition_fade_to_black;
        break;
If you take a look at my fhEase code, it is very similar to yours, doing a different function based on the argument. Instead of enums, I used macros, but it works exactly the same. The way I handled it(to avoid that massive switch/case() was to declare the functions as methods, but have it be a global array of methods. Then, you can use the enum to index the array.
Code:
#macro FHMAXEASE_ELASTICIN 28
#macro FHMAXEASE_ELASTICOUT 29
#macro FHMAXEASE_ELASTICINOUT 30
#endregion
__fhEaseFunctions[FHMAXEASE_LINEAR] = function(time, start, change)
{
    return (change * time) + start;
}
Code:
if(equation < 0 || equation > FHMAXEASE_ELASTICINOUT)
        throw("Attempted to call fhMaxEase with an invalid equation argument");
    var func = global.__fhEaseFunctions[equation];
    return func(amount, startvalue, endvalue - startvalue);
If you want me to elaborate more on this, feel free to ask.
I appreciate the generosity, so thank you! Glad to hear it is doing its job.

In terms of your suggestions, I really want to attempt keeping backwards-compatibility with 2.2 as well as existing customers' code, thus why there are some of the weird design decisions like the enums.

I find enums cleaner when usable and I initially had them assigned directly to script IDs but 2.3 broke that and brought about the switch statement, for example. There were a number of ways to solve the problem and the switch works fine. Regardless as to whether I used a switch, an array, or something else I would still require a long manually-entered structure of index-to-script pairs, and as it is only seeked once at the beginning of the transition it isn't a performance concern using a switch.

Thanks for the good ideas, though.
 

kburkhart84

Firehammer Games
When I was doing the similar thing in my easing thing, I was originally using script_execute() to avoid the switch statement. When I upgraded to 2.3, I set it up using the array of methods. But then they broke nesting the array with function call thing so I had to assign the method from the array to a blank variable for a time. Then they fixed it so I put it back. Backward compatibility is something worth keeping around for some people. I recently upgraded my input system and chose to avoid that. In the process, I took advantage of some new 2.3 features, which makes it easier to add more features, etc... for me personally, it is worth ditching the compatibility, but I know that isn't the case for everybody.
 
Top