Scaling modes

[skejeton]

Currently how window screen is scaled is it fits the game screen into the window while preserving aspect ratio. This works for most games and if you don't want black bars you can always set the screen size to window size and handle that manually, however for out of box experience it may also be nice to have integer-only scaling mode: Here's an example of how this looks:

Here you can see pixels are scaled by integer and preserving the aspect ratio.

Making a window smaller on the width made the entire game resize to fit the screen too, while preserving aspect ratio and pixel integrity.

This is obviously very useful for pixel art games. In my opinion there should be scaling flags like KEEP_ASPECT_RATIO and KEEP_PIXEL_INTEGRITY or something similar which you can combine. Currently windows created right now have KEEP_ASPECT_RATIO set, removing that will just stretch the contents of the window, it's usually not a desirable effect, but nonetheless may be needed for some.

The way this can be implemented is by calculating the bounding box out of these properties, or even simpler, without the properties allow the user to specify where the bounding box will go themselves, so they can have their own scaling/positioning modes. This can also be addressed with #99

Related: #63

[marekmaskarinec]

I agree with these changes. This is how I propose they would be implemented:

• remove the need to pass the camera to window.cycle
• add window.setViewport. This function would take a vf2 with dimension of the game viewport. If is desirable for this function to be callable multiple times during the cycle, which would allow simple scaling for the user (you could render the hud with some viewport dimensions and game with another ones).
• add window.setOffset. This would take a vf2 and (probably in window coordinates) and change thg.offset
• add window.setScalingFlags. This could take a bit field with your proposed flags and maybe others if we think of anything useful.
• maybe add window.shiftViewport. This would shift all coordinates, but I think the solution from #99 is more desirable.

With this I hope we could remove "camera" from tophat altogether and stop the coordinate conversion hell.

[skejeton]

I completely agree with removing camera, it worked but it appears that transforms are better now, plus, that could be a good performance boost since matrix multiplication is pretty cheap and really easy to SIMD

as for setScalingFlags, i still think this is a pretty good "wrapper feature" that will just use the transforms under the hood.

setViewport idea is something i actually wanted for a long time where the game's screen looks different over the editor ui and such

[skejeton]

but also there's an upside to having a viewport, although that can be patched by the user if they start using the image targets. right now the things are scaled in "vector mode" but sometimes scaling needs to be applied after rasterization, like in pixel art games

[marekmaskarinec]

I will start by removing camera and adding setViewport.

[marekmaskarinec]

Removing camera will be pain. Lot of my projects frequently use global.cam.w and global.cam.h

[skejeton]

Removing camera will be pain. Lot of my projects frequently use global.cam.w and global.cam.h

same thing, but you can make it use setViewport on high level right?

[marekmaskarinec]

What exactly do you mean?

[marekmaskarinec]

I implement window.setViewport

[skejeton]

What exactly do you mean?

Make global camera use setviewport under the hood, although now i've realized that would require a setter. You can also do setviewport to match the global camera somewhere during the pipeline when you are actually changing the rect, but yeah, that's one of the places globals can get in the way.

[skejeton]

I implement window.setViewport

I'll take a look!

[marekmaskarinec]

You can do setViewport(th.Vf2{global.cam.w, global.cam.h}) at the end of every cycle.

"---------- Původní zpráva ---------- Od: ske @.***> Datum: 12.11.2022 11:13:15 Předmět: Re: [marekmaskarinec/tophat] Scaling modes (Issue #114)

"

What exactly do you mean?

"

Make global camera use setviewport under the hood, although now i've realized that would require a setter. You can also do setviewport to match the global camera somewhere during the pipeline when you are actually changing the rect, but yeah, that's one of the places globals can get in the way.

— Reply to this email directly, view it on GitHub (https://github.com/marekmaskarinec/tophat/issues/114#issuecomment-1312446063) , or unsubscribe (https://github.com/notifications/unsubscribe-auth/AKGM45J2G6EAIXRHGQAHVKLWH5UTNANCNFSM6AAAAAAR4ZEICY) . You are receiving this because you commented. Message ID: <marekmaskarinec/ @.***>

"

[marekmaskarinec]

We should take this issue into consideration when working on the new renderer.

[skejeton]

This issue can be implemented manually using framebuffers now. However since this is extremely common I think it's worth adding it natively. Thoughts?