Other Resolutions.

[Calin Leafshade]

Would this be a good time to talk about the resolutions that AGS offers?

Currently AGS only offers 4:3 resolutions but the vast majorities of form factors that we deal with now are actually 16:10 or 16:9. Phones, laptops and monitors are almost all not 4:3.

Is this something we could discuss? I think we need a better way of relating the screen to the game res.

[Monsieur OUXX]

What are you dealing with exactly:
1) Making sure that the engine won't crash on exotic resolutions? (sometimes DirectX will tell you it can't initialize the device)...
...OR...
2) Offering those resolutions in the Editor, for design purposes?

Point 1 is my priority, even though big steps forward have been made in some branches of the Engine (can't remember which one).

[Calin Leafshade]

I think that merely offering resolutions at a different aspect ratio and ensuring proper letterboxing/pillarboxing where appropriate would be enough in the short term.

[MurrayL]

It'd be great if the engine showed the graphics options when there was a problem initialising, rather than just plonking a confusing error message in front of the player and closing outright.

[Crimson Wizard]

I never investigated this, but the general scaling filters, both software and D3D (also used for OpenGL driver by JJS), seemingly work in a very simple way: they take "multiplier" parameter in their constructor. They then use this multiplier to adjust sizes and coords. The solution may be to make 2 multipliers instead of one (for horizontal and vertical adjustment) and alter the way the filter is being set up: instead of having a multiplier options in combo-box, have resolution selection.

However, I have suspicions that this may cause problems with mouse-to-screen translations. AGS does some tricky things there, some of them are probably for backwards-compatibility. I don't have much knowledge about that yet.

[Calin Leafshade]

Yea, I've had a bit of a look at how this all works and it seems that a lot of the arcane stuff is a remnant from when AGS used "non-native" coordinates. i.e the coordinates were always mapped to 320x2#0 regardless of the actual resolution. I dont necessarily think that the engine needs to be able to scale width and height independantly merely that the user(game maker) can choose a native resolution for their game and then the engine scales and letterboxes in a sensible manner.

The user could set whether their game should only scale by integer values if it uses pixel art for instance.

I just think the engine needs to be a bit more smart about the whole thing to make it competitive. The number one complaint with AGS is *always* resolution.

[Crimson Wizard]

This made my day

(sorry, failed to upload pics to imageshack for some reason; also they are a bit unconventional size)
http://www.mediafire.com/view/?vq9s6k61ajaym8j
http://www.mediafire.com/view/?5v69ttg0ih9361b

[Calin Leafshade]

It's a start...

[Crimson Wizard]

Successfuly run the game fullscreen with 1920x1080 resolution.
Used multipliers: 6000/4500. The game's resolution is 320x200, but I guess AGS treats it as 320x240. (correction: this was because it forced widescreen resolution; with forced widescreen res off, it works with 6000/5400 multipliers)

E: oh, I forgot to mention, I use fixed-point sizes, basically scale * 1000 values, for better precision. When actual coordinates are calculated, it's done like "x * scale / 1000".

EE: the graphics are ok, but the cursor movement is terrible. It must be smoothed before this could be used.

[Calin Leafshade]

Thats one of the problems you'll have with different scale factors for x and y. Surely then the mouse movement will be more sensitive in one direction than another depending on the values?

[Alan v.Drake]

There should be a clear cut between native and display resolution, then you can just STRETCH the image to screen instead of using multipliers.
A reasonable pipeline could be: Draw native -> Apply filter -> Stretch to display (enabled ? keep aspect ratio ?)

The cursor position should be calculated with mathemagic like:
x = NATIVE_X * (MOUSE_X - BORDER_X) / VIEWPORT_X
y = NATIVE_Y * (MOUSE_Y - BORDER_Y) / VIEWPORT_Y
..,which could be turned to:
MULT_X = NATIVE_X / VIEWPORT_X (to be recalculated only when the viewport is resized)
x = (MOUSE_X - BORDER_X) * MULT_X
etc..

VIEWPORT being the aspect ratioed area, not the whole backbuffer, there should be proper matching between where the mouse is and where the cursor stands, because touch screens say so.

Also "Side borders on widescreen monitors" and "Force alternate letterbox resolution" were quick and dirty hacks that must be removed.
What we need is a dropbox menu with available system resolutions, a "Keep aspect ratio" and "Stretch to screen" checkbox. Perhaps someone might want to specify which aspect ratio to use but that sounds like very low priority and can be done later.

This way we could have whatever native resolution and whatever display resolution and forget forever about these issues.


- Alan

[Calin Leafshade]

I agree that things should be rendered natively to a separate render target before being pushed to the back buffer at display resolution.

If nothing else, it's faster.

"game resolution" and display resolution should be entirely disconnected I think.

[Crimson Wizard]

There should be a clear cut between native and display resolution, then you can just STRETCH the image to screen instead of using multipliers.
A reasonable pipeline could be: Draw native -> Apply filter -> Stretch to display (enabled ? keep aspect ratio ?)

Well, isn't this what AGS filters do now?
Multipliers are used mainly in calculating mouse bounding box and position.

[Alan v.Drake]

There should be a clear cut between native and display resolution, then you can just STRETCH the image to screen instead of using multipliers.
A reasonable pipeline could be: Draw native -> Apply filter -> Stretch to display (enabled ? keep aspect ratio ?)

Well, isn't this what AGS filters do now?
Multipliers are used mainly in calculating mouse bounding box and position.

Heh, at the moment filters are the ones that decide resolution, the poor user doesn't have a say in it.
I had seen some checks spread around that changed behaviour with multipliers, I don't know how the situation is now with refactory.

- Alan

[Crimson Wizard]

I had seen some checks spread around that changed behaviour with multipliers, I don't know how the situation is now with refactory.

It's the same, only difference is that we increased max scaling to x8 (dunno if someone runs 320x200 games in 2560x1600, but we are ready for that ).

[dbuske]

Calin, Have all your plug-ins been included in the current version of AGS?

[Calin Leafshade]

Not relevant to the thread but yes all the important ones have I believe. AGSBlend and SpriteFonts namely.

[Crimson Wizard]

Calin, Have all your plug-ins been included in the current version of AGS?

Not relevant to the thread but yes all the important ones have I believe. AGSBlend and SpriteFonts namely.

What "current version" of AGS includes AGSBlend and SpriteFonts?
I ask, because I don't understand what version dbuske has in mind.

[Calin Leafshade]

Well, yes, technically i misspoke. The current released version (3.2.1) does not contain any plugins but my plugins have been included in the git repo for the purposes of running games that use them on other platforms.

[selmiak]

Let me add that whenever I play in fullscreen on my 16:9 monitor I have letterboxing on top/bottom and both sides, but if I have a room background that is bigger than the room size and play in fullscreen in D3D 9  the top/bottom letterboxes disappear and everything is filled. This doesn't happen in DirectDraw5. And as nice as this looks without the letterboxing on top/bottom when I have a gui, for example a black gui to cover the screen like a fadeout it only covers the center of the screen and from there to the borders in straight lines, but the corners of the room background (overlapping the room size) are still visible. This only happens on some monitors though.
I hope this was posted in the right thread.

A reasonable pipeline could be: Draw native -> Apply filter -> Stretch to display (enabled ? keep aspect ratio ?)

This sounds cool, and keeping the aspect ratio is preferred from an artists viewpoint, so that the player always sees what he is supposed to see, at least in the correct aspect ratio, and also setting the window back to the correct aspect ratio is a pain once you distorted the AR. Maybe letting the user stretch to whatever when holding shift could be an option...

Yea, I've had a bit of a look at how this all works and it seems that a lot of the arcane stuff is a remnant from when AGS used "non-native" coordinates.

Why is it that the engine needs backwards compatibility to old AGS versions? I never understood this? Isn't it what the editor/compiler needs? All games written on older versions of the editor are compiled already and running. And if you import your old project into a newer version of the editor the editor could point out your deprecated code. Or just not compile the game and tell you where your code is too old. Like with the new audio scripting. Or just flag the project with a version number and in the engine you could have a check for this flag, if (versionnumber < 3.0) { make this oldcode work and react like it is supposed to work (or translate it to new style scripting)} else { only accepts new style scripting }
And with this have all the old deprecated code in a block and the newer stuff in another block without them interfering. Or am I thinking too simple? Don't want to derail this topic, and don't know much about engine coding, but I never understood this and would be happy to understand this.

[Crimson Wizard]

Why is it that the engine needs backwards compatibility to old AGS versions? I never understood this? Isn't it what the editor/compiler needs?

Primarily to run old games on other platforms than Windows, which can't run game in its original state (windows exe).
Also, in certain cases, running old games is better with the new engine, which provides, e.g., video settings better compatible with modern OSes.
Upgrading old project sounds good, but there are thousand of AGS games made by numerous people. You won't ask all of them to remake their games.

Or just flag the project with a version number and in the engine you could have a check for this flag,

And with this have all the old deprecated code in a block and the newer stuff in another block without them interfering.

Indeed, and that is exactly what we are doing. Either making a switch between different versions of code, or rewriting code in such a way that will work for old and new versions (when possible).
You probably confuse "backward compatibility" concept with something. It does not mean we can't change the code.

[selmiak]

nah, was just thinking this is making it unneccesarily complicated and hard to progress with the legacy code always in it.

[Gord10]

People, I have managed adding 1280*720 resolution to AGS!

I have simply added R1280x720 definition as a 7th element in GameResolution.cs. And then I modified other resolution-related parts of editor and engine, like GetGameResolutionHeight(GameResolutions resolution) function. Now I've got a game that runs perfectly in 1280*720. I will release my next game in this resolution.

Note that I have done nothing yet for backwards compatibility.

I wonder if my compiled test game will work for you, too.
My modified version of AGS
Sample wide screen game

And DO NOT try this new version before taking a back-up of your game first!

[LimpingFish]

I'm out of my depth here, but doesn't the SkyGoblin build of AGS feature custom resolutions? I haven't tried it myself, but I remember someone mentioning it.

[Calin Leafshade]

Yes but it's hacky and doesnt work right.

We need a proper solution.

[dbuske]

Yes but it's hacky and doesnt work right.

We need a proper solution.

Have to disagree.  Skygoblin works fine for me.  I added it on top of 3.2

[Crimson Wizard]

Skygoblins version has bugs. I don't know how many and serious they are, and if they may have a strong impact on development, but in any case this means that we cannot use that code as-as, someone must check it out and make fixes (or maybe just rewrite in a better way).

Examples of bugs I found in 15 minutes of working with Skygoblin's Editor:
1. Created a new 320x200 game using 9-verb template. Changed resolution to "Custom Resolution" 320x200. The Editor told me, that resolution did change, and suggested to automatically fix backgrounds. I accepted.
All GUIs become screwed, their sizes and control positions changed in weird ways.
A room editor started to display an image of disproportional size (something around 500x220 I think), although I could not move anything in room beyond 320x200 pixels.
When I compiled and run game, it crashed.

2. Created a new empty game. Set "Custom Resolution" in Global Settings. Typed in Width: 1280, Height: 720. Editor displayed an error message. Typed in Width: 320, Height: 240. Editor displayed an error message. And so on.

3. Created a new empty game. Set "Custom Resolution" in Global Settings. Typed in Width: 1280, Height: 720. Ignored error message.
Created a room 1 with blank background. Compiled and run a game. Game crashed.
I checked room editor more carefully, and found out that room coordinates are limited to 640x400 :-/.
I created a 1280x720 bitmap and imported as room background. Okay, it is a 1280x720 room now. Compiled and run game. It crashed.

I built an EXE for release (Build -> Build EXE) and run game setup. Setup shows that game resolution is 1024x768.

EDIT: BTW, I was very curious, and checked how the setup worked in Barely Floating (1280x720 game). First of all, they made custom setup!, secondly, there's no more any common config file in the game folder, and if I force run "Barely Floating.exe --setup", the AGS setup shows, telling me that the game is 320x200!!

Okay, I may believe that there's some special magic way to make things working, but how a regular average game developer is supposed to work with the program that crashes like that and has so much unexpected and weird behavior?

[s_d]

CW, that surreal experience of yours reminds me of META 

[dbuske]

Skygoblins version has bugs. I don't know how many and serious they are, and if they may have a strong impact on development, but in any case this means that we cannot use that code as-as, someone must check it out and make fixes (or maybe just rewrite in a better way).

Examples of bugs I found in 15 minutes of working with Skygoblin's Editor:
1. Created a new 320x200 game using 9-verb template. Changed resolution to "Custom Resolution" 320x200. The Editor told me, that resolution did change, and suggested to automatically fix backgrounds. I accepted.
All GUIs become screwed, their sizes and control positions changed in weird ways.
A room editor started to display an image of disproportional size (something around 500x220 I think), although I could not move anything in room beyond 320x200 pixels.
When I compiled and run game, it crashed.

2. Created a new empty game. Set "Custom Resolution" in Global Settings. Typed in Width: 1280, Height: 720. Editor displayed an error message. Typed in Width: 320, Height: 240. Editor displayed an error message. And so on.

3. Created a new empty game. Set "Custom Resolution" in Global Settings. Typed in Width: 1280, Height: 720. Ignored error message.
Created a room 1 with blank background. Compiled and run a game. Game crashed.
I checked room editor more carefully, and found out that room coordinates are limited to 640x400 :-/.
I created a 1280x720 bitmap and imported as room background. Okay, it is a 1280x720 room now. Compiled and run game. It crashed.

I built an EXE for release (Build -> Build EXE) and run game setup. Setup shows that game resolution is 1024x768.

EDIT: BTW, I was very curious, and checked how the setup worked in Barely Floating (1280x720 game). First of all, they made custom setup!, secondly, there's no more any common config file in the game folder, and if I force run "Barely Floating.exe --setup", the AGS setup shows, telling me that the game is 320x200!!

Okay, I may believe that there's some special magic way to make things working, but how a regular average game developer is supposed to work with the program that crashes like that and has so much unexpected and weird behavior?

Try putting Skygoblinags on top of AGS 3.2.1  I had no problem.

[Crimson Wizard]

Try putting Skygoblinags on top of AGS 3.2.1  I had no problem.

That's what I did. And have exactly same results, as I described above.
Have you tried to repeat any of the actions I mentioned? Did they work for you?

[Calin Leafshade]

it kinda doesn't matter if it worked for him. The implementation is incomplete and needs work. Not least of which the work to bring it in line with the refactored version of the engine.

Literally an irrelevant conversation.

[Crimson Wizard]

I want to add a small comment to this, since I've already saw two people making this mistake in their custom code (that might be same code, I did not accurately compared them yet).

If someone goes to try implementing custom resolutions, I'd strongly advise not to add it on top of existing resolution logic in AGS, e.g. as a "7th" resolution type (as Skygoblin did, for instance).
The first thing that should be done, IMO, is to remove the old logic with resolutions defined by IDs completely, and incorporate a new one, supplying a conversion between IDs loaded from old game data into actual resolution numbers (for backwards compatibility).
Even though the Editor may still allow to select between standard resolutions (instead of typing them manually) - they should not be enumerated and saved as "resolution id", but as actual resolution numbers (width x height x color).

Just saying...

[Luca]

I'll take advance of this opened tread to ask a question: me and my illustrator are making a game in 1280X720 using the SkyGoblin custom resolution AGS version and, untill now, we haven't found any bug (we are still protyping )...
Now I read about problems that this version could give... what do you suggest me to make a game with that resolution in AGS?
Our game graphic is nice and we would love to keep it

I'll try Gord10 version too

[Crimson Wizard]

I'll take advance of this opened tread to ask a question: me and my illustrator are making a game in 1280X720 using the SkyGoblin custom resolution AGS version and, untill now, we haven't found any bug (we are still protyping )...
Now I read about problems that this version could give... what do you suggest me to make a game with that resolution in AGS?

I think that Skygoblin's version works well while you stick to its rules. Some people used it for 1280x720 resolution and it worked for them, so I don't see a big problem with that.
What I was saying is that it starts to behave weird as soon as you step outside of certain bounds.
Also, regardless of how well it works for 1280x720, the way it is coded (internally) is not good enough to put this feature to official AGS yet.

[Luca]

These bounds are only about the graphic resolution?

[Crimson Wizard]

These bounds are only about the graphic resolution?

Yes, I guess so.
Well, I did not do full testing, all I know is that it breaks easily if you start experimenting with other resolutions than 1280x720.

[Luca]

Thank you
Is there a new official AGS version in development, maybe supporting higher resolutions?

[Crimson Wizard]

Is there a new official AGS version in development, maybe supporting higher resolutions?

Not yet .

[Luca]

Not yet .

aw sad news

[Luca]

But, apart from the ability to select a custom resolution, what are the differences between the Gord10 version and the SkyGoblin version?

[Crimson Wizard]

Since I was asked by Ascovel about this, also FYI.
I checked the repository I previously mentioned: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48278.msg636455388#msg636455388

The custom resolution code there is essentially the SkyGoblin's one, just little changed to match code style of our repository it was applied on.

The real problem, however, is that it was merged with "develop" branch, which is in potentially unstable and untested state. For that reason I'd rather recommended to not use it.

[Crimson Wizard]

I think Ali had troubles with widescreen mode, that's why he decided to program his own engine for Nelly 2?
I guess I am close to rewrite the way AGS renders game content to screen. First thing I did is dropped half of the graphics mode initialization code, including "letterbox" options.

My idea is to invert the logic of using scaling filters. At the moment the selected scaling filter define final resolution. While it is final resolution that should define which scaling filter to select. Setup should have following options:
- Display resolution
- Fullscreen (yes/no)
- Placement mode:

• Place (just render starting from 0,0)
• Center (center inside window)
• Stretch (stretch to window)
• Best fit (stretch proportionally as much as fits in the window) - this is the default option

- Scaling filter to use if necessary: nearest-neighbour (plain/AA), hq2x, hq3x.


Inside the game, there are 3 sizes defined:
1. Base game size - a resolution the game made with.
2. Game frame size - a target frame for scaling.
3. Display size - the real resolution.

The Game Frame rectangle is calculated based on combination of selected display resolution, base size and scaling filter.
For example, if scaling filter is hq2x or hq3x, the game obviously cannot be stretched to any size. It will be stretched to x2 or x3, as provided by filter, and then centered inside the window.
The normal scaling filter can stretch it to any size and proportions, therefore it is safest way to get proper letterbox and widescreen mode in fullscreen.

[Luca]

I think Ali had troubles with widescreen mode, that's why he decided to program his own engine for Nelly 2?

What resolution does he use?

[Crimson Wizard]

I think Ali had troubles with widescreen mode, that's why he decided to program his own engine for Nelly 2?

What resolution does he use?

800x600.
The thread he started: http://www.adventuregamestudio.co.uk/forums/index.php?topic=48372.0

[Ali]

I think Ali had troubles with widescreen mode, that's why he decided to program his own engine for Nelly 2?

I haven't started programming my own engine, I don't have the skills! What I was trying to do is something approaching what you describe in the post above, but the kickstarter campaign put my experiments on hold for a while. I got as far as placing an 800x600 window (unscaled) within a resolution of 1280x720, which would make the game playable at least.

I am increasingly interested interested in the idea of HD/widescreen resolutions. When you advise against the use of the Skygoblin branch, what are the dangers?

[Snarky]

My idea is to invert the logic of using scaling filters. At the moment the selected scaling filter define final resolution. While it is final resolution that should define which scaling filter to select. Setup should have following options:
- Display resolution
- Fullscreen (yes/no)
- Placement mode:

• Place (just render starting from 0,0)
• Center (center inside window)
• Stretch (stretch to window)
• Best fit (stretch proportionally as much as fits in the window) - this is the default option

- Scaling filter to use if necessary: nearest-neighbour (plain/AA), hq2x, hq3x.


Inside the game, there are 3 sizes defined:
1. Base game size - a resolution the game made with.
2. Game frame size - a target frame for scaling.
3. Display size - the real resolution.

The Game Frame rectangle is calculated based on combination of selected display resolution, base size and scaling filter.
For example, if scaling filter is hq2x or hq3x, the game obviously cannot be stretched to any size. It will be stretched to x2 or x3, as provided by filter, and then centered inside the window.
The normal scaling filter can stretch it to any size and proportions, therefore it is safest way to get proper letterbox and widescreen mode in fullscreen.

It's great that you're trying to address some of the limitations with AGS graphic modes and scaling.

My concern with this approach is that it sounds like the user has to figure out what resolution to pick so that the game will fit the window/screen perfectly. For example, if I want to run a 320x240 game in hq4x, would I have to manually work out that that's 1280x960, and set that as my target resolution? (I personally would want to do this even in full-screen mode, since my video card is perfectly able to set those screen modes. And I always play in full-screen mode.)

I should also point out that it's perfectly possible to take an upscaled version of the game and stretch it (bilinearly or bicubically) to fit another, non-exact-multiple resolution, though you'll get some mild blurring.

[Crimson Wizard]

My concern with this approach is that it sounds like the user has to figure out what resolution to pick so that the game will fit the window/screen perfectly. For example, if I want to run a 320x240 game in hq4x, would I have to manually work out that that's 1280x960, and set that as my target resolution? (I personally would want to do this even in full-screen mode, since my video card is perfectly able to set those screen modes. And I always play in full-screen mode.)

Point is that user shouldn't calculate anything.
Imagine you have a setup dialog which tells you that game is 320x240. It also shows the list of resolutions your monitor/card supports, possibly setting your current display resolution as a default selection. It also shows a list of scaling filters you may use. If you want a "best fit" option, the setup will remove those filters that can't provide correct scaling.
For example if your game is 320x240 and your resolution choice is 1920x1080, the "best fit" game frame would be 1440x1080, which is 4.5 multiple. This means neither of the "Hq" filters will work, and only "free-scaling" filters will stay in the list. In 1920x1080 fullscreen this will look like "letterbox", game image having black side borders.
If you choose "Centered" placement, you will be able to select Hq4x then, which will make game view 1280x960, while keeping the very same display resolution. This way the game image will have both horizontal and vertical black borders.

E: Probably I wasn't clear enough: there won't be any "nearest-neighbour" x2, x3, x4 etc selection, there will be just "nearest-neighbour" with multiplier calculated automatically.

[Alan v.Drake]

Allow me to interject,

The Game Frame rectangle is calculated based on combination of selected display resolution, base size and scaling filter.
For example, if scaling filter is hq2x or hq3x, the game obviously cannot be stretched to any size. It will be stretched to x2 or x3, as provided by filter, and then centered inside the window.
The normal scaling filter can stretch it to any size and proportions, therefore it is safest way to get proper letterbox and widescreen mode in fullscreen.

The game obviously can and must be stretched to any size. The only case to argue about is when the display resolution is inferior than the game resolution (how to handle mouse position, since you wouldn't be able to tell exactly over what game pixel the mouse cursor is over).

"Best fit", like "Stretch", shouldn't hide filters, they should simply stretch the output after the filter is applied. At least, that's how it's usually done. ( Source -> Filter [-> Stretch to viewport] )

"Place" and "Center" are the only modes that would need a check so not to overstep the display boundaries.

- Alan

[Crimson Wizard]

"Best fit", like "Stretch", shouldn't hide filters, they should simply stretch the output after the filter is applied. At least, that's how it's usually done. ( Source -> Filter [-> Stretch to viewport] )

I don't understand, how it is stretched "after filter is applied"? With some other filter? What is the purpose of the first filter then?

[Snarky]

Point is that user shouldn't calculate anything.
Imagine you have a setup dialog which tells you that game is 320x240. It also shows the list of resolutions your monitor/card supports, possibly setting your current display resolution as a default selection. It also shows a list of scaling filters you may use. If you want a "best fit" option, the setup will remove those filters that can't provide correct scaling.
For example if your game is 320x240 and your resolution choice is 1920x1080, the "best fit" game frame would be 1440x1080, which is 4.5 multiple. This means neither of the "Hq" filters will work, and only "free-scaling" filters will stay in the list. In 1920x1080 fullscreen this will look like "letterbox", game image having black side borders.
If you choose "Centered" placement, you will be able to select Hq4x then, which will make game view 1280x960, while keeping the very same display resolution. This way the game image will have both horizontal and vertical black borders.

The thing is that that's not how I choose the graphics mode. I don't have my heart set on a specific resolution which then determines how to display the game. I want to display the game in a certain way (e.g. fullscreen, filling the entire proportional area of the screen, with hq3x), and then that determines what resolution is best. It would be very annoying to have to try different resolutions, only to find that some of them don't support the options I want, or only display the actual graphics in some portion of the screen, etc.

The game obviously can and must be stretched to any size. The only case to argue about is when the display resolution is inferior than the game resolution (how to handle mouse position, since you wouldn't be able to tell exactly over what game pixel the mouse cursor is over).

"Best fit", like "Stretch", shouldn't hide filters, they should simply stretch the output after the filter is applied. At least, that's how it's usually done. ( Source -> Filter [-> Stretch to viewport] )

Yes, with the caveat that this should be optional, so if turned off the window would snap to the "integer multiple" sizes when you try to resize. That's how either DOSBox or ScummVM works on Windows.

[Crimson Wizard]

Alright, I am in confusion again. What is the right way then? Leave x2, x3, x4 etc selections?

[Snarky]

"Best fit", like "Stretch", shouldn't hide filters, they should simply stretch the output after the filter is applied. At least, that's how it's usually done. ( Source -> Filter [-> Stretch to viewport] )

I don't understand, how it is stretched "after filter is applied"? With some other filter? What is the purpose of the first filter then?

Once you've scaled up the graphics to 3x or higher, bilinear/bicubic scaling just introduces some slight softness to the pixel edges (essentially antialiasing). So if a hq5x canvas doesn't quite fit on the screen, for example, you can stretch down, or up to make it fullscreen if it was slightly too small, without major loss of quality.

You mentioned nearest-neighbor with antialiasing, which is essentially the same thing for that case. (A naive nearest-neighbor filter without antialiasing would look horrible on non-integer scaling ratios.)

[Ali]

Can I add another thought? Bearing in mind that AGS really should offer high/widescreen resolutions in the future, shouldn't the scaling process allow for that?

Hopefully one day, someone will try to run a 1920x1080 game on a 1280x720 monitor. Then the engine will need to scale down to accommodate that. I think it would be a real shame if these scaling and display improvements helped keep AGS locked in to dated resolutions.

[Crimson Wizard]

The thing is that that's not how I choose the graphics mode. I don't have my heart set on a specific resolution which then determines how to display the game. I want to display the game in a certain way (e.g. fullscreen, filling the entire proportional area of the screen, with hq3x), and then that determines what resolution is best. It would be very annoying to have to try different resolutions, only to find that some of them don't support the options I want, or only display the actual graphics in some portion of the screen, etc.

So, does this mean there should be both way to choose display resolution to make filter match that resolution, and choose used filter & multiplier and make resolution match them? Some people may not care about which multiplier to use, they may want to just stretch the game over their current display?

[Eric]

Is it out of reach to have an option that stretches proportionately until the picture hits the limits on either the top and bottom, or left and right of the screen? Is that what others are asking for?

[Crimson Wizard]

Is it out of reach to have an option that stretches proportionately until the picture hits the limits on either the top and bottom, or left and right of the screen? Is that what others are asking for?

That's what I called "best fit":

Best fit (stretch proportionally as much as fits in the window) - this is the default option

I was thinking, maybe what Snarky asks for is "stretch window to the chosen game scale"?

[Alan v.Drake]

"Best fit", like "Stretch", shouldn't hide filters, they should simply stretch the output after the filter is applied. At least, that's how it's usually done. ( Source -> Filter [-> Stretch to viewport] )

I don't understand, how it is stretched "after filter is applied"? With some other filter? What is the purpose of the first filter then?

Using stretch_blit() for software rendering and StretchRect for direct3d IIRC.
The purpose of filters is to add fancyness, of course!

You don't even have to calculate multipliers since you can just stretch to whatever size you want. Unless you want to separate "Best fit" from "Stretch with aspect ratio" or make a "keep aspect ratio" checkbox only for the "Stretch" option. And who knows, would we need also a way to change aspect ratio so old 320x200 games show like 4:3 ? unnecessary burden

That reminds me, I could use a separate checkbox for "bilinear filtering", which is only tied to the stretching.
That way, for example, we could use a simple2x filter and then stretch with bilinear which makes low-res games look better, not too blurry, not too sharp.

I admit, I'm rooting for the way my favourite emulators handle the task, like Snes9x

- Alan

[Crimson Wizard]

You don't even have to calculate multipliers since you can just stretch to whatever size you want.

We must calculate multipliers to know which virtual pixel mouse is over.

[Alan v.Drake]

You don't even have to calculate multipliers since you can just stretch to whatever size you want.

We must calculate multipliers to know which virtual pixel mouse is over.

Of course we need to do that.
I was referring to the calculation I thought you meant when you were talking about finding the best match for filters and multipliers, to make the image fit the screen but not completely.

[Snarky]

Yeah, I also say we should look to how other programs do it. Here are my thoughts on how I would want it to work, though:

The most important thing is that this should all be dynamic, something you can change on the fly without restarting the game.

Settings:
-Filter (2x, 3x, hq2x, ... which gives an effective game resolution, and tells you what it is)
-Window/fullscreen (switch between window/fullscreen with Alt-Enter by default)
-Fullscreen resolution (defaults to your current resolution, maybe detects supported modes and lists those)
-Stretch mode (none/center, stretch, proportional/best fit, only pixel multiples)

If you set the stretch mode to "only pixel multiples", if you try to stretch the window it will snap to integer multiples of the native game resolution, and the only supported fullscreen resolutions will be those same dimensions. I'm agnostic about how it should display e.g. a 320x200 game that you've set to hq4x (so the effective resolution is 1280x800), and "only pixel multiples," in a 960x600 client area. Should it scale down the hq4x graphics, or should it switch intelligently to hq3x? (The point is moot for the basic 2x, 3x, 4x, 5x filters, since the results should be identical.)

[Crimson Wizard]

There may be a sense in selecting x2, x3 etc filters for windowed mode, but is there a point to explicitly choose them for fullscreen? Why should you not using your current display resolution?
Also, what if it is not x2 or x3 multiplier, but 1.5 or 3.2 which fits best for your screen?

[Snarky]

There may be a sense in selecting x2, x3 etc filters for windowed mode, but is there a point to explicitly choose them for fullscreen?

With the plain x2, x3 etc. filters it's not so important, but it definitely makes sense for the hq filters (and other more advanced filters that might be available now or in the future), so it's mainly a matter of consistency. Though it would also, to my mind, affect screen captures (which should ideally capture it at the effective filtered resolution, but ignore the subsequent window stretching).

Why should you not using your current display resolution?

Wait, are you asking why there should be options for different resolutions at all?

Well, what if some combination of filters gives an effective resolution of 1280x800, maybe that's a resolution supported by my video card/monitor, and I'd rather just set my screen to that mode than have AGS stretch it do a different screen size.

Edit: Another thing we haven't really talked about, but which some emulators support, is to make the game resolution larger than the screen resolution, so that the screen just shows part of the whole graphics canvas (there needs to be a way to scroll around it or zoom back out, obviously). That could be useful if you're on a small screen, like a smart phone.

Also, what if it is not x2 or x3 multiplier, but 1.5 or 3.2 which fits best for your screen?

You set it to whatever is closest and then use the stretch mode to fit it to the screen however you like. With 3.2 I'd probably just set it to x3 centered, but with 1.5 I'd set it to x1 or x2 best proportional fit.

[Crimson Wizard]

But why should I choose a multiplier or resolution at all, if I already know that my desktop resolution is supported by the graphics card?
Can't I just tell: stretch it to current display?

[Snarky]

Can't I just tell: stretch it to current display?

Yes, just leave the filters off, leave the resolution at the default, and set it to stretch or best fit in fullscreen.

But why should I choose a multiplier or resolution at all, if I already know that my desktop resolution is supported by the graphics card?

Well, as mentioned above, what if your screen is slightly larger than 4x, and for optimal crispness you just want to center the 4x graphics on screen without stretching them? Then you need the filter option.

And if you prefer to let the video card handle the stretching rather than AGS (it might use a slightly different algorithm that some might prefer), you need the resolution setting. (Though since it is more of an edge case these days, it might make sense to put it as an advanced option and maybe behind a "force screen resolution" check box or something.)

[Crimson Wizard]

For anyone savvy in 3d graphics out there: if I have a 2d texture rendered in 3d world, and I want it be not stretched to whole screen, does it matter if I change "position" matrix to make it appear "further" from camera, or change "perspective" matrix to make camera "zoom out"? Or is it essentially same thing, the difference is only in which object moves and which stays on same place? I am interested mainly in how it affects rendering speed, does one of those methods make calculations faster/slower, or there's no difference at all?

[Calin Leafshade]

Well you should really be using an orthographic camera so distance from it shouldnt make a difference in rendering size.

If you want to render something at a different size you should change the vertices of the poly.

[Tosek]

I agree to Calin Leafshade.
Ortho is the right way to handle 2d graphics within 3d space. But you can also use the scale component of the object matrix to resize a plane.

[Crimson Wizard]

So, to clarify, I do not touch the projection matrix, but move/scale a plane I render texture on?

[Calin Leafshade]

Yes, providing the matrix is currently an orthographic matrix and not a perspective one. It should be but I remember looking at the D3D code in AGS and it looked like CJ copied it straight from a tutorial or something because it had unrelated comments so it might not be.

[Crimson Wizard]

Thanks!

Woo, its getting shape:



And just for lulz:

[Ali]

Yay!

Any chance of seeing a full-size version of the screenshot?

Sorry to harp on, but would the technique you're working on allow (hypothetically) for scaling down a larger screen size like 1280x or 1920x?

[Dropped Monocle Games]

Sorry to harp on, but would the technique you're working on allow (hypothetically) for scaling down a larger screen size like 1280x or 1920x?

I would also like to know about this! working in a higher res would be amazing
I know I'm pretty new around here but I have big plans on making games in AGS

[Crimson Wizard]

Any chance of seeing a full-size version of the screenshot?

Blackwell Deception (640x480 game) playing on 1680x1050 fullscreen (nearest-neighbour transformation):
http://img827.imageshack.us/img827/4937/qrj3.jpg

Sorry to harp on, but would the technique you're working on allow (hypothetically) for scaling down a larger screen size like 1280x or 1920x?

Nelly 2 playing on 320x240
[imgzoom]http://img842.imageshack.us/img842/3912/8myx.jpg[/imgzoom]

There's still number of issues, both with drawing and mouse cursor position.
And we need to plan how the setup should work.

[Alan v.Drake]

Hooray

[Igor Hardy]

Most impressive.

[Crimson Wizard]

Funny, I found I must set a Viewport for D3D, because otherwise scrolling rooms are drawn on the side borders too, making it visible what shouldn't be .

E: Oh, actually not just scrolling rooms, but anything that goes beyond "border", like moving objects etc. CJ did not use it, because the image was always stretched to whole window.

EE: Also, important note, simply for the record. AGS engine has 2 set of parameters defining screen size: scrnwid & scrnhit, final_scrn_wid & final_scrn_hit. The difference is only that the latter takes side border into consideration. Since now borders are defined by graphics driver/filter, only one pair is needed, the one which defines game size.
The "screen sizes" returned by script functions (GetScreenWidth/Height) are "virtual screen" sizes (which = game resolution), not real window sizes the game is currently running.
While making some experiments I forgot about that, and this resulted in weird misalignment of guis and fonts in several games.
If the script API will ever allow to get real window size, there should be separate set of functions for this.

[Monsieur OUXX]

My idea is to invert the logic of using scaling filters. At the moment the selected scaling filter define final resolution. While it is final resolution that should define which scaling filter to select. Setup should have following options:
- Display resolution
- Fullscreen (yes/no)
- Placement mode:

• Place (just render starting from 0,0)
• Center (center inside window)
• Stretch (stretch to window)
• Best fit (stretch proportionally as much as fits in the window) - this is the default option

- Scaling filter to use if necessary: nearest-neighbour (plain/AA), hq2x, hq3x.

I like your idea.
But as Snarky pointed out, sometimes the choice of the resolution by the player (at least me) is a bit irrational. Especially the zooming level. Sometimes I want to play in window-mode, and I decide sort-of afterwards if I want the game to use up most of the screen (3x) or just part of it (2x).

However I strongly agree that we have to find a way to "hide" those resolution calculations from the player.

Maybe we could have a list of recomended modes (appearing in bold in the list)?

Or have a thumbnail of what the result would look like in the winsetup.exe window? (a bit like in the Display Parameters window of Windows XP -- see the upper part of the screenshot below.) : you'd see a larger rectangle symbolizing the screen, with a message on top of it : "your screen needs to be able to display resolution 1024x768" and a smaller rectangle inside it symbolizing the game window ("the game will appear as a 800x600 window")

[RickJ]

I also like CWs ideas, it is much simpler and much more sane. I think Monsieur OUXX and Snarky are correct in that "you can't please everyone so you have to let them please themselves". 

So instead of junking up CW's clean design why not have a button labeled "Other Options" that opens a little window containing the irrational options.  Just a thought!

[Crimson Wizard]

Basically it is either window size that define scaling or otherwise. But we can have both options.
All we need, IMO, is to add another placement option: "Resize window". When selected, the resolution selection (in setup) will be disabled, and when run, the engine will make the window size = base game size * chosen scaling.
Other options (stretch, center, etc) will work opposite: they will create window of defined size independently of scaling mode, then scale and put a game image inside.

[Crimson Wizard]

Test build (engine only): http://www.mediafire.com/download/4adkw2du7kdj63u/custom_dispres.zip

Related branch: https://github.com/adventuregamestudio/ags/tree/feature_display_resolution
(forked from latest 'master')

I have to apologize, I wanted to make a build with new options in winsetup, but feel too sleepy to write code :p. I am also leaving my city for several days, so I thought maybe I'll upload what I have just to show how it works.
The only way to setup new settings is to write them manually into acsetup.cfg. Put following into "[misc]" category (where you have "gfxdriver", "gfxfilter" and similar stuff):

Code: text

renderstyle=N
// N=0 - center
// N=1 - stretch
// N=2 - stretch proportional (aka "best fit")
// N=3 - resize window - this makes window size equal to (default game size)*(filter scaling).
// if you set renderstyle=3, the following screenwidth and screenheight params are ignored.
screenwidth=X
screenheight=Y
// Where X and Y are wanted window resolutions.

I scrapped most of gfx mode initialization code in the engine, and now it does following:
1. Tries to initialize requested resolution.
2. If failed, looks for the nearest supported resolution in the internal driver list, and tries to initialize it.
3. If failed, tries to initialize originally requested resolution with alternate color depth.
4. If failed, looks for the nearest supported resolution with alternate color depth.
5. If failed, quits with error.
This is good to know, because you may end having different resolution than you asked for. Press Ctrl+V in the game to see system stats - it tells which resolution you are running.
Also, this process is reflected in the game log file (agsgame.log).
Log example:

Spoiler

Switching to graphics mode
Trying gfx mode 320 x 200 (16-bit) fullscreen
Attempt to switch gfx mode to 320 x 200 (16-bit)
Failed, resolution not supported
Attempting to find nearest supported resolution
Trying gfx mode 640 x 480 (16-bit)
Attempt to switch gfx mode to 640 x 480 (16-bit)
Succeeded. Using gfx mode 640 x 480 (16-bit) fullscreen

[close]

Remember, if you are running old games (AGS 2.7 and lower) run new engine's setup program at least once before launching game in this engine - to set graphics driver and other 3.x options properly, otherwise you may get weird results.

Known problems:
OpenGL driver not yet updated, therefore engine ports won't work (or work weird).
Mouse will act annoyingly slow with very small games run non-stretched in large windows; also in proportionally stretched games it may be too slow or too fast moving along one of the axises. I think this needs some kind of automatic fixing + mouse sensivity setup.

[Rulaman]

I didn't read the whole thread, but what about dynamic resolutions?

I mean, I create a room with 1680 x 1024 and on a monitor with this resolution it shows in its original size, but on a monitor with only 1024x1024 (only assumed resolution) it is a scrollable room.

I hope it is clear.

[Crimson Wizard]

I didn't read the whole thread, but what about dynamic resolutions?

I mean, I create a room with 1680 x 1024 and on a monitor with this resolution it shows in its original size, but on a monitor with only 1024x1024 (only assumed resolution) it is a scrollable room.

I think that this is theoretically possible to do, but if ever implemented this must be optional setting either global or per room.
Thing is that in 2-d game the screen size is often deliberately used to limit what player may see. Such as to make whole room cutscenes, or, vice-versa, hide part of room to make surprises for player.

EDIT: But really, this is not so simple anyway. This way GUI will look different depending on display resolution, and many screen-coordinates based calculations will work differently.
This is a very big topic, and should be thoroughly discussed before even thinking about putting it in the AGS.