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.