WASM needs aspect ratio preserving full screen mode about wipeout-rewrite

[phoboslab]

Not sure why that happens; can't reproduce for lack of iPad. Do you have any insights on why toggling fullscreen doesn't trigger the resize event on the WebGL context?

[jonsage]

The same thing happens on a desktop browser too.

It's hard to perceive because the game screen ratio and the desktop screen ratio is similar.

But watch the circular elements in particular - the logos at the start have a few circles - when going to and from full screen there are issues that should become clear if you compare the circle shapes.

I'm assuming you have coded the game to run at a specific set of resolutions (as this is ported from PC version I guess that is how it works?) So what I'd expect to happen is that when going fullscreen there would be black bars visible when necessary to ensure the game's ratio stays the same. Instead it seems to just stretch the entire canvas.

It's been a long time since I have worked with fullscreen functionality in browsers - but it used to be the case I think that sometimes it is better to "fullscreen" a wrapping "div" rather than the canvas itself.

[phoboslab]

But watch the circular elements in particular - the logos at the start have a few circles - when going to and from full screen there are issues that should become clear if you compare the circle shapes.

You mean these?

Well, the background image is stretched to cover the whole screen. We could tile it, or indeed pillarbox the background. Both bad options in my opinion, as the image is not meant to be tiled and pillarboxing looks way worse than some stretching.

I'm assuming you have coded the game to run at a specific set of resolution

No.

So what I'd expect to happen is that when going fullscreen there would be black bars visible when necessary to ensure the game's ratio stays the same.

Why? For the main game the aspect ratio doesn't matter. I should be able to play in 16:9 if I want to, instead of being forced to 4:3.

but it used to be the case I think that sometimes it is better to "fullscreen" a wrapping "div" rather than the canvas itself.

That's how it works currently. The wrapping DIV also contains the touch controls, so we cannot just fullscreen the canvas.

So I assume I misunderstood the whole issue. It's NOT the case that the WebGL resolution doesn't match the canvas CSS size and aspect ratio. Rather, the issue is that the menu backgrounds, title screen and intro video are inherently 4:3 and stretched to 16:9 - which I think is OK; better than pillarboxing.