(solved) Autodetect resolution

Started by Radiant, Sun 13/10/2013 17:00:36

Previous topic - Next topic

Radiant

Something that would be nice to have in the setup program: "Autodetect Nearest Neighbor Filter". When selected and the game is run, this would look at the user's current screen resolution, and pick the largest multiple for the filter that fits on the screen.

For instance, if the game runs in 320x200, then normally you could pick "x2" "x3" "x4" and so forth; if you'd pick autodetect, and the screen resolution is 1024x768, then it would use the x3 filter because that still fits on the screen and x4 would not. If the user changes resolution to 1600x1200 and starts the game again, it would become the x5 filter. The same could apply to other filters, of course.

Would this be feasible to implement? This may be tricky for full-screen as you'd have to enumerate the possible resolutions for the monitor, but in windowed mode it sounds pretty straightforward.

selmiak

+1 and/or disable/greyout filter multiples not possible for the users currents screenresolution.

DoorKnobHandle

The entire resolution system has to be reworked. While your suggestion makes sense, I feel it's better to spend the time to implement a proper fullscreen borderless mode - otherwise we just waste time to hotfix a system that's already fundamentally flawed.

Radiant

That doesn't strike me as hard, even. Just set the window to maximized (so it automatically covers the entire screen plus or minus the taskbar) and then set the game resolution to the highest fitting multiple. In fact, that's what many games do these days, and it works well; it even avoids flickers and slowdowns when alt-tabbing.

DoorKnobHandle

It's not hard to implement Fullscreen Borderless with pixel-art-friendly upscaling indeed! I've done it before on several game projects, some in D3D9. But I just don't have to time to dig into the AGS engine source right now - and it would mean completely dropping DirectDraw 5 support.

Radiant

Why would it mean that? The function could simply only work with DX9 and be ignored with DX5.

DoorKnobHandle

Hm true, would require a winsetup update of course, as all the upscaling options would have to be disabled when D3D9 is selected if the plan is to split up the scaling behavior like that.

DoorKnobHandle

#7
All in all, I believe we just need a good plan, a goal, in regards to AGS' scaling and display behavior that we can all agree on. This has been discussed a lot previously but I'm unsure as to what has come out of that.

Here's my opinion on the matter, in case another discussion about this breaks out:

1.) We drop winsetup.exe completely.
2.) We expose functionality to AGS Script that allows game authors to change the display mode (windowed/fullscreen) during game run-time (OOP example: 'GameSettings.SetDisplayMode(eDisplayModeFullscreen); GameSettings.SetWindowScale(1.5); GameSettings.Save(); GameSettings.Load();'). Note that loading and saving the settings would write it to acsetup.cfg).
3.) In the General Settings pane inside the AGS editor, you could now only select a game resolution (technically unlimited, so this could be 16x16 or 321x59 or 1920x1080 etc.) and if your game should start in windowed or fullscreen mode.
4.) We add a GUI to the default template that takes over the functionality of the old winsetup.exe - this would allow newbies not to have to worry about creating a custom options menu in the beginning, just like we do with the saving, loading and quit game interfaces currently.
5.) Windowed mode is easy as windows can have any size all the time. The window is as big as the game resolution by default but there is a window scaling factor (see the function examples above) which can be used to make it larger.
6.) Fullscreen mode is implemented in the modern borderless fashion. It looks and feels just like proper fullscreen but allows for very quick alt-tabbing and overlaying chat windows and such on top of the game at the cost of a very small performance decrease on some systems.
7.) Internally, this system relies on creating a D3D9 render target texture that is as large as the game resolution chosen. Then everything gets rendered to that texture instead of the screen. In window mode, the AGS engine would then, after rendering, have to take that render target (I would call it a render buffer) and scale it according to the window scale factor. In fullscreen mode, the engine would instead detect the aspect ratio of the render buffer, calculate if it equals the aspect ratio of the player screen, if not, it would add black bars left/right or top/bottom, wherever necessary, and then draw the render buffer to the screen at the maximum size. The render buffer scaling is done without filtering, ie. Nearest Neighbor of course (theoretically Bilinear filtering could be selected from the General Settings pane for scaling high res games!)

I have done this exact thing (step 7) before on fresh projects and have code available if that's the problem. I don't know how much work it would be, however, to do everything else with the AGS engine. Also, it would be tricky to use this system and, at the same time, still support Direct Draw 5. Any thoughts/comments?

Radiant

#8
I think I'm generally in favor of abolishing winsetup. This is first because it contains a lot of options that the average player simply doesn't understand; second because it contains options that the designers of a game may disapprove of (e.g. certain art styles don't look good on a Hq2x filter, and I'm not sure why I would want the player to be able to shut off the music pack); and third, some options are vastly outdated (the one that says "CRT only" - most people don't know what that term means, and it's safe to assume that contemporary monitors don't need that option; the same applies to "widescreen only" and "fast CPU only"; even the "MIDI music" option is outdated because almost all games use MP3/OGG now). And I have no idea why a setup program would let me use replays, I'm pretty sure that doesn't even work in the first place. The only option in setup that I would actually use is the language selector, and that really belongs in the in-game control panel, where players actually see it. And win7/win8 computers will likely not run the game if you enable 'downgrade 32-bit graphics'...

I think it would be much better for the player if the game would automatically pick a suitable resolution this is a typical example of a choice you wouldn't want to bother a player with.

Blackthorne

You know, either getting rid of WinSetup completely or making it so you can create a custom WinSetup would be ideal.  I know there was a discussion some ways back about making a custom WinSetup application - but I really would like the option, in game, to decide windowed or full-screen, or set resolutions, etc.


Bt
-----------------------------------
"Enjoy Every Sandwich" - Warren Zevon

http://www.infamous-quests.com

Crimson Wizard

#10
Quote from: Radiant on Sun 13/10/2013 17:00:36
Something that would be nice to have in the setup program: "Autodetect Nearest Neighbor Filter". When selected and the game is run, this would look at the user's current screen resolution, and pick the largest multiple for the filter that fits on the screen.
This was implemented by BigMC for 3.3.0 long ago. The problem is that it only functions if there's no "gfxfilter" line found in winsetup. And Windows versions of the game usually comes with one (at least "gfxfilter=none"). I guess it is possible to add support for something like "gfxfilter=auto".


EDIT:
Quote from: Radiant on Sun 13/10/2013 17:00:36
Would this be feasible to implement? This may be tricky for full-screen as you'd have to enumerate the possible resolutions for the monitor, but in windowed mode it sounds pretty straightforward.
Ironically, quite opposite, graphic driver API can always enumerate fullscreen modes, but they sometimes do not "want" to enumerate resolutions in window mode, because, usually, any window size is possible.

TheBitPriest

Conceptually, I like your idea, DoorKnobHandle.


Dirt McStain

#12
I noticed that the current resolution picker for 3.3 is a bit bugged.

I have a 16:10 ratio monitor that natively runs at 1680:1050 resolution. The only two resolutions that the monitor/video card can run the game in full screen are 1600x1000 (5x) and 1280x800 (4x). Using the later makes the game look perfect at full screen but, it seems like the former should be a more appropriate resolution. However, the game appears squished (black area on top and bottom). When I check the resolution it says that I'm actually at 1600x1200 resolution, not 1600x1000.

If it's too late to add an auto-detect (or custom size) feature, can this be fixed?

Radiant

Quote from: Crimson Wizard on Mon 14/10/2013 17:44:17
Ironically, quite opposite, graphic driver API can always enumerate fullscreen modes, but they sometimes do not "want" to enumerate resolutions in window mode, because, usually, any window size is possible.
Interesting. But it's possible in code to get the current screen resolution in windowed mode, yes? Because then you don't need to enumerate anything.

Radiant

Quote from: Crimson Wizard on Mon 14/10/2013 17:44:17
This was implemented by BigMC for 3.3.0 long ago. The problem is that it only functions if there's no "gfxfilter" line found in winsetup. And Windows versions of the game usually comes with one (at least "gfxfilter=none"). I guess it is possible to add support for something like "gfxfilter=auto".
Wait, let me understand this. If I remove the gfxfilter line from the config in windowed mode, then run the game, it will actually use Nearest Neighbor filter at the biggest magnification that fits on the screen, is that correct? Because that's basically what we're looking for, except that it would be nice to give the window the size of the entire screen, and add black borders around the (magnified) game screen.

However, if I run setup, it will place the gfxfilter line back into the config file, at which point it will run at x1 magnification. So I suppose that the 'bug' or missing feature is that "Nearest Neighbor Max Size" doesn't appear in the winsetup screen.

This also means that I can basically distribute the game now without any winsetup, which is good because it contains a number of options that players don't need and don't understand. The only thing that would be really nice to have is the ability to set windowed/fullscreen mode at runtime, but I'm told that's kind of tricky. I suppose I could make a simple winsetup program that only has that question and a language pulldown...

I really think smart autodetection is the way to go here; you don't want to present users with a host of options if they aren't relevant to gameplay.

Crimson Wizard

Quote from: Radiant on Tue 15/10/2013 10:44:46except that it would be nice to give the window the size of the entire screen, and add black borders around the (magnified) game screen.
<...>
I really think smart autodetection is the way to go here; you don't want to present users with a host of options if they aren't relevant to gameplay.
This is implemented in custom display resolution branch to certain degree: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636462609#msg636462609
It still requires some improvement, that's why I haven't put it in 3.3.0.

Radiant

My current idea is to distribute the game with no winsetup program, and besides the executable include a batch file that runs it in fullscreen mode. For this to work, it would be really nice if it was possible to do "gamename.exe -fullscreen" to force full screen mode; I couldn't find this in the manual but I know that some command line switches exist. Otherwise I would write the batch file so that it uses renaming to switch two config files around, I suppose.

Is there anything I might run into when not including a winsetup? It strikes me that all important options (e.g. sound on/off, language) can be set at runtime if I just design a GUI for it.

Crimson Wizard

There's whole bunch of command line parameters, but many have very specific meaning.
Here's most common ones:

Code: text

-windowed            Set display mode to windowed;
-fullscreen          Set display mode to fullscreen;
-hicolor             Downgrade to 16bit colors;
-letterbox           Enable letterbox mode;
-gfxfilter <filter>  Use graphics filter, where <filter> can be:
                     StdScale2, StdScale3, StdScale4, Hq2x or Hq3x
--help               Print this help message;

Radiant

Excellent. So if I omit winsetup, and omit the filter line from the config, then I can have gamename.exe and fullscreen.bat which does "gamename.exe -fullscreen".

...does AGS pick sensible defaults if I omit other parts from acsetup.cfg? In particular 'digiwin=1096302880' which looks like it's something system-specific. I just tried and the game seems to start up fine without a config file, but I'm not sure if it might default to DX5 or to 16-bit color or something.

Crimson Wizard

There appear to be few options that are not used anywhere in the engine. Might be deprecated or unfinished work.

SMF spam blocked by CleanTalk