[TEST] Custom Resolution build (based on 3.3.0 / 3.3.1)

[Crimson Wizard]

what i meant is if i use a background of the same resolution as i set in "acsetup.cfg", but its not the resolution that is set in the general settings, the background and sprites got distorted (e.g.: even in window mode it did show just a part of the background and upscaled version of sprite). However i tried it now again with 1600x800 resolution and in window mode it worked fine but with fullscreen renderstyle=2 it stretched the width of the view beyond my display while the height was shorter then height of my display, it worked as a scrollable background.

Wait...umm, I am not sure I understand this right.
If you mean that in general settings you have one resolution, like 800x600, and in "acsetup.cfg" you set higher resolution, like 1280x720, and have a room background 1280x720, then that room will indeed become a scrolling room, and only 800x600 part should be displayed at all times.
The resolution you type in "acsetup.cfg" does not change anything to game or room size, it is simply a size of the window. The viewport size (the visible piece of the game) should always stay the same - equal to game size as set in general settings.

In case I am mistaken, can you give more details, like which resolutions do you set everywhere? Also screenshots may really help.

[LameNick]

aah, so all the screenwidth/height feature does, it stretches the window in window mode to that particular resolution while the viewport stays at the resolution set in general settings? then in this particular case it was doing what it was supposed to do except that renderstyle=0 doesn't work. I'm sorry, my brain is slow sometime although i don't understand very much now what is it good for if it just changes the window size while the game view has its own setting..

[Crimson Wizard]

although i don't understand very much now what is it good for if it just changes the window size while the game view has its own setting..

There are three settings:
1. Game size, which determines the base size of the game view.
2. Window size.
2. Final game view size inside the window, which determines how game view is positioned in the window. This one cannot be set directly, but calculated from number of parameters, like scaling filter, "renderstyle" option, etc.

Imagine there's a 320x200 game, and you have a 1920x1200 desktop. If you will run the game in the window using its base resolution then the window will be too small on your large monitor. Here is where scaling comes, to scale the game up to certain degree. For example, you can scale game x6, and the result will be exactly your desktop resolution, thus game will cover the whole screen.
Now, if the game is not 320x200, but 320x240, scaling to maximal size will make game appear stretched horizontally, because its size has different ratio than your desktop size. Here is where "renderstyle" comes: instead of stretching the game view to maximal possible, "renderstyle=2" stretches it proportinally, possibly leaving black borders around.

In this case the "rectangle" (4:3) game on the widescreen monitor will look like this:

Spoiler

[close]

And the "wide" (16:10 or 16:9) game on the 4:3 monitor will look like this:

Spoiler

[close]

[Crimson Wizard]

I decided to make up a summary of the plans for the custom resolutions build in regards of the display modes. Many of the following is already featured, other things are yet to be implemented.
It would be nice to know opinions - does this all sounds proper?

The display mode is specified by the combination of the following parameters:

1. Original game resolution, or Viewport size.
2. Window size or fullscreen resolution ("window size" for simplicity).
3. Viewport position and scaling. I am calling the resulting rectangle a "Render Frame", or "Drawing Frame", internally.

Here's basic illustration to how it works:

Spoiler

[close]

When the window is created, the game view is positioned/scaled inside according to some rules, making a "render frame".

Window.
The window is defined by size (width * height).
Window may be:
- fullscreen;
- plain window with border and caption (classic windowed mode);
- desktop-sized borderless window; although covering all screen, this is not an exclusive fullscreen mode and it may be generally easier for graphics card to handle one (although the rendering may be sometimes slower relative to fullscreen).

Window size can be determined either by directly setting width & height, or by following scaling filter settings.
In the latter case the window size will be recalculated as a (game size * scaling level), so the window is trying to match the supposed game view size.
Separately there's an option to Keep desktop ratio: as an alternative this mode will recalculate window size, but then correct it to make it match your desktop resolution's aspect ratio. This option have meaning only for fullscreen.
The desktop-sized borderless window is always the same resolution as the desktop.

Game viewport position.
Render frame is defined by scaling and positioning inside the window.
The scaling is a combination of selected graphics filter and a final stretching (applied only when necessary) done in a way specific for every driver (e.g. nearest-neighbor for software driver).

The render frame may be positioned in three different ways:
- Center: the scaling filter is applied (if any), then the result is centered inside the window. If no filter was selected, the game will appear unscaled*. This may cause black borders appear around the game view.
* "Unscaled" game will look larger or smaller depending on desktop resolution, also if a fullscreen mode is used, you will receive different visuals depending on fullscreen resolution. But technically it is the graphics card and/or monitor that scale the picture on their own.
- Stretch: the scaling filter is applied (if any) and then the result is stretched or squeezed to fill precisely the window. This may cause visuals to degrade, if the window size have different aspect ratio than the game size (the game may appear stretched horizontally or vertically).
- Proportional stretch (aka "Best fit"): the scaling filter is applied (if any) and then the result is stretched or squeezed to fill the maximal available space inside the window, while maintaining the original game's aspect ratio. This may cause either horizontal or vertical black borders appear (but not both).

Following are illustrations to these three options:

Spoiler

[close]

WinSetup usability.
The average user usually won't care about how these things work internally, he will want a simple dialog to set up visuals he wants. The question is how to present him all these options.
This is what I came up with so far (WARNING: this is a dirty mockup):

Spoiler

[close]

First the user choses the window mode: fullscreen / windowed / fullscreen window (better name anyone?).
Then user decides to either set precise window resolution or game scaling.

A. If user wants to set window resolution, a resolution list activates.
The "Keep game ratio" check serves as a switch between "stretch" and "proportional stretch" modes.
Filter selection is active, but the scaling level is not enabled for filters that support free scaling level (like nearest-neighbor and anti-aliased-nearest-neighbor), because the stretching will be done to max allowed by window size anyway.
Setting filter to "None" will basically make game appear centered in the window, if it fits, or scaled down proportionally if it does not.

B. If user wants to set scaling filter, a resolution list is replaced by a read-only label, that will display the calculated window resolution.
The "Match desktop ratio" check is self-explanatory.
Filter selection is active and a scaling level can be set either to one of the predefined values, or to custom level (if filter supports this).



The configuration file may still be edited by hand, or by custom setup program, to set more exotic combination of options.
The options are following:

Spoiler

gfx_driver - defines driver id

gfx_mode - defines the base mode
  gfx_mode=fullscreen
  gfx_mode=windowed
  gfx_mode=fullscreen_windowed

window_def - defines how window is determined
  window_def=resolution
  window_def=scaling

window_width - set window width
window_height - set window height

gfx_filter - defines the filter name

gfx_scaling_both - custom scaling multiplier
gfx_scaling_hor - separate horizontal scaling
gfx_scaling_ver - separate vertical scaling

match_desktop_ratio - defines whether window's aspect ratio must match desktop ratio

game_frame - defines the positioning of the render frame inside window:
  game_frame=center
  game_frame=stretch
  game_frame=proportional

[close]

[AGD2]

This all sounds pretty good to me! Out of curiosity, would the following things be rolled into the same release?

-Rename winsetup to something else
-Ability to change all of the aforementioned options from within the game itself at run-time (so the end user doesn't need to tinker with an external setup program)
-Ability to drag the corner of the window so that the game window size can be scaled in real-time

[Crimson Wizard]

-Ability to drag the corner of the window so that the game window size can be scaled in real-time

I just got a email from BigMC, who has information about one guy introducing this feature for Allegro library.

[LameNick]

cannot wait till its released
i'd like to ask the highest game viewport resolution will be 1280x720?

[Crimson Wizard]

By Ali's request, here's an updated version of the build:
(Fixed version reuploaded 20 november)
http://www.mediafire.com/download/6yk5jmo1xlurfah/CustomRes_Beta10.7z

Copy this over 3.3.0 beta 10 (can be found here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47966.0)

Not thouroghly tested yet, but I will fix any critical bugs found.

Please, take into consideration that custom game resolutions are still experimental. Some things are made for the sake of speed and will be redone in future. (That is also the reason I do not publish the source code for this feature).
Aside from that, the build is based on 3.3.0 Beta 10 and custom display resolution feature (which should probably work).

@LameNick: I found few mistakes in the previous version, which could cause weird effects, but only if the combination of parameters in config file was invalid. I could not reproduce the crash you reported (with "renderstyle=0"). Please tell, if this version works better for you.

//--------------------------------------------------------
What has changed:

In the Editor:
The Resolution option in General Settings now works differently: you do not select the size from drop-down list, but click on the "..." button to the right. This will open a dialog window, where you do your selection.
Why: at first I was considering doing this similar to SkyGoblin's build: he made new "custom size" property that would appear under "Resolution" if you select "Custom" in the list. Problem is, however, that if you type Width and Height separately, the editor will try to update rooms & guis in between those changes, which is very annoying.


In the Engine's config file:
"renderstyle" is now a string parameter, valid values are:
- "center",
- "stretch",
- "proportional",
- "resizewindow"
Added "match_desktop_ratio" parameter to substitute "letterbox" and "sideborders" from original config. It works only for fullscreen.

Examples of manual display mode setting:

Code: text

gfxDriver=D3D9
windowed=0
screenwidth=1920
screenheight=1080
renderstyle=proportional

This will create 1920x1080 fullscreen and scale the game to max fitting size proportionally (keeping its aspect ratio).

Code: text

[misc]
gfxDriver=D3D9
windowed=0
gfxFilter=StdScale4
renderstyle=resize
match_desktop_ratio=1

This will scale the game x4 using nearest-neighbour filter. The fullscreen mode will try to take resolution that both contains scaled game size and matches your desktop aspect ratio.


//-----------------------------------------------
UPDATE: reuploaded the build with couple editor bugs fixed (related to the property editing).

UPDATE 2: reuploaded again, this time fixed a bug in the engine which occured if using low resolutions.



Just for lulz, the 200x800 game:

Spoiler

[close]

[Ali]

This looks fantastic! I'll be playing around with it in the next couple of weeks.

[miguel]

It does look great!
Thank you Crimson and everybody else who's working on it!

[Daniel Eakins]

Thank you

[LameNick]

Awesome! Works nicely so far, one more stupid question though: is there no way for it to recognize the monitor's resolution? does screenwidth/height in the acsetup.cfg always need to be edited when the game is played on different monitor setup?

[Crimson Wizard]

Awesome! Works nicely so far, one more stupid question though: is there no way for it to recognize the monitor's resolution? does screenwidth/height in the acsetup.cfg always need to be edited when the game is played on different monitor setup?

I am supposed to rewrite the setup program when I get time, in plans it should display a list of resolutions supported by your gfx card.

At the moment you can type in some ridiculously large number (like 5000x5000) and the engine will likely lower that down to the nearest supported, as it does when it cannot apply the given one.

[David Ostman]

EDIT: Actually I just tested it and it seems to be doing what I'm asking about

This is a huge step in the right direction, thanks for working on it CW!

I was thinking.. With custom resolution would I be able to enter some arbitrary resolution that "doesn't exist", like 320x180 which is 16:9? So when I scale up I'd end up at 640x360, 1280x720, 1920x1080. The two latter are well known and used resolutions, but the three other aren't ever used natively on normal consumer displays, are they?

So for example in the case of someone still running a 1024x768 resolution would it just take that 320x180, set the game's resolution natively at 1024x760, and scale up the content as much as possible without going above 1024x768 in any one or both direction, like so:



Right now I'm developing for 640x400 which is 16:10 ratio, but I'd rather use 640x360 and a 16:9 ratio so I always get a case of horizontal bars.



... and never, ever end up with a (to me) unacceptable case of vertical bars.

[Crimson Wizard]

I was thinking.. With custom resolution would I be able to enter some arbitrary resolution that "doesn't exist"

Yes.

I posted a 200x800 example few posts above:
http://img607.imageshack.us/img607/7669/528s.png

This still needs testing though, there are many hacks in AGS, I have a slight fear they may screw things on some cases.

[David Ostman]

I started a little side project a week ago (that's just meant to be a tiny palate cleanser as I'm so sick of my main project at this point) so I'll take the chance with it and perhaps I'll be able to ferret out a few issues with it in the process. Of all the improvements and features I've read about lately this one is of most interest to me so I don't mind messing around with it quite a bit.

EDIT: Oh, I realize now I was sloppy reading through your posts above which made my previous post redundant, so sorry about cluttering up the thread.

[Ali]

I've done a little experimenting, and have spotted a few issues and made some observations. Many of them are probably things your aware of:

Room Editor
With a large room/character, but game resolution still set to 320x200, the selection box for a character is half the size it should be.
Needs zoom out option for comfortable working.
Import BG automatically zooms in. Not appropriate for high res

GUI Editor
Needs scrolling/zoom out option for large GUIs.

Aesthetics
Character scaling is not at all smooth with large sprites. You can see the jumps very badly. Would it be possible for scaling to work with floats rather than integers, if you see what I mean?
As I'm sure you know, down/upscaling would look much better with sampling.
Working Vsync would really improve things.

View:
Create Subfolder option collapses the tree - possiblty a 3.30 issue?

Misc
This might just be me, but the mouse sensitivity seems very high when full screened - this is scaling 1920x1080 down to 1600x900, so still pretty large.
The option "Fonts designed for 640x..." - is no longer really meaningful and should be changed to something that new users could understand.

[Crimson Wizard]

Quite a few things should be redesigned. For example, "Fonts designed for XX" could be replaced by more clear "scale factor". Same for sprites, probably.

[Knox]

Hey Crimson, any idea when the newest changes to 3.3.0 beta10 can be applied to this Custom Resolution Build?

[Crimson Wizard]

Hey Crimson, any idea when the newest changes to 3.3.0 beta10 can be applied to this Custom Resolution Build?

There were not much changes recently, mostly updates for safer play on Linux and minor bug fixes, I do not think there's any urgency in this. What do you have in mind?