[FEATURE REQUEST] - AGI 2:1 Aspect Ratio Support

[Gal Shemesh]

Hi guys,

Not sure if anyone would be interested in this, but if it's not too much to ask maybe others like me would appreciate it.

I'm trying to make a short game in all the historical graphical Sierra styles games, which are AGI (running in 2:1 aspect ratio in 16 colors), SCI (1:1 aspect ratio in 16 colors), and AGS (1:1 aspect ratio in rich colors).

However, I found that if I draw my graphics in Aseprite in 2:1 aspect ratio which is natively supports, I need to resample the images when exporting them so they would stretch twice as big horizontally before importing them into AGS, or else they would look narrow. So I wondered if there's a way to have an aspect ratio of 2:1 in AGS but then found that there is none...

Resampling the sprites and backgrounds may statically look good, but the overall gameplay experience would still behave in a 1:1 manner, meaning that when the character moves it would move 1 pixel instead of 2 when walking to the sides, breaking the feel of an AGI style game.

There's another feature request that I just posted for having an AGI style game feel (here), so we'd be able to set the characters to stop on any of their Walking cycle frames, and not only on the first frame (ID 0).

I really don't want to start learning the out-dated AGI Studio engine for a small game only to achieve its feel, and would prefer it if I could make it in AGS where I'm more comfortable with.

Of course, the Room Editor with all its drawing tools should also work in the 2:1 aspect ratio, so I'm really not sure what such feature request involves. However, if it's possible and not too much work it would be nice to have in AGS.

Thanks

[Crimson Wizard]

I believe that you can easily achieve this, and many other similar effects, with the Room Viewport / Camera settings:
https://adventuregamestudio.github.io/ags-manual/Camera.html
https://adventuregamestudio.github.io/ags-manual/Viewport.html


For example, you create everything 1:1, and then stretch the Camera's size to have double width.

[Gal Shemesh]

That's an option, I guess. Though, wouldn't it be visible only in runtime? I was more thinking about something that the entire editor could show the resources (and the room) in the 2:1 aspect ratio, so it would be easy to view and edit things in the editor. Otherwise, everything would look narrow / skewed.

Here's an example how an AGI background would look when imported into AGS (original on the left versus a resampled version on the right):

[Crimson Wizard]

I was more thinking about something that the entire editor could show the resources (and the room) in the 2:1 aspect ratio, so it would be easy to view and edit things in the editor.

I guess that's also an option; since there's already a "scaling" setting in Room editor (and few other panes), it is technically possible to do separate scaling by x and y.

The questions remaining are:
- how to configure this to keep saved in the project;
- which previews (editor panes) to apply this scaling to;
- how (or whether) to connect to the runtime viewport/camera setup.

EDIT: No, actually, if the whole game has to be rescaled, then Camera won't be enough. There's also a need to scale GUI, and texts... or is there?

If the whole game has to be displayed in 2:1, then engine would have to support full game screen transformation option.

EDIT2: In other words, it's essential to clearly specify, which parts of the game have to be visually rescaled to a different ratio.
After this, it will have to be decided:
- how to achieve this at runtime;
- how to achieve this in the Editor preview.

[Gal Shemesh]

Tweaking camera settings shouldn't be necessary to achieve this; the 2:1 aspect ratio should basically be for any sprite related resource that is imported into the game, including fonts. So it's the Sprites section, GUI, Inventory Items, Views, Characters, Mouse Pointers, Fonts - anything that has resources preview. And of course, the entire Room Editor which should be affected as well, such as when drawing masks or moving objects around: drawing / moving anything on the horizontal axis should move in increments of 2 pixels to the sides and 1 pixel to the top and bottom.

When looking on it from a point of view of 1:1 aspect ratio, this may look like a 160x200 resolution game that is stretched up twice as big to its sides by the editor and engine, making it look a 320x200 game in an aspect ratio of 2:1.

[Crimson Wizard]

Tweaking camera settings shouldn't be necessary to achieve this

When looking on it from a point of view of 1:1 aspect ratio, this may look like a 160x200 resolution game that is stretched up twice as big to its sides by the editor and engine, making it look a 320x200 game in an aspect ratio of 2:1.

If logically it is 160x200 game which only looks 320x200, then everything should stay in 160x200, and only displayed 320x200. This is what cameras are for.

But given you also want this for GUI and texts, then we need a Camera-like effect for the whole game screen.

[Gal Shemesh]

Kind of... I mean, you can both look at it as a 160x200 game in an aspect ratio of 1:1 that gets streached to 320x200, or a 320x200 game in an aspect ratio of 2:1. But the second one (the natively 2:1) is the way it should be considered, where both the editor and the engine during runtime should take the aspect ratio into account and do the streching/scalling automatically for all of the in-game resources.

Just like in Aseprite when I open a 2:1 graphic that was saved in a 2:1 aspect ratio - it automatically shows it correctly, streatching the preview to look twice as big to its sides, without doing any manipulation to the actual resource. The drawing tools also work in a 2:1 way which is wonderful. If however, I open the resource is a program that does not take into account the aspect ratio setting, such as Windows Paint, then the resource would be considered in an aspect ratio of 1:1 and would look narrow, which is incorrect.

[Crimson Wizard]

The way I see this problem, is that game resources should not be stretched individually neither in Editor nor in the Engine as in - their pixels in memory should not be duplicated. Only the final image on screen should be stretched at runtime, and previews should be visually stretched in the Editor.

But I do not know how AGI games ran logically.

In order to define whether that's true or false, consider following question: which coordinates are you planning to use in script, for example, when ordering Walk()? Would that be 160x200 or 320x200 resolution?
Suppose you want to modify a sprite at runtime, in script, using DynamicSprite and DrawingSurface. Which resolution will that DrawingSurface relate to, 160x200 or 320x200?

[Gal Shemesh]

The way I see this problem, is that game resources should not be stretched for real individually neither in Editor nor in the Engine as in - their pixels in memory should not be duplicated. Only the final image on screen should be stretched at runtime, and previews should be visually stretched in the Editor.

In order to define whether that's true or false, consider following question: which coordinates are you planning to use in script, for example, when ordering Walk()? Would that be 160x200 or 320x200 resolution?
Suppose you want to modify a sprite at runtime, in script, using DynamicSprite and DrawingSurface. Which resolution will that DrawingSurface relate to, 160x200 or 320x200?

That's a very good question! I think that it should be 320x200 where the coordinates on screen (when moving the mouse cursor in the Room Editor) should also be affected by the 2:1 aspect ratio. Meaning that you'd need to move the mouse twice the distance to move one pixel to the sides than to move one pixel to the top or bottom. I think that this is how it behaved in AGI Studio, but I'm going to load one of the Sierra games and check this now. Will come back to update shortly...

[eri0o]

With both GUI scaling and Camera/Viewport this looks easy to achieve with only regular scripting.

[Crimson Wizard]

I think if we take this quote from your original post:

Resampling the sprites and backgrounds may statically look good, but the overall gameplay experience would still behave in a 1:1 manner, meaning that when the character moves it would move 1 pixel instead of 2 when walking to the sides, breaking the feel of an AGI style game.

If you want characters and other objects to stick strictly to 2:1 pixels, that means that you must have a logical resolution of 160x200. That's like a physical world is 160x200, but visually stretched to 320x200.
If so, then all rooms, masks, and all script commands must natively be in 160x200.

[Gal Shemesh]

I think if we take this quote from your original post:

Resampling the sprites and backgrounds may statically look good, but the overall gameplay experience would still behave in a 1:1 manner, meaning that when the character moves it would move 1 pixel instead of 2 when walking to the sides, breaking the feel of an AGI style game.

If you want characters and other objects to stick strictly to 2:1 pixels, that means that you must have a logical resolution of 160x200. That's like a physical world is 160x200, but visually stretched to 320x200.
If so, then all rooms, masks, and all script commands must natively be in 160x200.

You're correct. I've just finished examining one of Sierra's AGI games and found that when I set a character to walk to around pixel 140 on the X axis, it almost reached the end of the screen to the right. So the AGI interpreter considers the game in 160x200 resolution and projects it to be displayed in 320x200. So yeah, the logic resolution must be 160x200, which can be set in a custom resolution. Only need to have the Editor to be able to show all of the resources in aspect ratio of 2:1 and the Engine too during runtime. Or else everything would look half as wide.

[Snarky]

With both GUI scaling and Camera/Viewport this looks easy to achieve with only regular scripting.

... And to handle speech text, I suppose you could do something like Speech.TextOverlay.Width *= 2; (along with repositioning, probably). Or just use a double-wide font.

Only need to have the Editor to be able to show all of the resources in aspect ratio of 2:1

If the only issue is that things look squeezed in the editor, does it really make sense to devote efforts to this very edgy edge-case?

[Gal Shemesh]

Hi Snarky

The old AGI style doesn't use speech, only text boxes describing what happens when you do something. But anyway, if the camera would be set to stretch everything twice as wide on runtime then no further manual adjustment needed to be done - everything would have an aspect ratio of 2:1 then.

The squeezed graphics in the editor is just something I find a little annoying when editing the game - I remember making a game in an old game creation engine in 160x200 resolution back in my childhood, only to mimic the AGI style and feel, and I had to work my head trying to ignore the narrow look when editing everything, while the engine was set to stretch the game to 640x400 on runtime (320x200 x2). While it worked, it was somewhat annoying while editing...

However, I wouldn't want anyone to spend a lot of time working on something that only a minor amount of people might use. But if there's an option to have the editor support an aspect ratio setting which would manipulate the appearance of the pixels in both the editor and engine, that would be great! You can then even have a different aspect ratio in mind if you want to have a unique style of a game, the pixels would be manipulated automatically, and you won't need to tweak any camera setting - only to handle the aspect ratio property.

[Crimson Wizard]

To outline the problem.

On the Editor's side:

It's not particularily difficult to make Room and GUI previews scaled to a given ratio. As Editor already has preview scaling and all necessary code for both converting display and interactions (clicks in display resolution to logical resolution), then it's a matter of separating X and Y scale factors.

The missing part is a project setting, and applying this setting everywhere.

Then, some previews are probably coded to have previews stretched with certain proportion (like Views, or Sprite preview), so can't tell if more work will have to be done to achieve custom ratio there.

On the Engine's side:

For automatic behavior, engine has to support whole "GUI layer" transformation (both in terms of display and interaction) and/or whole Game screen transformation. This is similar to how Room Viewports are done.

[Gal Shemesh]

I see. Well, thanks for the detailed information and for looking into this. This would be a nice add-on for AGS if eventually implemented. No rush about it, though. Only if and when you have time. Appreciate it. Thanks!!