Adventure Game Studio

UPD: this was a test version, for more recent version check this thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51050.0
//-----------------------------------------------------------------


Okay, this took ridiculously long time because of different reasons (some of which were rather irrational), but I finally seem to be generally content with the code and got every backwards-compatible thingie working in my custom resolutions rewrite.

This is the latest 3.3.1 branch (soon be renamed to 3.4.0.0 actually) with the free display resolutions, made for your test and comments.
http://www.mediafire.com/download/bbn1krqj636ib8z/AGS-3.3.1-a2-free-resolutions.zip
UPD with custom resolutions:
http://www.mediafire.com/download/9w1astxw1ocadv1/AGS-3.3.1-a2-custom-gameres.zip

Source code in my personal repository: https://github.com/ivan-mogilko/ags-refactoring/tree/feature-custom-gameres

The package is not complete and its contents should be copied over
Gurok's 3.3.1 alpha 2 (http://www.adventuregamestudio.co.uk/forums/index.php?topic=50162.0) release.

Please, do not use this for your actual game development, this has passed only limited amount of testing.

I must explain following:
1. This does not have custom game resolutions yet. These are very easy to add, and I'll probably do that following day for the sake of test; however I would like to make a them a separate pull request in our repository, because they are, in essence, a separate feature.
Now does.
2. I must say sorry about this, but this version still has old built-in winsetup :embarrassed:. Although I declared my intentions to make a stand-alone utility, I met few problems that would require additional investigation on my side, and I just could not yet find free time to look into that; while winsetup code was practically ready since the last Custom Resolutions build, only requiring some fixing.
Also I was getting weary of this addition takng so long, so I decided to limit the changes at this point.


The main intention of this test build is to:
1. Ensure that free resolutions still work at least as good as in last Custom Res. build.
2. Ensure that people are generally happy with visual setup. The one I did for CR build had a weird resolution selection for windowed mode. For this time I used Snarky's commentary (http://www.adventuregamestudio.co.uk/forums/index.php?topic=49014.msg636480319#msg636480319) as a basis.


There are changes to the configuration file and visual setup dialog. I'll start with the latter.

Here how it looks like now:

Spoiler

Displaying full set of options after pressed "Advanced" button:
(http://i.imgur.com/8ePuTPk.png)

Displaying the contents of "graphics modes" list:
(http://i.imgur.com/vdlCuR2.png)

Displaying the contents of "scaling" list:
(http://i.imgur.com/SBt3iKa.png)

As you may notice, the scaling is both for increasing and decreasing size, but has only integer factors in the selection.
The available factors are determined by calculating maximal fit in whether chosen full screen mode, or your current desktop (for windowed mode).
The downscale factors actually treat 320x200 game as minimum, so you won't be able to select a downscale factor for 320x200 or 320x240 games.

[close]

As for configuration file, it allows to do more precise setup, including even bordered window mode (visual setup can't do that at the moment) and different scaling factors for width and height.
All graphics mode settings are now placed under "[graphics]" section in configuration file. Following is the working example with all the possible options:


[graphics]
driver = D3D9
windowed = 1
screen_def = explicit
screen_width = 1920
screen_height = 1080
match_device_ratio = 0
filter = linear
filter_scaling = max
filter_scaling_x = max
filter_scaling_y = max
game_frame = center
vsync = 1


What does these mean:
- driver (DX5, D3D9) - which gfx driver (renderer) to use
- windowed (0, 1) - play fullscreen or in window
- screen_def (explicit, scaling, max) - how the screen (window) size is determined:
  = explicit - requires exact screen width & height values
  = scaling - tries to make screen equal to game size scaled by filter (best for windowed mode)
  = max - sets to your desktop resolution
- screen_width, screen_height - which screen size to use if screen_def = explicit, ignored otherwise
- match_device_ratio - an auxiliary option, instead of using width and height, looks for the nearest mode that keeps your desktop aspect ratio
- filter - gfx filter name, depends on gfx driver; one filter was renamed:
  = DX5: stdscale, hq2x, hq3x
  = D3D9: stdscale, linear
- filter_scaling (any integer number, or "max") - defines a uniform scaling factor for the filter; positive numbers mean upscale, negative numbers mean downscale, 0 or "max" means maximal integer factor fitting in the window.
- filter_scaling_x, _y - these are not really useful, but may be just little fun to play with; they allow you to define different scaling factor for width & height of the picture; they override "filter_scaling" option
- game_frame (offset, center, stretch, proportional) - defines how the game is positioned inside the window (and fullscreen):
  = offset - in theory needs x,y coordinates, but currently just places picture at the top-left corner; not really useful, just for completeness
  = center - the picture scaled by filter is positioned at the screen center
  = stretch - the picture is scaled by filter, then stretch to fit the whole screen
  = proportional - the picture is scaled by filter, then stretched to fit the maximum of the screen while keeping game's aspect ratio.
- vsync (0, 1) - vertical sync.


As you may notice, the scaling options do not allow non-integer factors. This is not a problem of implementation, just the design choice. If there will be a real need to use non-integer factors, I would simply change the option parsing to read floats; however, I am not sure this will be demanded.

Alternate horizontal setup layout:
http://www.mediafire.com/download/c83th46bhlw1w9c/AGS-3.3.1-a2-free-resolutions-alt-layout.zip

Spoiler

(http://i.imgur.com/vCoJlcW.png)

(http://i.imgur.com/Eq92w23.png)

[close]

Sorry, what does "Stretch to fit screen (window)" do? I'm looking at "keep aspect ratio" directly beneath it and it's a bit puzzling.

Quote from: Gurok on Wed 24/09/2014 12:16:52
Sorry, what does "Stretch to fit screen (window)" do? I'm looking at "keep aspect ratio" directly beneath it and it's a bit puzzling.

No stretch checked -> scale by filter and place at center;
Stretch to fit screen -> scale by filter, then stretches game to whole screen
Stretch + Keep aspect ratio -> scale by filter, then stretches proportionally (keeping game aspect ratio).

"Keep aspect ratio" is enabled only if "Stretch" was checked.

Illustration:

Spoiler

(http://imageshack.us/a/img5/1341/0vyp.png)
(http://imageshack.us/a/img843/1069/q9n7.png)
(http://imageshack.us/a/img600/8606/ax2s.png)

[close]

The thorough explanation was made in this older thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=49014.msg636473241#msg636473241
(although some minor things may be different now)

Now with custom resolutions:
http://www.mediafire.com/download/9w1astxw1ocadv1/AGS-3.3.1-a2-custom-gameres.zip

I would like to know if this works with existing CR projects.

Also, which setup layout do you like more? Personally I am leaning towards new horizontal one, because it utilizes dialog space better.

I just made a backup and tested it with our project. I opened the project, played around with it, compiled and started the game.
Everything works as expected. Great work! :)

Oh, and I agree that the horizontal layout looks better.

Another problem. With "screen_def=max" or "screen_def=explicit" and the screen size set to my current resolution, it just loads the game in fullscreen mode instead of windowed, even if "windowed=1".
Actually, winsetup is saying my resolution is 960x600, which is lower than it actually is, so there must be some bug in detecting the current resolution.
The engine seems to default to fullscreen if you try to run it windowed at a greater size than (what it thinks is) your current resolution. This shouldn't be how it works, in any case-- it should just set the window size to the maximum and NOT go to fullscreen.

Quote from: Trapezoid on Sat 11/10/2014 01:00:24
Another problem. With "screen_def=max" or "screen_def=explicit" and the screen size set to my current resolution, it just loads the game in fullscreen mode instead of windowed, even if "windowed=1".
Actually, winsetup is saying my resolution is 960x600, which is lower than it actually is, so there must be some bug in detecting the current resolution.
The engine seems to default to fullscreen if you try to run it windowed at a greater size than (what it thinks is) your current resolution. This shouldn't be how it works, in any case-- it should just set the window size to the maximum and NOT go to fullscreen.

Yes, it was supposed to do what you say.
Can you tell which resolution your game has, and show the contents of setup file?
Also, to clarify: are you using 3.4.0 or this 3.3.1 alpha test build with CR?

Oh sorry, I posted in the wrong thread. Yeah, 3.4.0. It's an 8-bit 320x200 game, with these graphics settings:

Quote[graphics]
windowed=1
game_frame=center
screen_def=explicit
filter=StdScale
filter_scaling=3
driver=DX5
screen_width=1366
screen_height=768
refresh=0
vsync=0

I suppose your actual display mode is 1366x768.
Are you sure game runs in fullscreen and not in a window so large that you don't see the title bar? It is supposed to try alternate mode only if it failed to init the requested one for some reason.
Can you put "log=1" under "[misc]" section and run the game with log (log will be found at "<User>/Saved Games/.ags")?

Regarding the winsetup issue, at the moment it has particular limitation to which options it can set. For instance, it does not let user to select a windowed mode that is different than the scaled game size (game size * filter scaling factor). This may lead to some discrepancy between configuring game in winsetup and doing manual config.
What may be a mistake is that it does not rewrite the screen_width & screen_height parameters when a windowed mode is checked...

Okay. With these settings:
[graphics]
windowed=1
game_frame=center
screen_def=explicit
filter=StdScale
filter_scaling=max
driver=DX5
screen_width=1366
screen_height=768
refresh=0
vsync=0
Here's the relevant part of the log:

Initializing resolution settings
Device display resolution: 1366 x 768
Game native resolution: 320 x 200 (8 bit)
Game settings: windowed = yes, screen def: explicit, screen size: 1366 x 768, match device ratio: yes, frame placement: center
Init gfx driver
Created graphics driver: Allegro/DX5
Supported gfx modes (8-bit):
320x200;320x240;400x300;512x384;640x400;640x480;800x600;1024x768;
1280x600;1280x720;1280x768;1360x768;1366x768;
Supported gfx modes (8-bit):
320x200;320x240;400x300;512x384;640x400;640x480;800x600;1024x768;
1280x600;1280x720;1280x768;1360x768;1366x768;
Requested gfx filter: StdScale, filter scaling: max uniform
Applying scaling filter: StdScale
Switching to graphics mode
Attempting to find nearest supported resolution for screen size 1366 x 768 (8-bit) windowed
Attempt to switch gfx mode to 1366 x 736 (8-bit) windowed; game frame: 960 x 600, frame placement: center
Failed. Unable to find a suitable graphics driver
Attempting to find nearest supported resolution for screen size 1366 x 768 (8-bit) fullscreen
Attempt to switch gfx mode to 1366 x 768 (8-bit) fullscreen; game frame: 960 x 600, frame placement: center
Succeeded. Using gfx mode 1366 x 768 (8-bit) fullscreen
filter dest (203, 84, 1162, 683 : 960 x 600), render dest (203, 84, 1162, 683 : 960 x 600)
Preparing graphics mode screen
Initializing colour conversion
Check for preload image
Initialize sprites
Set up screen
Initialize game settings
Prepare to start game
Audio is processed on the main thread
Checking replay status
Engine initialization complete
Starting game
Loading room 15
***** ENGINE HAS SHUTDOWN
This is from manually editing the .cfg and running the game straight, so winsetup isn't affecting anything.
It's definitely fullscreen mode. (I have a a separate issue with palettes that only occurs in fullscreen mode. I should make a post about that too.)
I notice that with screen_def=explicit, if I set the width to 1364 (two less than my actual resolution 1366) it results in windowed mode, though with a distracting white line on the right side of the screen. Setting it to 1366 or screen_def to max results in fullscreen mode.

I'm also going back to a compile from the 3.3.0 custom resolution AGS, and it looks like a similar problem. Instead of jumping to fullscreen mode, it just gives me an error: "There was a problem initializing graphics mode 1366 x 768 (8-bit)." Changing the config to 1364 works. This is strange because I'm pretty sure I had these settings working properly with 3.3.0 on this computer before.

I don't understand why the black padding around the gamescreen is considered part of the graphics mode, anyway!

Just noticed something weird: in my desktop resolution settings I have options for 1366x768 and 1360x768. I switched to 1360 and the difference is unnoticeable, but now I'm able to get my game to run at full screen width in windowed mode. Very odd, but there must be something funky about 1366 mode.

There's another problem which I noticed before though: The window HEIGHT no longer reaches the bottom of the screen. There's about a 10 pixel gap no matter what. I assume you put this in so the start bar is always visible? I preferred how the 3.3.0 version worked, because I'm planning on using an autohotkey launcher to hide the titlebar/frame and make a faux-fullscreen effect. (P.S. a native hide_titlebar option would be a nice feature.)

Quote from: Trapezoid on Sat 11/10/2014 23:20:59
I don't understand why the black padding around the gamescreen is considered part of the graphics mode, anyway!

Can you elaborate, please?

Oh, I'm just confused as to what difference the size of the black border surrounding the game makes to the graphics mode it needs to initialize. I would think that a 320x200 game at 3x scale would be 960x600 and the black border would be rendered by Windows, not the game engine.

Now that I've set my resolution to 1360, I can't get that error to come up anymore, so maybe it's moot.

Quote from: Trapezoid on Sun 12/10/2014 00:02:57
Oh, I'm just confused as to what difference the size of the black border surrounding the game makes to the graphics mode it needs to initialize.

The size of black borders does not affect the initialization, it is only the size of window that does. I do not think the user should bother which size the borders are. All you need is a size of screen, a game scaling and, optionally, additional stretch to fit the whole screen.

Quote from: Trapezoid on Sun 12/10/2014 00:02:57
I would think that a 320x200 game at 3x scale would be 960x600 and the black border would be rendered by Windows, not the game engine.

Precisely as you say, a 320x200 game at 3x scale is 960x600, and black border is rendered by graphics renderer (you may say "Windows"), not game engine. Game engine only draws the game picture and graphics renderer scales it up and positiones inside window.
(It was AGS 3.3 and earlier where game engine drew borders as well)

Ah, I see. I must have been confused by 3.3's error-- 3.4 hasn't given me any kinds of errors, just the weirdness with 1366x768. On the whole I'm really impressed with the added flexibility in the custom resolution versions.

The problem with window being not large enough is related to a hack that prevents it from being too large, because AFAIK on Windows Allegro (the library AGS uses) failed to create a window if it is larger than desktop. I forgot to write a proper detection for max size; I'll look into handling this case in a more appropriate way.

I'm definitely not complaining that you've gotten this implemented in the current development branch, but it's definitely throwing off a lot of the work I'm doing (writing the game data file from the editor). I've actually got the full data file building from the editor now, but there's quite a few minor mistakes here and there that are throwing off the entire thing, so I'm working through that ATM. Hopefully I'll have something to show for it soon, then I can merge this back into the branch with the option for building other platforms... 8-)

Quote from: monkey_05_06 on Mon 13/10/2014 00:05:18
I'm definitely not complaining that you've gotten this implemented in the current development branch, but it's definitely throwing off a lot of the work I'm doing (writing the game data file from the editor).

Umm... that was inevitable since I was changing existing properties. Most of the changes come rather from GUI class refactoring, I suppose. BTW, more is coming, so I should probably wait a bit :D?

I actually suggest doing a rebase instead of merge to have a cleaner branch for pull request (wtf), or copy to new branch using cherry picks. After all some of the changes you did might have been just a temp state made for experiment (or so it seems). Also, some changes may become not-applicable/duplicate, etc.

Splitting one large task into smaller pull requests may simplify things a bit. For instance, you could make saving data in Editor first, and multiplatform build later, or vice versa.

Quote from: Crimson Wizard on Mon 13/10/2014 08:14:05Splitting one large task into smaller pull requests may simplify things a bit. For instance, you could make saving data in Editor first, and multiplatform build later, or vice versa.

Well writing the data file from the editor is definitely a huge task (stream->WriteArray(&structInstance, sizeof(MyStruct), MAX_STRUCT_INSTANCES) seriously made me want to assault someone), but it wouldn't really make any sense or be useful to split that into multiple pulls. But I can definitely do a pull request for that feature once it's ready and then just pull that back into the multiplatform branch that way.

I'm doing my best to clean up temporary code as I go along, though ultimately writing the data file should probably be split into multiple separate files. I've been working with all of it in a single place for simplicity until it can get thoroughly tested to ensure that it's doing what it's supposed to.

P.S. If you could hold off on making further changes to the game data format, I am honing in on completion here. I've got more than 80 of 90 KB of my test project verified...shouldn't be too many major mistakes left to correct. ;)

Quote from: monkey_05_06 on Mon 13/10/2014 18:25:03
P.S. If you could hold off on making further changes to the game data format, I am honing in on completion here. I've got more than 80 of 90 KB of my test project verified...shouldn't be too many major mistakes left to correct. ;)

Here's something I just wanted to say: in my honest opinion I think that you're doing a big mistake by continuously merging changes from main development branch.
I am strongly advising to first finish your feature and be sure that it works with all the old code, and then update it all at once to the latest development state. That will make things much easier to you.
It is a common thing in parallel development that two or more developers change the code that affect other's work in separate branches. If they would continiously merge their changes before they are ready, they will go mad.
I think I'll even make another post in our sticky thread about this :).

Quote from: monkey_05_06 on Mon 13/10/2014 18:25:03
(stream->WriteArray(&structInstance, sizeof(MyStruct), MAX_STRUCT_INSTANCES) seriously made me want to assault someone)

Lol, and that is why I had to create AlignedStream to read the data written that way and count structure padding.
BTW, what about "stream->ReadArrayOfInt32(&numItems, 11);" where numItems is the first integer in struct of 11 ints? :D Something I am refactoring right now.

Quote from: Crimson Wizard on Mon 13/10/2014 20:58:07in my honest opinion I think that you're doing a big mistake by continuously merging changes from main development branch.
I am strongly advising to first finish your feature and be sure that it works with all the old code, and then update it all at once to the latest development state. That will make things much easier to you.

My fear in this is that if I don't pull in intermediate changes that I'll end up so far behind that merging the changes back together will be a nightmare in itself, constantly trying to play catch-up to the changes that other people are making to the existing native code while I'm trying to port it to C#. Especially given how fractured a process writing the data file is, there are several dozen script files that could contain relevant changes that I would have to manually piece back together. I'm not saying you're wrong, but considering how close I am to having the code ready for a pull request, I don't think that I can afford not to keep up at this point.

Quote from: monkey_05_06 on Mon 13/10/2014 21:15:44

Quote from: Crimson Wizard on Mon 13/10/2014 20:58:07in my honest opinion I think that you're doing a big mistake by continuously merging changes from main development branch.
I am strongly advising to first finish your feature and be sure that it works with all the old code, and then update it all at once to the latest development state. That will make things much easier to you.

My fear in this is that if I don't pull in intermediate changes that I'll end up so far behind that merging the changes back together will be a nightmare in itself, constantly trying to play catch-up to the changes that other people are making to the existing native code while I'm trying to port it to C#. Especially given how fractured a process writing the data file is, there are several dozen script files that could contain relevant changes that I would have to manually piece back together. I'm not saying you're wrong, but considering how close I am to having the code ready for a pull request, I don't think that I can afford not to keep up at this point.

That is true that the changes may be significant, but not that significant to render all of your work completely obsolete. In current situation it will require simply to fix some of the modular parts, like add a thing or two into routine that writes game data.
What is more important, IMO, you are continiously distracting yourself to merge the changes and worry about possible inconsistences, instead of finishing the core of the task first, and worry about updating it only later. If you have a feature ready and tested, you are more sure of what you do. If there are problems after merge, you would know that they come from the merge and not wonder what are these. You are also staying focused at one task.

BTW, I had a similar situation updating hugely refactored development branch with changes to master. I usually waited 'till I finish current rewrite I was doing, then did one big merge, sometimes even followed by few updating commits to fix any problems arised from that merge.

I think you definitely make a valid point here, and I appreciate your advice and feedback. I mostly felt concerned about it because I was duplicating so much code from so many different places that sometimes it was hard to wrap my head around what was going on, nevermind keeping track of changes that might be introduced in the meantime. I also realize it creates extra commits that clutter up the history, but for what it's worth it was my way of ensuring that I wasn't inadvertently undoing the work of others.

That said, with the latest commit (https://github.com/monkey0506/ags/commit/2e49ece6e6b86bd7c3fe2a7c40de4e7b80526179) I'm happy to say that the data file can now fully be built from the managed editor code (sans the script compiler, which is still invoked from native). There are some final things that need to be cleaned up or reviewed before I submit a pull request, but the data file format is thankfully no longer one of them. :-D There's a note about this in the commit message, and this is definitely getting off-topic for this thread (sorry for the derailment). If I have further questions I'll make a separate thread. ;)