Viewport and Resolution Question

Coded Games

Theoretically, a view that is 1080p drawn to a 1080p window should take the exact same amount of time to render as a 1080p view downscaled to a 720p window? Because window size doesn't matter, view size is what determine what all needs to be drawn. Does this sound correct?

So me creating video options to downscale a large view to a smaller winder shouldn't improve performance.


Firehammer Games
It might take just slightly longer to render the downscaled version actually. The reason is because at the full scale, you are rendering only the 1080p stuff...but scaled down, you have the same render, plus the additional step. In reality it is likely to make little difference, but technically, there you go.

If you actually were trying to get better performance, you would need to go a different route.


šŸ§ *penguin noises*
GMC Elder
In my understanding, what happens is that you render to the 1920x1080 application surface, and then that is rendered to the screen whatever the window size is. The only potential source of slowdown would be if a downsized app surface gets drawn with interpolation to figure out what to use when there's more than one surface pixel occupying that screen pixel, but you will render fewer window pixels in total so it should even out in the end, and disabling texture interpolation at the end of the draw event (so the app surface gets drawn with it disabled) should disable this anyway? (At least if you manually draw it in the Post Draw event, with application_surface_draw_enable turned off)


Yeah application surface matters. For the various sizes, starting from the beginning of the pipe... Room size does not matter at all. View size (and position) matters in grabbing part of the room to be displayed, so can scale stuff by deciding how much is visible. Application surface size is the base approximation scale of room content. If your view versus app surface size is not identical, the positions and scales of sprites get multiplied by the difference before drawn to app surface. Meaning, if view and app surface are 1:1 then no scaling whatsoever happens. (Room coordinate positions will be rounded to app surface pixel positions; this doesn't matter if view is 1:1 but will matter if you're upscaling fractional positions.) Setting a small view and large app surface is how pixel art is typically upscaled with GMS2. The fullscreen display or window then receives the app surface. I don't know if the automated draw process will stretch to fit as I've been running my display system with application_surface_draw_enable turned off and draw it myself, which will not stretch unless I tell it to. Then there's also the view port stuff, which I've never used but can be used to assign only a portion of the fullscreen or window to receive the app surface content.

(Aside: those using view to app surface upscaling technique should take note of the above. If your coordinates are not integers all the time, it can create partial sprite overlap that collision functions will not detect. This is because collisions happen in room space and get rounded before collisions are checked. But drawing will happen in app surface space using multiplied coordinates rounded after multiplication. So if your coordinate value is 3.4 collisions for that instance are checked at 3.0. And if your upscale is 5 it gets drawn to coordinate value 3.4 * 5 = 17, not 15 where the collision was checked. This would be avoided if collision commands worked with fractions, but they don't.)