GML Centering a room in a view larger than the room? [SOLVED]

JadeMonsuta

Member
Yes I'm aware that it's not the best thing to have a view larger than a room, I've given my game a dynamic aspect ratio horizontally as means of better displaying the art created for it without distortion. It works properly so long as the room's width is equal to or greater than the width of the window, the smallest room would be 320 pixels wide and the largest window would be 640 pixels wide.

Pretext aside, I'm struggling to draw the room in the center of the screen, because for some reason it's aligned to the right of the screen.



While experimenting with it, I came across several interesting visual bugs.



Here it is drawing the game in all of the wrong places.

For some reason it's drawing the game multiple times, one correctly on the far left, then to the right of that a very glitchy display that flickers and only updates the frame it displays every few seconds. Then after that, a display of the game with the shaders applied twice, and to the right of that, the game without shaders.

Here is the code that handles the post processing, it's a script in a draw_gui event for the player:
Hastebin
Here's the code that handles the aspect ratio and the offset the room should be displayed at, it's in a begin step event in its own object:
Hastebin

The only possible "fixes" for this that I know how to program on my own are:
-Extending every room to meet the maximum size for the horizontal aspect ratio
-Limiting the maximum horizontal size
-Stretching the entire game to fit if the room is smaller than the view


Help would be greatly appreciated! I nearly came here for help on the aspect ratio code itself, but I was able to figure it out, but this has me completely stumped.

For anyone that comes across this post looking for code for a dynamic aspect ratio, feel free to use my code (even if it is kinda buggy, hence the existence of this thread), I think more games need this feature.
 
C

Catastrophe

Guest
The only thing that comes to mind is maybe you need to correct the view_xport/yport/wport/hport variables, but I haven't messed with code nearly this comvoluted xD I would also comment out bits of the code to see if you can find the culprit, like turn off all the shaders first. e.g. Everything seems right, but then again I've also never resized the application_surface to be larger than the room

That said I guess I'm just at a loss as to the point of this, or is it just curiosity? Why can't you just make the room bigger as your initial workaround? Seems simple enough.
 
Last edited by a moderator:

Yal

🐧 *penguin noises*
GMC Elder
I second the "make rooms bigger" workaround, there's essentially no performance loss from making the rooms bigger and you've got much better control over what ends up in the void that way.
 

JadeMonsuta

Member
The only reason I'm hesitant on making rooms bigger is because having a room only take up a single screen works better stylistically in some scenarios i.e in houses.
I could just lock the camera though so...
 

Yal

🐧 *penguin noises*
GMC Elder
The only reason I'm hesitant on making rooms bigger is because having a room only take up a single screen works better stylistically in some scenarios i.e in houses.
I could just lock the camera though so...
You could fill the area outside the view with black tiles or somesuch, and then you'd get the same effect...?

Also, does rooms that are exactly 1 view big work properly or do they need to be larger than the view?
 

JadeMonsuta

Member
Also, does rooms that are exactly 1 view big work properly or do they need to be larger than the view?
Rooms that are as wide as the view work fine, it only gives an unintended effect when the view is larger than the room.
 

Yal

🐧 *penguin noises*
GMC Elder
Rooms that are as wide as the view work fine, it only gives an unintended effect when the view is larger than the room.
I see~

My educated guess is that the glitches are a mix of...
  • the view-motion code trying to limit the view from leaving the room, which fails since clamping one side to the room will make the other go outside the boundaries, which could cause a back-and-forth every every step
  • automatic drawing for space outside the room not being clearly defined (which could mess up things like the after effects)
  • "clear the room to the background color" being turned off, so anything that is drawn outside the room will linger there indefinitely unless you draw something else on top, which together with the back-and-forth issues when the view code tries to clamp it could lead to those weird frames that don't update as often as the others.

Since the view code works for rooms that are at least 1 view big, I'd guess the easiest solution is to just never have rooms that are smaller than the view, and fill the empty space with whatever tiles fits the rest of the level. (E.g. if you want a small connection room that doesn't use all the space, you could have the sides fade into black with a nice rounded fade).
upload_2019-11-6_23-32-26.png

You could try just enabling clearing the room with a color before starting normal drawing (or manually clear the drawing by drawing a rectangle covering the view background), to see if that helps, but I'm pretty sure you'd just see the view bounce around like a bunny that's had too much caffeine rather than getting multiple copies.
 

JadeMonsuta

Member
Clear display buffer is enabled, which is strange...
I guess now the question is if I could make the rooms larger with just code, or if I'd need to go in and edit them manually
 

JadeMonsuta

Member
It just came to me like some sort of eureka moment last night.

The room is on the right side of the screen, right?

Expanding the room width adds empty space to the right of the screen, right?

So my hypotheses is:
I'll expand the room width dynamically using code to push the room to the center of the screen, and use some sort of percentage calculations to draw black bars around the area.

I'll post my results either later today or tomorrow.
 

Yal

🐧 *penguin noises*
GMC Elder
Clear display buffer is enabled, which is strange...
I guess now the question is if I could make the rooms larger with just code, or if I'd need to go in and edit them manually
The code solution is pretty trivial, you should be able to do this in e.g. the player's create event...
Code:
room_width = max(room_width,horizontal_view_size_youre_using)
 

JadeMonsuta

Member
How did I not see this until now???
I tried using room_set_width and that didn't work properly, but this works properly (though I made a different formula that just centers the room)

Code:
if room_width < global.gamewidth
{
room_width = roomsize + (global.gamewidth - roomsize) / 2;
}
You're a lifesaver, thank you!

I guess that marks this case of 'I can't code' as solved.
 

Yal

🐧 *penguin noises*
GMC Elder
room_set_width() has no effect on the currently loaded room data (since it's copied from the resource database to the active room memory and room_set_width only updates the database blob for the room), but will affect future visits and any other reads from its data. The manual currently says it can't be used on the current room, it used to say that you shouldn't use it on the current room because it had unpredictable results. Seems like you can use it just fine even in GMS2, just with the "random stuff that nobody can explain happens" caveat, which is why you shouldn't use it on the current room :p
upload_2019-11-9_17-41-38.png


Speaking of weird behavior, I saw another topic yesterday where someone brought up that the "clear display buffer" setting being bugged, which would explain why it had no effect for you.
 
Top