Runtime resolution change (experiment)

Crimson Wizard · Sat 16/04/2016 17:54:34

Experimental build which supports changing game resolution at runtime.
Based on 3.4.0.6.

Current commands: Alt + Enter - switches from window to fullscreen and back.

Download: http://www.mediafire.com/download/vgyqp0i1e4eyjqt/acwin_3.4.0.6--changeres.zip
Source branch: https://github.com/ivan-mogilko/ags-refactoring/tree/feature--dynamic-gfx-mode

PS. Regarding the merge of 3.3.5 to 3.4.0, I must apologize for the delay. I know I was making promises and then did not keep them. But the work continues.

Monsieur OUXX · Sat 16/04/2016 22:41:40

Cool

Crimson Wizard · Sat 16/04/2016 23:02:22

Quote from: Monsieur OUXX on Sat 16/04/2016 22:41:40
Cool

Does this mean it works?

In the end there should be Script API for reading/setting display mode, but first it needs to be tested that it may change without problems in the middle of the game.

Scavenger · Sun 17/04/2016 00:27:30

Tested it out on my game, Heatwave. It works fine (apart from the obvious colour issues in fullscreen), however....

Code: ags

An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x004B6EC5 ; program pointer is -41, ACI version 3.4.0.6, gtags (0,0)

...

in "Room26.asc", line 8

happens when you switch from fullscreen to windows mode while PlayFlic () is running, as soon as the Flic playing ends. Line 8 in the script is PlayFlic. I'd check it out with PlayVideo as well, but I don't have any builds on me that use that. Also, the palette never gets fixed when you enter windowed mode while PlayFlic is playing.

Will the script API be able to switch the display resolution from, say, 320x200 to 640x400, similar to how early games did that in order to display high resolution low colour graphics or text? Because I could think of loads of things I could do with that.

Crimson Wizard · Sun 17/04/2016 01:01:37

Quote from: Scavenger on Sun 17/04/2016 00:27:30
Will the script API be able to switch the display resolution from, say, 320x200 to 640x400, similar to how early games did that in order to display high resolution low colour graphics or text? Because I could think of loads of things I could do with that.

This is a a different thing, being outside the scope of this feature.
The feature in question is changing display mode at runtime, as opposed to being able to change it only in setup program.
What you are asking about is an ability to use different resources depending on display mode.
Currently this is supported for backwards compatibility only with a special setting that you need to manually add to config file. I mentioned that here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=53360.msg636532457#msg636532457
I was thinking about returning it back somehow, if I have time, because there were complains about low-res font looking bad when running in hi-res mode.

Monsieur OUXX · Tue 19/04/2016 12:54:50

Quote from: Crimson Wizard on Sat 16/04/2016 23:02:22
Quote from: Monsieur OUXX on Sat 16/04/2016 22:41:40
Cool
Does this mean it works?

Didn't test, was just praising the idea

morganw · Wed 20/04/2016 20:38:45

When switching resolution the mouse cursor is being restricted in the window, by the same offset that it was restricted to in full screen (with black borders).

i.e. if the black border was 10px at the top of the screen, when switching to a window the cursor is being restricted 10px from the top of the game. If I don't see the problem at the top of the screen I see it at the bottom, but not top and bottom at the same time.

I've got an external monitor connected, but it seems to happen when just testing on the primary display.

Crimson Wizard · Thu 28/04/2016 03:36:50

Fixed switchng mode during FLIC playback:
Download: http://www.mediafire.com/download/vgyqp0i1e4eyjqt/acwin_3.4.0.6--changeres.zip

Dave Gilbert · Thu 28/04/2016 12:35:24

Why haven't I seen this before now? This is a feature our fans have been requesting for EVER. Will test later today!

Dave Gilbert · Thu 28/04/2016 15:47:55

OK, so I tested it and got some weird results. I compiled and ran in full-screen mode. I pressed alt-enter, then I heard the "Windows error" sound and the game just froze. My standard windows mouse cursor appeared on the screen and I could move that around, but the game's mouse cursor remained frozen where it was. I could only get back to the desktop by going to the task manager, and then I saw this error message:

I am running the game on a windows 8.1 laptop. Screen resolution is 1920x1080. The game itself was running in Direct3D, using the mode "Bind to game scaling (force desktop ratio), filter "nearest-neighbor", and scaling "max fit."

edit: Interestingly enough, alt-tabbing now works totally as expected in full-screen mode, when it didn't used to do that before.

Crimson Wizard · Thu 28/04/2016 17:10:52

Direct3D does not seem to work after switching yet, only DirectDraw5 mode does. I'll be looking into this.

Dave Gilbert · Thu 28/04/2016 17:22:22

Ah. I see. It's been my experience that DirectDraw doesn't work on a lot of modern computers anyway (we had more problems with games that run solely in DD mode than we can count). So sussing out a way to get Direct3D working would be great. Thanks again, CW!

Crimson Wizard · Thu 28/04/2016 19:18:50

The problem with Direct3D is that you have to reset all the device resources (like textures) game has at this point for the new mode. This means iterating through everything that was cached and recreate them from original bitmaps. This will take some time to code...

Dave Gilbert · Thu 28/04/2016 21:17:13

Yep. I get that. Which is why many prefer using DirectDraw than Direct3D, even though DirectDraw isn't supported anymore. It gives really unpredictable results especially on modern laptops, which made problems extraordinarily hard to troubleshoot. But that's a discussion to be had a later time! Thanks again.

edit: That said, I switched to DD mode and tried it out. It worked, although it restarted my game when doing so!

Crimson Wizard · Sun 12/06/2016 03:35:32

I made some progress with the Direct3D, it generally worked, but was still crashing under certain conditions, like during room transition effect (fadeout).

But then I had to lay my work away because I was leaving town, and then I had to prepare new 3.4.0 release.

And when I wanted to review what I have done, I found that I deleted all the last changes by mistake, they got lost, even do not exist in the repository history.

I will have to recover these by memory when I have more time.

Quote from: Dave Gilbert on Thu 28/04/2016 21:17:13
edit: That said, I switched to DD mode and tried it out. It worked, although it restarted my game when doing so!

Yeah, that is a weird effect I am also experiencing. I think it might have something to do with incorrectly interpreted key codes.

Crimson Wizard · Mon 26/09/2016 16:14:11

Yeah I know I said I will leave AGS... but I am currently "tying loose ends" in a more relaxed working mode. So, I decided to look if I can bring resolution switching to at least potentially working state. I was not completely sure about this, but after several days I was able to ressurect my lost code and possibly fix certain other issues (game restarting after switch).

Download: http://www.mediafire.com/download/1pssj7z1v81lrjr/acwin_post-3.4.0--gfxmode-switch.zip
Source (warning, dirty WIP code): https://github.com/ivan-mogilko/ags-refactoring/tree/feature--dynamic-gfx-mode

WARNING: this work is now based on POST 3.4.0 development branch; it does not include any new big features but has a lot of code refactored, so there may be minor glitches. Please do not use for your actual game making yet.

INSTRUCTIONS: switch between fullscreen and windowed mode with Alt+Enter.

KNOWN ISSUES:
1. This is not yet optimized, and it fully recreates device-dependent sprites after switch. That's not a big issue for software mode (because it draws with raw bitmaps), but switching in Direct3D may take quite some time... like several seconds. But what makes it worst, I noticed that it does not even depend on the number of sprites on screen. Literally, there could be one Direct3D sprite that takes 2-3 seconds to release, or something like that. Since I do not know Direct3D very well, I cannot immediately tell what's going on.
2. Switch does not try to optimize new mode parameters yet, which may lead to strange results, like game surrounded with black borders in windowed mode (usually there is no need for these). I believe there should be some kind of rule set, which default display properties to use when such switch occurs.

Alan v.Drake · Mon 26/09/2016 21:57:27

Excellent work CW, I just gave it a try and it seems to be working even better than advertised.
In D3D mode the switch is almost instant, the DD mode instead takes a few seconds.
Perhaps it's related to the game ?

- Alan

selmiak · Mon 26/09/2016 23:58:32

Quote from: Crimson Wizard on Mon 26/09/2016 16:14:11
Yeah I know I said I will leave AGS... but I am currently "tying loose ends" in a more relaxed working mode. So, I decided to look if I can bring resolution switching to at least potentially working state. I was not completely sure about this, but after several days I was able to ressurect my lost code and possibly fix certain other issues (game restarting after switch).

yay

Radiant · Wed 05/10/2016 15:34:59

Quote from: Crimson Wizard on Sat 16/04/2016 17:54:34
Current commands: Alt + Enter - switches from window to fullscreen and back.

Great, I've had requests for that

Crimson Wizard · Wed 14/12/2016 00:58:02

I am still not well versed in Direct3D, so I may not have seen opportunities when doing this build. Now I found there is actually a better, proper way to switch display mode without reinitializing Direct3D device, and that does not require to recreate textures at all. The switch is literally instant.
This is done using IDirect3DDevice::Reset function (which is also used to restore window in case surface was lost). Initially I thought it can be used only to restore previously set mode, but I learnt it can be used to dynamically switch modes too.

Dave Gilbert · Fri 23/12/2016 17:32:25

Just saw this. Excellent news! Do you need anyone to test this?

Crimson Wizard · Fri 23/12/2016 21:33:27

I was very busy recently, but the new code is generally done, I think I will clear it up a bit and make the test build on this weekend.

Crimson Wizard · Sun 25/12/2016 22:39:27

Ok, here you go:
http://www.mediafire.com/file/idxao8mwk3hu6yd/acwin_post-3.4.0--gfxmode-switch_%282%29.zip

As always, I advise you to not use this engine for making actual game.

There may be few problems with it, like switch not working during certain blocking events, but these will hopefully be found and fixed.
I am more or less glad with the code, so if it works in general I can add it to our repository.

Dave Gilbert · Wed 18/01/2017 15:24:38

Yeesh I didn't see this until now. Apologies! Feel free to poke me via PM if you need someone to test these things. I don't always check the forum as often as I should.

Downloading now!

Crimson Wizard · Wed 18/01/2017 15:25:42

~~Well, I received no replies,~~Whoops I just received a reply from Dave Gilbert. Anyway, I decided to just go ahead and add it to repository.
It's been several months since the release of AGS 3.4.0, and according to our new development rule, there should be a new version about every that much. So I guess we would have a new AGS Beta at the beginning of February with this feature included, that could be tested by anyone.

Dave Gilbert · Wed 18/01/2017 15:32:04

So I tried it out. I loaded up my game, pressed alt-enter, and the game just restarted itself. I assume that's not the correct behavior? I am running the game in direct3D mode.

edit: same happens in directdraw.

Crimson Wizard · Wed 18/01/2017 15:35:31

Quote from: Dave Gilbert on Wed 18/01/2017 15:32:04
So I tried it out. I loaded up my game, pressed alt-enter, and the game just restarted itself. I assume that's not the correct behavior?

Yes, this is not supposed to happen.
This problem has been plaguing this test build. For some reason Alt+Enter combo has same key code as F9, that is usually used as Restart in game scripts. I was trying to prevent engine from misidentifying them, but apparently not enough...

Dave Gilbert · Wed 18/01/2017 15:40:31

Well, I commenting out the "F9 restart" command in the global script and recompiled. This time, I pressed alt-enter and nothing at all happened. I tried it in both DirectDraw and Direct3D mode.

Crimson Wizard · Wed 18/01/2017 15:50:33

How do you use the engine from that package, and how run the game exactly?
Maybe you ran the game using different engine build by mistake.

If you press Ctrl+V (or Ctrl+Alt+V), what engine version does it show?

Dave Gilbert · Wed 18/01/2017 15:57:46

Oh my god you're right. I was using a different version of the engine. Using the right one this time.

So. The first thing I notice is that when I run the game, it takes much longer for the game to come up on my screen than normal. 5-10 seconds when it used to be almost instantaneous. And whereas before it had my intro splash screen fade up from black (with the music fading in from silence), it now just sharply cuts to the image and the music with no fade-in for either.

That said, the alt-enter works as advertised. It takes a few seconds to switch from one or the other, and the windowed version isn't an ideal size (it seems to be defaulting to the native size of the game, which is quite small) but it works.

-Dave

Edit: It also takes longer for the game to quit. It used to be instantaneous, and now it's around 5 seconds or so. Not a dealbreaker but it's something I noticed.

Crimson Wizard · Wed 18/01/2017 16:15:21

Quote from: Dave Gilbert on Wed 18/01/2017 15:57:467
So. The first thing I notice is that when I run the game, it takes much longer for the game to come up on my screen than normal. 5-10 seconds when it used to be almost instantaneous. And whereas before it had my intro splash screen fade up from black (with the music fading in from silence), it now just sharply cuts to the image and the music with no fade-in for either.

That said, the alt-enter works as advertised. It takes a few seconds to switch from one or the other, and the windowed version isn't an ideal size (it seems to be defaulting to the native size of the game, which is quite small) but it works.

That is all not expected to be honest. It was supposed to switch to the window scaled with maximal round multiplier. And I do not remember if it caused any slowdowns...

Just to be sure, here is most recent automatic build containing this feature: http://teamcity.bigbluecup.org/repository/download/AdventureGameStudio_EngineRelease/21988:id/engine.zip

May someone else try this out? I was testing this on two different computers, and it worked fine.

Dave Gilbert · Wed 18/01/2017 16:25:07

Hm. I usually use the "stretch to fit screen (preserve aspect ratio)" filter. I changed it to "max round multiplier" but I had the same behavior.

Crimson Wizard · Wed 18/01/2017 18:23:58

Quote from: Dave Gilbert on Wed 18/01/2017 16:25:07
Hm. I usually use the "stretch to fit screen (preserve aspect ratio)" filter. I changed it to "max round multiplier" but I had the same behavior.

It does not currently depend on config settings; when you switch to alternate display mode in game, it takes the "default" config for that mode, which is -
* for fullscreen mode: resolution equal to the current desktop resolution, max round multiplier scaling;
* for windowed mode: window size equal to game scaled using same max round multiplier;

Max round multiplier was chosen as default, because in certain combinations of monitor/game the game scaled to fit screen (even if proportional) can get uneven scaling issues.
I can change this to make it choose same scaling method as in previous mode.

But the point is that the window is supposed to be largest that can fit into screen using given scaling method.

morganw · Wed 18/01/2017 19:40:10

I've tried the build that you linked. For me, sometimes the change between the modes doesn't work every time. Sometimes it works fine, but I've had it go in circles (seems to be switching and then switching back in a loop) trying to go from fullscreen to a window. I had to press CTL+ALT+DEL to make it stop, at which point it did switch to a window and stay in windowed mode. I've also seen it fail to go fullscreen (seems to change and then instantly change back, but didn't do it continuously). This is using Direct3D.