Support for non-square pixel ratios?

Started by Elvisish, Thu 14/11/2024 19:06:16

Previous topic - Next topic

Elvisish

Could it be possible to support non-square pixel ratios? Most (if not all) of the VGA Lucasarts games were drawn with a 6:5 pixel-ratio, intended to be viewed in Mode 13h. The game would technically be rendered at 320x200, then stretched vertically to 320x240 where each pixel is now 1.2x taller. Sierra AGI games were drawn at 2:1 ratio, where every pixel is twice as wide as it is tall.

Aseprite supports custom pixel ratios, so art can be drawn as it would be rendered, AGS would just require a way of setting the internal resolution and the actual rendered resolution.

Crimson Wizard

#1
So, previously I thought about this a little, and it seems like this may be done in a following way:

1. The game has 2 resolution settings: logical resolution and, say, "visual resolution". "Visual resolution" is optional, and if not set then it's treated as equal to logical resolution.

2. In the Editor, the game is created in logical resolution. Optionally we might make game previews show "visual res" too, but in the current state of this program that's going to be significantly more work, and affect a number of different panes (room editor, gui editor, and who knows what else), so I'd separate that out.

3. At runtime, all the game logic is run in logical resolution. The game simply does not "know" about visual one. (well, that does not mean that we cannot read this property in script, but rather that it does not affect any coordinates in game or script).

4. There's a concept of a "main game viewport", right now it's rather a formality, but in theory we may use this in order to transform the whole game image additionally, before final filter scaling is applied (the one that scales the game frame to the fullscreen/window resolution).

So, the game visual transformation chain would look like:

Code: ags
 [ whole game drawn in native logical resolution ] 
    |
    | - full-game viewport scaling
    V
 [ game frame using native visual resolution ]
    |
    | - graphics filter
    V
 [ display game in window ]


We might even change the position of "engine layer", like FPS counter, in this chain, and place it after first transformation, so that they render unstretched.

eri0o


Crimson Wizard

Quote from: eri0o on Thu 14/11/2024 19:33:02There is a thread on this previously, if you want it right now it's possible by resizing the viewport.

https://www.adventuregamestudio.co.uk/forums/editor-development/feature-request-agi-21-aspect-ratio-support/msg636663951/#msg636663951


I've mentioned this to the user previously, when we spoke on Discord.
But that's only for rooms, the rest of the game will have to be adjusted by hand, which is less convenient.

Snarky

Note that for this to display correctly without artifacts, it will often require quite high monitor resolutions. For example, to properly render a 5:6 pixel aspect ratio for a 320x200 game, you need at least a 1200 vertical resolution monitor, while it seems like 1920x1080 is still (!) – in the Year of Our Lord 2024 – the most common desktop screen resolution. Otherwise you'll get uneven pixel sizes or blurry pixel edges.

Crimson Wizard

#5
Quote from: Snarky on Thu 14/11/2024 20:27:51Note that for this to display correctly without artifacts, it will often require quite high monitor resolutions. For example, to properly render a 5:6 pixel aspect ratio for a 320x200 game, you need at least a 1200 vertical resolution monitor

What does "properly render" mean in this context?

In above user's example this is going to be 320x200 displayed as 320x240. 320x240 game may be displayed with up to x4 scaling if using integer multiplier, either in a window, or with some black borders around it in 1920x1080 fullscreen.

EDIT: also it looks like there's a confusion about ratio. Elvisish sais "6:5" ratio, you say "5:6". But 320x240 is 4:3 ratio, is not it?
Linked wikipedia article on 13h mode also mentions 4:3.

Snarky

#6
Quote from: Crimson Wizard on Thu 14/11/2024 20:36:09What does "properly render" mean in this context?

Pixel perfect.

Quote from: Crimson Wizard on Thu 14/11/2024 20:36:09In above user's example this is going to be 320x200 displayed as 320x240.

No, it's going to be 320x200 displayed as 1600x1200, where each game pixel is displayed as a 5x6 rectangle on screen.

You cannot properly display a 320x200 image on 320x240 pixels: the stretching will either involve e.g. linear interpolation which makes all the pixels blurry, or a nearest-neighbor filter where some lines of pixels will be twice as tall as the others.

So it's not really correct to say that "The game would technically be rendered at 320x200, then stretched vertically to 320x240 where each pixel is now 1.2x taller." The resolution always remained 320x200, just fit to a 4:3 screen (320:240 = 4:3) by making each pixel taller. That works on a CRT screen but not on screens like LCDs which have physically fixed pixels.

Quote from: Crimson Wizard on Thu 14/11/2024 20:36:09EDIT: also it looks like there's a confusion about ratio. Elvisish sais "6:5" ratio, you say "5:6". But 320x240 is 4:3 ratio, is not it?
Linked wikipedia article on 13h mode also mentions 4:3.

We're talking about the pixel aspect ratio, not the screen aspect ratio. If we follow the usual convention where the ratio is expressed as width:height, it's 5:6 (taller than they are wide), but people do sometimes switch it around.

Elvisish

#7
Quote from: Crimson Wizard on Thu 14/11/2024 20:36:09
Quote from: Snarky on Thu 14/11/2024 20:27:51Note that for this to display correctly without artifacts, it will often require quite high monitor resolutions. For example, to properly render a 5:6 pixel aspect ratio for a 320x200 game, you need at least a 1200 vertical resolution monitor

What does "properly render" mean in this context?

In above user's example this is going to be 320x200 displayed as 320x240. 320x240 game may be displayed with up to x4 scaling if using integer multiplier, either in a window, or with some black borders around it in 1920x1080 fullscreen.

EDIT: also it looks like there's a confusion about ratio. Elvisish sais "6:5" ratio, you say "5:6". But 320x240 is 4:3 ratio, is not it?
Linked wikipedia article on 13h mode also mentions 4:3.

5:6 is correct since the pixels would be taller than wider, but if you were making an AGI game you'd want 2:1 as the pixels would be wider than taller. 4:3 is the screen ratio, 5:6 is the pixel ratio.

Quote from: Snarky on Thu 14/11/2024 20:27:51Note that for this to display correctly without artifacts, it will often require quite high monitor resolutions. For example, to properly render a 5:6 pixel aspect ratio for a 320x200 game, you need at least a 1200 vertical resolution monitor, while it seems like 1920x1080 is still (!) – in the Year of Our Lord 2024 – the most common desktop screen resolution. Otherwise you'll get uneven pixel sizes or blurry pixel edges.

Yes, this is how ScummVM does it, if the screen resolution is too low, it will be distorted, there's no way around that as the process used to be done on the CRT, whereas now it must be done after the image has been upscaled to the native resolution of the monitor.

SMF spam blocked by CleanTalk