Other Resolutions.

Started by Calin Leafshade, Sat 29/12/2012 18:09:41

Previous topic - Next topic

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 :D

(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


Crimson Wizard

#8
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

#12
Quote from: Alan v.Drake on Wed 13/02/2013 21:42:03
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

Quote from: Crimson Wizard on Wed 13/02/2013 22:55:46
Quote from: Alan v.Drake on Wed 13/02/2013 21:42:03
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

Quote from: Alan v.Drake on Thu 14/02/2013 06:58:28
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?
What if your blessings come through raindrops
What if your healing comes through tears...

Calin Leafshade

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

Crimson Wizard

Quote from: dbuske on Thu 14/02/2013 17:40:37
Calin, Have all your plug-ins been included in the current version of AGS?
Quote from: Calin Leafshade on Thu 14/02/2013 17:43:58
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.


Quote from: Alan v.Drake on Wed 13/02/2013 21:42:03
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...


Quote from: Calin Leafshade on Fri 01/02/2013 17:26:12
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.

SMF spam blocked by CleanTalk