3.3.0 update: improved display resolution selection

[Crimson Wizard]

First of all, I apologize for closing previous thread with this name (I asked mods to delete it). I've had numerous issues with the first version of this build and got very upset, thinking that I won't be able to deal with all the hacks in AGS code related to letterboxing.

After some time I saw that probably it is possible to fix them. So, I am reposting the improved version of the build.

//---------------------------------------------------------------------

This is a test build with improved display resolution setting, based on latest 3.3.0.
This version is some kind of "intermediate" between 3.2.1 and custom resolutions. It features a relatively free window resolution. Since everything related to graphics is pretty fragile in AGS, and this is supposed to be an update over current release, rather than completely new version, I tried to keep changes to minimum.
Yes, I moved from "hotfix" idea to "update", because this is really can't be viewed as a hotfix anymore.

http://www.mediafire.com/download/rdzu8zaacmt2065/ags_3.3.0_scaling_update.7z

Git branch: https://github.com/ivan-mogilko/ags-refactoring/tree/update_scaling

This includes only acwin.exe to replace the one in 3.3.0 installation.

Now in master branch:
http://www.mediafire.com/download/5a67mvl0d63i416/AGS-3.3.0.zip

Please, do not use this for your actual game release yet. It must be tested first.
I ask anyone who has little time to test if that works for any game resolution / display resolution combinations.

What it does (in theory):
1. It should support running game at almost any resolution, provided that a) the resolution is not smaller than scaled up game, and b) its sizes are multiplies of scaling multiplier.
For example, if game scaling is 4, then window sizes should be multiplies of 4. If scaling is 3, window sizes should be multiple of 3, etc.
This restriction is implied by how black borders (letterboxing/sideborders) work in original AGS.
If scaling is 1 (no filter), window can have any size (I think).
2. It should automatically find maximal supported nearest-neighbour scaling, if the requested scaling failed. In any case it searches for all combinations of sideborders/letterbox (depending on setup options). Therefore if you computer supports just any resolution equal or larger to game size, AGS must find and use one. Resolutions with desktop aspect ratio are given higher priority.
3. Writes bit more interesting stuff to the log.

What it does not:
1. It does not allow absolutely free window size selection.
2. It does not allow non-integer scaling.
3. It does not allow downscaling.
4. It does not allow to explicitly choose position of the game inside window (proportional, stretched, centered, etc) - this is defined only automatically.
5. This has nothing to do with custom game resolutions.

//---------------------------------------------------------------------

Known issues:
1. Resolution selection now works differently, and you may sometimes get surprised by results; for example, you may get a small "boxed" game inside a larger fullscreen without expectation. Well, this is not really a bug, yet needs to be checked, to know if people are generally ok with that.
This is "cured" by disabling sideborders and removing "force letterbox" check in winsetup.
2. This is rather related to old AGS logic, but if "Force letterbox" is not checked, engine always looks for non-letterboxed resolution first, and the game may end up stretched to fullscreen, breaking aspect ratio, even though there may be more correct resolution available.
3. Proper letterboxing is disabled in winsetup for 800x600 and 1024x768 now, I need to fix this; but it should generally work: you may put "forceletterbox=1" into setup file.
4. Sometimes the part of cursor may be drawn above borders.


What needs to be tested:
1. All game resolutions / scaling combos.
2. Room transitions, especially fade-in/fade-out.
3. Scrolling rooms.
4. Built-in dialogs (default quit/load/save dialogs).

[Gurok]

Hey, CW, is it possible for me to make an updated version of 3.3.1 with this resolution selection stuff in it? I might be able to help test it, but my game uses text window padding. Is there a branch or is it just a matter of grabbing the most recent commits from master?

[Crimson Wizard]

Hey, CW, is it possible for me to make an updated version of 3.3.1 with this resolution selection stuff in it? I might be able to help test it, but my game uses text window padding. Is there a branch or is it just a matter of grabbing the most recent commits from master?

I would not want to post it in official repository right away, because the code is raw, and I still have slight doubts in approach.
I will make a feature branch in my personal repository, and possibly another test branch that merges 3.3.1 in. I'll do that later today.

[Crimson Wizard]

Created branch: https://github.com/ivan-mogilko/ags-refactoring/tree/update_scaling

It can be merged to 3.3.1, but you'll have to resolve couple of simple conflicts first (parameters to GraphicsDriver::Init call and to error message).

[Crimson Wizard]

Uploaded slightly updated version, now can run all games letterboxed.
http://www.mediafire.com/download/7wepvs1339utl8a/acwin_3.3.0_scaling_update.7z

I'd liked to hear any feedback about how this works.

[Gurok]

I tried merging this into 3.3.1, but I'm getting crashes and errors saying that a resolution of 0x0 can't be initialised when running it full screen. Running in a window is fine though.
It's probably my fault. I don't know if I did the correct thing when merging it or not.
This is my branch: https://github.com/gurok/ags/tree/331_alpha1proposal
It's 3.3.1 + the master + your branch.
I checked out your branch, edited the files that had conflicts, added them to the commit, then committed and pushed the whole thing to my branch.
I'm not asking for your help. I just wanted to cry a bit because I can't figure out what's wrong.

[Radiant]

Uploaded slightly updated version, now can run all games letterboxed.
http://www.mediafire.com/download/7wepvs1339utl8a/acwin_3.3.0_scaling_update.7z

Is this the same as hotfix 2 from the main release thread?

[Crimson Wizard]

I tried merging this into 3.3.1, but I'm getting crashes and errors saying that a resolution of 0x0 can't be initialised when running it full screen. Running in a window is fine though.
It's probably my fault. I don't know if I did the correct thing when merging it or not.
This is my branch: https://github.com/gurok/ags/tree/331_alpha1proposal
It's 3.3.1 + the master + your branch.
I checked out your branch, edited the files that had conflicts, added them to the commit, then committed and pushed the whole thing to my branch.
I'm not asking for your help. I just wanted to cry a bit because I can't figure out what's wrong.

Just built your branch, works well for me. Can you show the config file you are using? Maybe some combination of options leads to this.
You can also run with "--log" parameter to get a log file.

Uploaded slightly updated version, now can run all games letterboxed.
http://www.mediafire.com/download/7wepvs1339utl8a/acwin_3.3.0_scaling_update.7z

Is this the same as hotfix 2 from the main release thread?

No, it's slightly below. It is not meant to be used in real game yet, but that won't be a problem to upgrade it to hotfix-2 if this is really important.

[Crimson Wizard]

I tested this more, and it seems to work.
I'd really love to hear ANY feedback.

[Radiant]

Testing now...

Scale x2, no side borders. Chosen gfx resolution: 640 x 480 (32 bit), game frame: 320 x 240. That works since my monitor doesn't run in 640x400.
Scale x2, side borders. Game ends up running on a 1280 x 720 screen with the game in 640 x 360. That's weird, I'd expect it to be 640x400 (perhaps the logging is wrong or the 'game frame' doesn't mean what I think?) I suppose the big black borders are because my monitor doesn't support intermediate resolutions.
Scale max, side borders. Chosen gfx resolution: 1920 x 1080 (32 bit), game frame: 384 x 216. Again I'm not sure where the game frame comes from, but it launches well and does get side borders as expected.

Scale max, no side borders. Game fails to launch,

Spoiler

msg:
There was a problem initializing graphics mode 0 x 0 (32-bit) with game size 320 x 200 and filter 'Undefined'.
(Problem: 'Failed to find acceptable graphics filter')

log:
Built library path: d3d9.dll
Created graphics driver: Direct3D 9
Initializing screen settings
Game native resolution: 320 x 200 (32 bit), letterbox optional, side borders disabled
Initializing gfx filters
Couldn't find any supported uniform scaling for game size 320 x 200 (32 bit)
Init gfx driver
Created graphics driver: Allegro/DX5
Initializing screen settings
Game native resolution: 320 x 200 (32 bit), letterbox optional, side borders disabled
Initializing gfx filters
Couldn't find any supported uniform scaling for game size 320 x 200 (32 bit)

[close]

So we're getting close, I think Thank you for your time!

[Crimson Wizard]

Scale x2, side borders. Game ends up running on a 1280 x 720 screen with the game in 640 x 360. That's weird, I'd expect it to be 640x400 (perhaps the logging is wrong or the 'game frame' doesn't mean what I think?)

In contrary to real "custom resolutions" build, game frame here is a (game size + size of borders) before scaling. That's because the borders are drawn not by graphics renderer, but by room drawing routine.
640x360 is a game + borders, and 1280x720 is this (game + borders) x 2 scale. It works like that.

Scale max, no side borders. Game fails to launch,

Spoiler

msg:
There was a problem initializing graphics mode 0 x 0 (32-bit) with game size 320 x 200 and filter 'Undefined'.
(Problem: 'Failed to find acceptable graphics filter')

[close]

Hm, I see two problems here:
1) it did not find supported resolutions, which should not normally happen, knowing that "Scale x2, no side borders" worked well. But this happens if sideborders are disabled, so it's theoretically possible that there's simply no matching resolution. I wonder what the game should do in such case: should it override user request and try sideborders, or just quit?
2) it displays incorrect error message (should tell about not being able to find resolution).

[Radiant]

1) it did not find supported resolutions, which should not normally happen. But this happens if sideborders are disabled, so it's theoretically possible that there's simply no matching resolution. I wonder what the game should do in such case: should it override user request and try sideborders, or just quit?

Well, the engine also overrides e.g. the graphics driver (using Dx5 if Dx9 doesn't work), so it should also override the sideborders in this case. After all, it's better for the user to get a slightly different resolution, than for the game to abort.

Also note that the earlier build (log H) did run with max scaling/no borders.

[Crimson Wizard]

The max scaling algorythm had a mistake in searching modes without borders. Now fixed:
http://www.mediafire.com/download/c937rks93m8rnr4/acwin_3.3.0_scaling_update.7z

[Radiant]

Ok, testing again.

Scale x2, no side borders same as yesterday.
Scale x2, with borders same as yesterday.
Max scaling, no side borders now works.
Max scaling with borders however no longer works: it plays the game fine, but doesn't show the side borders. This did work in yesterday's version.

Spoiler

Created graphics driver: Direct3D 9
Initializing screen settings
Game native resolution: 320 x 200 (32 bit), letterbox optional, side borders enabled
Initializing gfx filters
Requested gfx filter: max
Chosen gfx resolution: 1280 x 800 (32 bit), game frame: 320 x 200
Applying scaling filter: StdScale4
Switching to graphics mode
Attempt to switch gfx mode to 1280 x 800 (32-bit) fullscreen, game frame 320 x 200, gfx filter: StdScale4
Succeeded. Using gfx mode 1280 x 800 (32-bit) fullscreen, game frame 320 x 200, gfx filter: StdScale4
Preparing graphics mode screen

[close]

[Crimson Wizard]

Max scaling with borders however no longer works: it plays the game fine, but doesn't show the side borders. This did work in yesterday's version.

You should run with "force letterbox", otherwise it first finds available non-letterboxed mode, which not necessarily matches desktop ratio.

[Radiant]

Ok, I'll try that. What exactly is a "letterboxed" mode, though?

[Crimson Wizard]

Ok, I'll try that. What exactly is a "letterboxed" mode, though?

Erm.
Letterboxed = top & bottom borders.
Siderborders = left & right borders.

(I thought you guys know those things better, you are making games since early 2000-ies ).

[Radiant]

Wait, so if I enable "letterbox" then I get borders to the side but not to the top/bottom, and if I disable it I get no borders anywhere even though I still asked for side borders. Huh?

[Crimson Wizard]

Wait, so if I enable "letterbox" then I get borders to the side but not to the top/bottom, and if I disable it I get no borders anywhere even though I still asked for side borders. Huh?

Force Letterbox    => enabled  => try all resolutions, regardless of whether they are with top & bottom borders or not.
                          => disabled => try resolutions without top&bottom borders first, then, if failed, - ALL the rest.

Enable Sideborders => enabled => try all resolutions, regardless of whether they are with side borders or not.
                          => disabled => try only resolutions without side borders

Don't force letterbox, disable sideborders: look only for resolutions that allow to scale game without side-borders, first check non-letterboxed ones, then, if failed, - letterboxed ones.
Force letterbox, disable sideborders: look only for resolutions that allow to scale game without side-border, regardless of whether they need top&bottom borders or not.
Don't force letterbox, enable sideborders: look for ALL resolutions, but first check non-letterboxed ones, then, if failed, - letterboxed ones.
Force letterbox, enable sideborders: look for ALL resolutions.


This was in AGS for all those years btw.

Okay, I must admit that letterbox switch now works partially differently. In fact it does not make real sense anymore . Maybe change it to "enable/disable letterbox" instead of "force/don't force"?

[Radiant]

Yes, it was in AGS for a long time, but it didn't actually work until you fixed it

[Radiant]

Yes, it would be nice if these two options worked similar. So that would mean renaming force letterbox to "enable" (and maybe call it top/bottom borders instead of letterbox), and it would be nice if disabling sideborders would try the resolutions without borders first, and if failed try all the rest (just like how disabling letterboxing works now). And maybe make these the top two under 'graphics options' so that they're adjacent to one another.

[Crimson Wizard]

Yes, it would be nice if these two options worked similar. So that would mean renaming force letterbox to "enable" (and maybe call it top/bottom borders instead of letterbox), and it would be nice if disabling sideborders would try the resolutions without borders first, and if failed try all the rest (just like how disabling letterboxing works now). And maybe make these the top two under 'graphics options' so that they're adjacent to one another.

Yes, I agree it is a right thing to do, because "force letterbox" now works in a more "liberal" way (prior to these changes this option really forced borders, now it simply allows them).

[Gurok]

Can we call "sideborders" pillarboxing? That's the official term. From what CW has posted about the algorithm, it sounds like "prefer letterboxing" or the inverse "avoid letterboxing" might be appropriate verbs.

I think I was encountering that same 0x0 error too. I'll update from your branch when I get a chance and do some more testing.

[Radiant]

Can we call "sideborders" pillarboxing? That's the official term.

I'd rather not, as I've never heard of that and it barely even shows up on google. I'd prefer a clear and widely-used term over an "official" one.

[Gurok]

Can we call "sideborders" pillarboxing? That's the official term.

I'd rather not, as I've never heard of that and it barely even shows up on google. I'd prefer a clear and widely-used term over an "official" one.

I don't know if that's a good test or not. I mean, try applying that test to the term "side borders". I have no trouble finding pillarboxing and letterboxing. I guess our mileage differs.

Ehh... I'm not trying to start a fight. If people love "side borders", I guess it's not that bad.

Do we even need these options? Pillarboxing is the least desirable effect. A screen that's filled with content is most desirable. Is this perhaps just a question of picking an order in which to do things and removing the configuration options?
1. Try all video modes without tolerating letterboxing or pillarboxing
2. Try all video modes tolerating letterboxing
3. Try all video modes tolerating letterboxing and pillarboxing
Similar to, but not quite that same as "Don't force letterbox, enable sideborders" under the current schema. Perhaps that's too narrow an approach. I might just not be seeing the use case for those options. If you end up with a video mode that has non-square pixels, I guess it would throw things out a bit.

[Radiant]

Do we even need these options?

I think that's a very good question.

As far as I can tell, there are two kinds of players here. One kind prefers to have a full screen without any borders, and one kind that prefers to retain the game's aspect ratio (and, of course, there's a third kind who doesn't care either way). Since AGS games run in 16:10 aspect ratio and most contemporary monitors are 16:9, the second kind of player likes to have borders. I believe top/bottom borders are a remnant from the time when most monitors were 16:12, and most people probably haven't used that option for several years.

[Problem]

Pillarboxing is the least desirable effect. A screen that's filled with content is most desirable.

I have to disagree here. As a player I have no problem with small sideborders, but I don't like it at all when the graphics are stretched in an unnatural way just to fit the screen size, it just looks wrong.
So there should always be an option to keep the correct aspect ratio that will use sideborders to prevent distorted graphics.

[Crimson Wizard]

First, please keep in mind, that this is an intermediate state. Custom resolutions feature will have slightly different options: no division between vertical & horizontal borders, but a choice between "stretch", "proportional stretch" and "place in center", with last two allowing borders (these options could be presented differently on setup dialog).

Second, I believe options do not hurt anyone, because they are options.

Third, I myself hate playing a stretched game, it hurts my eyes and feelings .
I am a happy owner of a wide-screen 16:10 monitor with built-in "4:3" mode support that creates "pillarboxed" image on hardware level (I think). And I was very glad to find a device with such feature, because it lets me to play old 4:3 games in their original look.

[Gurok]

Oh whoops. I definitely hate distorted aspect ratios too. In my mind, if there were no options to toggle it, the aspect ratio would always be preserved. The coming custom resolutions version sounds like it has a much more sensible set of options anyway.

[Adeel]

Can we call "sideborders" pillarboxing? That's the official term.

I'd rather not, as I've never heard of that and it barely even shows up on google. I'd prefer a clear and widely-used term over an "official" one.

Or perhaps, we should go full retard and collectively name 'pillarboxing' and 'sideboxing' as: 'ugly-black-boxing'

[Crimson Wizard]

Updated with 3.3.0 hotfix-2:
http://www.mediafire.com/download/rdzu8zaacmt2065/ags_3.3.0_scaling_update.7z

Please, test again if that works (it has slightly modified code).

By the way, Gurok, did it work for you? I'd really wish to know. I've recreated the branch in my repository, but it still has same name.

1. Try all video modes without tolerating letterboxing or pillarboxing
2. Try all video modes tolerating letterboxing
3. Try all video modes tolerating letterboxing and pillarboxing

It now does about that.

[Radiant]

Ok, I'm a bit confused now what does what. The options are still called "side borders on widescreen monitors" (does this actually detect whether a monitor is widescreen?) and "force alternate", but apparently they've changed now? It would help if these options were worded in the same way and were placed adjacent in the setup screen.

[Crimson Wizard]

EDIT: deleted.
I will update soon.

UPD:
http://www.mediafire.com/download/rdzu8zaacmt2065/ags_3.3.0_scaling_update.7z

[Radiant]

Thanks, that's much clearer. So if I understand correctly, if borders are enabled then AGS will attempt for a resolution with borders first, and if none are found, it will find a resolution without borders; whereas if borders are disabled then AGS will only look for resolutions without borders. Is that correct?

[Crimson Wizard]

Thanks, that's much clearer. So if I understand correctly, if borders are enabled then AGS will attempt for a resolution with borders first, and if none are found, it will find a resolution without borders; whereas if borders are disabled then AGS will only look for resolutions without borders. Is that correct?

No. It will look for all resolutions always, as was requested, so that SOME resolution is found in the end.

If borders option is enabled: it will look for resolution with or without borders, the one that matches better. The desktop aspect ratio is preferred.
If borders option is disabled: it will look for resolution without borders first, and for resolution with borders only if failed.

[Gurok]

Okay, I did a re-merge. Now I get a crash trying to initialise a high (16-bit) colour game. Let me know if you need more info.

Spoiler

>   acwin.exe!AGS::Common::Bitmap::GetColorDepth()  Line 101 + 0x3 bytes   C++
   acwin.exe!prepare_characters_for_drawing()  Line 1858 + 0x15 bytes   C++
   acwin.exe!draw_screen_background(AGS::Common::Bitmap * ds=0x034867a8)  Line 2123   C++
   acwin.exe!construct_virtual_screen(bool fullRedraw=false)  Line 2543 + 0x9 bytes   C++
   acwin.exe!render_graphics(AGS::Engine::IDriverDependantBitmap * extraBitmap=0x00000000, int extraX=0, int extraY=0)  Line 2575 + 0x7 bytes   C++
   acwin.exe!game_loop_do_render_and_check_mouse(AGS::Engine::IDriverDependantBitmap * extraBitmap=0x00000000, int extraX=0, int extraY=0)  Line 566 + 0x11 bytes   C++
   acwin.exe!mainloop(bool checkControls=true, AGS::Engine::IDriverDependantBitmap * extraBitmap=0x00000000, int extraX=0, int extraY=0)  Line 717 + 0x11 bytes   C++
   acwin.exe!main_game_loop()  Line 840 + 0xd bytes   C++
   acwin.exe!do_play_game()  Line 143   C++
   acwin.exe!initialize_start_and_play_game(int override_start_room=0, const char * loadSaveGameOnStartup=0x00000000)  Line 182 + 0x5 bytes   C++
   acwin.exe!initialize_engine(int argc=1, char * * argv=0x00970490)  Line 1467 + 0x12 bytes   C++
   acwin.exe!_mangled_main(int argc=1, char * * argv=0x00970490)  Line 488 + 0xd bytes   C++
   acwin.exe!__WinMain()  + 0x216 bytes   C

[close]

Spoiler

AGS: Created graphics driver: Direct3D 9
AGS: Initializing screen settings
AGS: Game native resolution: 320 x 200 (16 bit), letterbox optional, side borders enabled
AGS: Initializing gfx filters
AGS: Requested gfx filter: max
AGS: Chosen gfx resolution: 1600 x 1000 (16 bit), game frame: 320 x 200
The thread 'Win32 Thread' (0x146c) has exited with code 0 (0x0).
AGS: Applying scaling filter: StdScale5
AGS: Switching to graphics mode
AGS: Attempt to switch gfx mode to 1600 x 1000 (16-bit) windowed, game frame 320 x 200, gfx filter: StdScale5
'acwin.exe': Loaded 'C:\Program Files (x86)\NVIDIA Corporation\3D Vision\nvSCPAPI.dll'
AGS -- InitializeD3DState()AGS: Succeeded. Using gfx mode 1600 x 1000 (16-bit) windowed, game frame 320 x 200, gfx filter: StdScale5
AGS: Preparing graphics mode screen
AGS: Initializing colour conversion
AGS: Check for preload image
AGS: Initialize sprites
AGS: Set up screen
AGS: Initialize game settings
AGS: Prepare to start game
AGS: Audio is processed on the main thread
AGS: Cursor mode set to 0 ()
AGS: Checking replay status
AGS: Engine initialization complete
AGS: Starting game
AGS: Cursor mode set to 0 ()
AGS: Playing music 0 ()
AGS: Game speed set to 40 (G 32)
AGS: Loading room 1
AGS: Mouse bounds constrained to (0,0)-(319,199) ()
AGS: Now in room 1 ()
First-chance exception at 0x00bdc836 in acwin.exe: 0xC0000005: Access violation reading location 0x00000000.
Unhandled exception at 0x00bdc836 in acwin.exe: 0xC0000005: Access violation reading location 0x00000000.

[close]

It is better though! I managed to run a windowed/full-screen 32-bit colour game!

[Crimson Wizard]

No. Something is very wrong with this version. It displays a weird black strip across the screen in fullscreen mode. I need to fix this.
E: this occurs only for 640x480 and 320x240 games.

Also, 16-bit games run fine for me.
The error like that usually happen if you build both Editor and Engine, then start engine having output folder as a working dir: the engine then accepts generated default "acsprset.spr" as a resource for your game, and fails to load sprites.

[Radiant]

No. It will look for all resolutions always, as was requested, so that SOME resolution is found in the end.

If borders option is enabled: it will look for resolution with or without borders, the one that matches better. The desktop aspect ratio is preferred.
If borders option is disabled: it will look for resolution without borders first, and for resolution with borders only if failed.

Excellent. Thank you very much!

[Crimson Wizard]

Fixed two bugs, mostly related to 640x480 games:
http://www.mediafire.com/download/rdzu8zaacmt2065/ags_3.3.0_scaling_update.7z

E: Now that I notice this, mediafire.com allows to replace file while keeping original share link... good to know.

[Gurok]

Also, 16-bit games run fine for me.
The error like that usually happen if you build both Editor and Engine, then start engine having output folder as a working dir: the engine then accepts generated default "acsprset.spr" as a resource for your game, and fails to load sprites.

Right you are. Ignore me and my flawed testing process then. :/ I've now tested it outside of the build folder and everything appears to be working well.

[Radiant]

Testing now...

Scale x2, no side borders. Works as before, it gives 640x480 with the game running 640x400.
Scale x2, side borders. Works as before, it gives 1280x720 with the game running 640x400.
Scale max, no side borders. Ends up running in x4 scale with no borders, as expected.

Spoiler

Built library path: d3d9.dll
Created graphics driver: Direct3D 9
Initializing screen settings
Game native resolution: 320 x 200 (32 bit), letterbox optional, side borders disabled
Initializing gfx filters
Requested gfx filter: max
Chosen gfx resolution: 1280 x 800 (32 bit), game frame: 320 x 200
Applying scaling filter: StdScale4
Switching to graphics mode
Attempt to switch gfx mode to 1280 x 800 (32-bit) fullscreen, game frame 320 x 200, gfx filter: StdScale4
Succeeded. Using gfx mode 1280 x 800 (32-bit) fullscreen, game frame 320 x 200, gfx filter: StdScale4
Preparing graphics mode screen

[close]

Scale max, side borders. Does exactly the same as above, which is a bit surprising.

Spoiler

Built library path: d3d9.dll
Created graphics driver: Direct3D 9
Initializing screen settings
Game native resolution: 320 x 200 (32 bit), letterbox optional, side borders enabled
Initializing gfx filters
Requested gfx filter: max
Chosen gfx resolution: 1280 x 800 (32 bit), game frame: 320 x 200
Applying scaling filter: StdScale4
Switching to graphics mode
Attempt to switch gfx mode to 1280 x 800 (32-bit) fullscreen, game frame 320 x 200, gfx filter: StdScale4
Succeeded. Using gfx mode 1280 x 800 (32-bit) fullscreen, game frame 320 x 200, gfx filter: StdScale4
Preparing graphics mode screen
Initializing colour conversion

[close]

Scale max, no side borders, tob/bottom borders. Does the same as above, which is expected.

Spoiler

Init gfx driver
Built library path: d3d9.dll
Created graphics driver: Direct3D 9
Initializing screen settings
Game native resolution: 320 x 200 (32 bit), letterbox forced, side borders disabled
Initializing gfx filters
Requested gfx filter: max
Chosen gfx resolution: 1280 x 800 (32 bit), game frame: 320 x 200
Applying scaling filter: StdScale4
Switching to graphics mode
Attempt to switch gfx mode to 1280 x 800 (32-bit) fullscreen, game frame 320 x 200, gfx filter: StdScale4
Succeeded. Using gfx mode 1280 x 800 (32-bit) fullscreen, game frame 320 x 200, gfx filter: StdScale4
Preparing graphics mode screen

[close]

Scale max, side borders, top/bottom borders. Now I'm getting the side borders.

Spoiler

Init gfx driver
Built library path: d3d9.dll
Created graphics driver: Direct3D 9
Initializing screen settings
Game native resolution: 320 x 200 (32 bit), letterbox forced, side borders enabled
Initializing gfx filters
Requested gfx filter: max
Chosen gfx resolution: 1920 x 1080 (32 bit), game frame: 384 x 216
Applying scaling filter: StdScale5
Switching to graphics mode
Attempt to switch gfx mode to 1920 x 1080 (32-bit) fullscreen, game frame 384 x 216, gfx filter: StdScale5
Succeeded. Using gfx mode 1920 x 1080 (32-bit) fullscreen, game frame 384 x 216, gfx filter: StdScale5
Preparing graphics mode screen
Initializing colour conversion

[close]

So everything works fine, the only thing I don't understand is why I'd have to enable top/bottom borders in order to actually see side borders.

[Crimson Wizard]

So everything works fine, the only thing I don't understand is why I'd have to enable top/bottom borders in order to actually see side borders.

This depends on supported resolutions. Also, as I mentioned in the first post, this feature still implies some restrictions on which resolutions can be used.
It is possible that all resolutions with side borders but without top/bottom borders simply does not match those requirements, while resolutions with both borders do.
Still, we may calculate which resolutions are possible and see if this really works well.

First of all, to run without top/bottom borders, having 320x200 game, we'd have to have gfx mode heights = multiplies of 200. That is:
x1 => something x 200
x2 => something x 400
x3 => something x 600
x4 => something x 800
x5 => something x 1000
etc

Now, it seems maximal supported (by your monitor) height from this list is 800, which is scaling x4. 320x4 = exactly 1280, which means that no side borders needed whatsoever.

But as soon as you enable top/bottom borders, then other heights become available too, such as 1080, which is multiple of 5, so allows scaling x5. 320x5 = 1600, which means that there should be 320 pixels of side borders (160 per side).

[Radiant]

Oh, I see your point. When I do the last test, I actually get 1920x1080, which means it does have top and bottom borders, they're just small enough that I didn't notice them.

Ok, everything seems in order then with build 1160. Thank you for your time!

[Crimson Wizard]

Please, don't use 1160 for your game (it's hotfix2 number), I'll make a next version soon (maybe today). Just to use new version number, because it will be difficult to know which build it is exactly if any problem arises.

[Radiant]

Very well.

[Crimson Wizard]

I found another bug , occurs in room with vertical scrolling (room drawn over top/bottom borders). Should be easy to fix, but I need to test little more to be sure.

[Radiant]

Could you give us a full build (including the latest hotfix) so that we can help you test?

[Crimson Wizard]

Ok, this is kind of "release candidate" for the 3.3.0 update (3.3.0.1162). I was thinking about releasing this already, but extra test will be good too.

http://www.mediafire.com/download/5a67mvl0d63i416/AGS-3.3.0.zip

[Stacy Davidson]

Just to be clear, this build is strictly about setting the playback resolution, and still only allows a maximum of 1024x768 for the game its self, right?

[Crimson Wizard]

Just to be clear, this build is strictly about setting the playback resolution, and still only allows a maximum of 1024x768 for the game its self, right?

Yes; also it's inferior to custom resolutions in the way it handles "playback" resolution too (may be non-optimal).

[Radiant]

I note the current zip no longer includes msvcm90.dll, msvcr90.dll, or Microsoft.VC90.CRT.manifest; do I no longer need these?

[abstauber]

Just tested 1162, framerates are equal to 1158 and everything looks fine. The only thing I notice is that it doesn't get higher than 5x nearest neighbor. Even if I select 1920x1200, the window isn't bigger than 1600x1000.

[Crimson Wizard]

Just tested 1162, framerates are equal to 1158 and everything looks fine. The only thing I notice is that it doesn't get higher than 5x nearest neighbor. Even if I select 1920x1200, the window isn't bigger than 1600x1000.

What is the game resolution? Do you run windowed or fullscreen?

I note the current zip no longer includes msvcm90.dll, msvcr90.dll, or Microsoft.VC90.CRT.manifest; do I no longer need these?

I tested on clean system and found they were not used anyway, AGS required VC redistributable to be installed normal way, so I included it to installer.
If you use zip archive, you can download that from MS site (http://www.microsoft.com/en-us/download/details.aspx?id=26368)

[abstauber]

you are right that info would have been helpful
320x200x32b
Windowed mode only reaches 1600x1000.
Fullscreen with max NN goes up to 1920x1200 and looks great

[Crimson Wizard]

Windowed mode only reaches 1600x1000.

Windows usually cannot create a window => desktop size. Since window size = content + borders & title bar, there's a "margin" for maximal size of the windowed mode. So, max scaling could be, like, 5.8 or 5.9, but since only integer scaling is supported, it choses factor 5 as max scaling.

[abstauber]

Ah okay, thanks for explaining it.

XBMC has a nice workaround for this using a borderless fake fullscreen. But I'm already very happy how this turned out.

[Crimson Wizard]

There was a rare bug found in latest build. It took me some time to find solution. Here's an updated version.
May someone interested check if that still works well for them?
http://www.mediafire.com/download/5a67mvl0d63i416/AGS-3.3.0.zip

BTW, Radiant, did the latest one work for you? Have you released your new game version?

[Radiant]

No problems so far. We haven't released yet although we're planning to do that this week.