Legacy GM Ports (view_wport and view_hport) are broken, don't affect aspect ratio or resolution at all

[Mr. Unp3rf3ct]

So as my title suggests I'm experiencing issues with view_wport and view_hport which I have never experienced before.

I've used GMS 1.X for a few thousand hours across the last years and when writing a framework for handling scaling today I found this issue. For performance reasons I've disabled the application surface and thus disabled the built in "keep aspect ratio" setting in global game settings. So far nothing new for me, this is expected behaviour. However what isn't expected is the following (project download here):



On the left the application surface is enabled. It's the same dimensions as the rooms configured viewport and handles aspect ratio and resolution.

On the right however the surface is disabled. The viewport is set to the same settings as before but is completely bypassed in rendering somehow. Neither the resolution nor the aspect ratio respect it, the resolution is tied to the the window sizes height if the window is wider than the view and the window's width if its taller. For all I know in the right pic the ports targeted aspect ratio could be set to be super slim and tall and it just wouldn't care. Nothing changes when changing it on the fly too.
Also as the text states it shouldn't be readable in the right picture as the resolution is set to 128x128 pixels but is being output at 512x512 stretched to 512x700.

Expected behaviour would be that the resolution is dictated by the viewport size and because the port coordinates are set to 0 a square featuring the view contents should appear in the top right corner, unstretched with a black bar on the right.
The positioning would then of course be done using some basic maths to place it in the middle of the viewport. This is not possible as when the ports size is set to 10 for example the x coordinate 5 still represents the middle of the screen, however resolution isnt tied to it so the whole view is still at a crazy high resolution.

Effectively this ruins any performance gains from disabling the application surface as the resolution on a 4k or higher for example display would be uncapped instead of sticking to the port. Also letterboxed scaling is impossible to achieve. (Letterboxing was ment for a small 8 bit style minigame in a different game, but now it just stretched to fill the entire screen).

I've also toyed around with the gui size, but it doesnt affect anything either.

The thing is in this thread: "Keep Aspect Ratio" GGS and Disabled Application Surface

[SOLVED] "Keep Aspect Ratio" GGS and Disabled Application Surface

It appears the Global Game Setting for the game to keep its aspect ratio is ignored when the application_surface is disabled. So it stretches either way. But I need the application_surface disabled to help Android performance. According to the FAQ Are you stopping support for Studio 1.X...

forum.yoyogames.com

Everything behaves as expected (Marked as solved, Working according to poster)

As this is a thread focused on Android I set up the export to android and it didn't work on there either. YYC didn't affect anything either on any platform.

I would love to try and go back to the current GMS version at the time of the post being made, but I don't want to provoke glitches stemming from downgrading. I've been using the last version before sunset for this, but everything is tested on sunset as well and behaves the exact same way.

Does anyone know what I could be missing or how I could fix this? On windows I can adapt the window size to fix this, however on Android and in fullscreen I cant do that and turning on the application surface again is a not a viable solution.
Many thanks in advance, I'll do my best to respond when I'm awake and try everything viable.

 

[RangerX]

What is your:
- Room size
- View size
- Port size
- Monitor resolution
- Texture page size

Then I will be able to tell you what's wrong.

 

[Mr. Unp3rf3ct]

What is your:
- Room size
- View size
- Port size
- Monitor resolution
- Texture page size

Then I will be able to tell you what's wrong.

The room is 224 by however long the level is (over 288)
with a view of 224x256 (doesn't perfectly scale to 1080p, hence the port for letterboxing) or alternatively 216x288 for better scaling to 1080p (no upper and lower letterbox).
For testing the port scales up to 1080p in fullscreen so 1080 by 1234 displayed on a 1080 by 1920 monitor.
The texture page is set to 2048x2048.

Edit:
The ports x is at 343 so in my understanding it should be centered. These are the values for the actual project and not the example from above.

So basically a non integer scaled NTSC NES resolution if im not mistaking (I'm aware sub pixel movement would be visible with this setup)

Thank you for responding.

 

[Mr. Unp3rf3ct]

In the meantime I did some testing.
I went back to the version from the post I mentioned and I have the same result. I don't see how the accepted solution could ever have worked with a one view setup, the bounding box of all views is stretched to fill the screen buffer, but not only that it also adjusts the port resolution to the buffer (I don't know why, couldn't figure this one out).

One possible solution is to activate the app surface again

Another one is to affect the bounding box by rendering with the same aspect ratio as the window/screen in fullscreen and then rendering the actual contents with a higher view on top with the right positioning but still the resolution issue.

From this second solution a better version would be to render a singular view with adjusted aspect ratio to render only once. All calculations for checking if something was in view would have to be done with another variable then. Finally black bars could be drawn in the GUI or similar.

All these solutions aren't perfect. Obviously the first one requires the app surface and the third one has the issue with loosing control about the render resolution. I've had issues with surfaces on simulated larger resolutions, but they can be used to limit resolution, unlike the the third approach. Ill have to benchmark which solution gives the better performance at which resolution and write code to switch between the behaviours accordingly unless someone can suggest a better solution.