[TEST] Custom Resolution build (based on 3.3.0 / 3.3.1)

Started by Crimson Wizard, Thu 19/09/2013 18:05:19

Previous topic - Next topic

Crimson Wizard

After some thinking, here's new (already almost working*) winsetup for this build:



*Needs polishing, also controls layout may change slightly.

Mode combo box and scaling slider are mutually linked, changing one should update another. I think slider should be disabled for fullscreen, because it makes less sense for it. For windowed mode some people will like to set scaling rather than calculate wanted resolution.
Slider tics mark integer multipliers (x1, x2, x3 etc). Scaling range is calculated for uniform (proportional) scaling only (so that both width and height fit).

Radiant

Looks nice, but you should maybe remove the "game resolution: 320x240" line because it seems to contradict the "1280x720".

DoorKnobHandle

I would not remove the line because it's pretty nice to be able to find out what the game's native resolution is. Instead I would relabel it to make the difference between the game's native resolution and the display resolution more clear.

EDIT: Also, nice work Crimson. Not the approach I was having in mind for AGS and resolutions but nice work nonetheless!

Snarky

Hmmm... I like the idea of decoupling the filter from the scaling. But if the graphics mode and scale now literally control the same thing, wouldn't it be simpler to combine it into one drop-down, with entries like "x2 (640 x 480)"?

(I'm also confused about seeing 1280x720 rather than 960x720 in that box. So you're running the game with sideborders in a window? Confusing...)

Daniel Eakins

Quote from: DoorKnobHandle on Wed 05/02/2014 12:47:45
I would not remove the line because it's pretty nice to be able to find out what the game's native resolution is.
That could be put in the game's description (on the AGS site, game site and/or readme file) along with the other technical information like color depth and stuff.
We all have our time machines, don't we?

Crimson Wizard

Quote from: DoorKnobHandle on Wed 05/02/2014 12:47:45
Not the approach I was having in mind for AGS and resolutions but nice work nonetheless!
And what was your idea? Maybe yours better.

Quote from: Snarky on Wed 05/02/2014 12:54:55
But if the graphics mode and scale now literally control the same thing, wouldn't it be simpler to combine it into one drop-down, with entries like "x2 (640 x 480)"?

(I'm also confused about seeing 1280x720 rather than 960x720 in that box. So you're running the game with sideborders in a window? Confusing...)
The list has only the modes returned by graphics driver. These are basically fullscreen modes it supports. But in window mode you can usually have any random resolution, hence the slider.
I was considering to hide the list for windowed mode and display a label with resolution based on slider position.

DoorKnobHandle

Quote from: Crimson Wizard on Wed 05/02/2014 13:27:15
Quote from: DoorKnobHandle on Wed 05/02/2014 12:47:45
Not the approach I was having in mind for AGS and resolutions but nice work nonetheless!
And what was your idea? Maybe yours better.

I summarized it a while ago here. I realize that it's not as simple to do as a (custom) winsetup program though and will take fiddling with the engine code. So, in the meantime, it's nice to have a better winsetup! :)

Crimson Wizard

Quote from: DoorKnobHandle on Wed 05/02/2014 13:32:56
I summarized it a while ago here. I realize that it's not as simple to do as a (custom) winsetup program though and will take fiddling with the engine code. So, in the meantime, it's nice to have a better winsetup! :)
Oh, I see. Well, I am making this winsetup for this test build only, so that people could use GUI instead of typing options in text file.

Regarding the code, I am coming to a thought that the feature should be redone from scratch (for 3.4), keeping the WIP branch as a reference: it has a lot of redundant changes history now, because I wasn't sure about where to go at first.

Crimson Wizard

#88
Updated version:
http://www.mediafire.com/download/daidduo2hdn8z1k/CustomRed_RC.7z

This is built on top of 3.3.0 RC, added new winsetup.
Be careful and make a backup of your game before using this new build!

I made up my mind regarding how to organize the code, and now everything is in my personal repository, rather than central AGS one:
https://github.com/ivan-mogilko/ags-refactoring/tree/dirty_custom_resolutions
(Branch is called "dirty_custom_resolutions").
Later I plan to remake custom resolutions in 3.4.0, using this branch as a reference (unless better implementation proposed).

Snarky

I've been thinking about how to best present the setup options for the graphics (and looking at how other comparable applications do it, including ScummVM, Snes9x, and DOSBox/D-Fend Reloaded), particularly looking forward to being able to change these setting dynamically. And I wonder if the best thing isn't to separate out the settings for Windowed mode and Full-screen mode, since certain options only make sense for one or the other. So here's my idea:

Common settings/info:
  • Native game resolution: 320x200
  • Graphics driver (list)
    • Direct3D 9
    • DirectDraw
  • Graphics filter (list)
    • Normal (nearest neighbor)
    • HQ (interpolation)
  • Maintain aspect ratio (checkbox) â€" this replaces the "show sidebars" setting from previous versions of winsetup
  • Run in full-screen (checkbox) â€" hopefully at some point we'll be able to switch while the game is playing, and this will become "Start in full-screen"

Windowed mode:
  • Scaling factor (list) â€" range depends on setting of Graphics filter
    • 1X
    • 2X
    • ...
    • 8X
  • Window stretch (list) â€" this is not currently supported, but could be used in the future to enable dynamic resizing of window
    • Disabled
    • Snap â€" this would only allow resizing window to 1X, 2X, etc.
    • Interpolate â€" resize the window freely, using standard interpolation; if "Maintain aspect ratio" is set, width/height adjust together

Full-screen mode:
  • Resolution (list)
    • Desktop resolution (1920x1280)
    • Game resolution (640x480)
    • [other available modes detected]
  • Scaling factor (list) â€" range depends on setting of Graphics filter
    • Maximum fit â€" disabled if graphics filter set to HQ
    • 1X
    • 2X
    • ...
    • 8X
  • Stretch to fit full-screen (checkbox) â€" if aspect ratio doesn't fit and "Maintain aspect ratio" is off, will stretch across entire screen with standard interpolation; otherwise sidebars/letterboxed

Potentially, the settings Graphics driver (?), Graphics filter (normal: nearest neighbor), Preserve aspect ratio (true), Window stretch (disabled), Scaling factor (for full-screen: Maximum fit) and Stretch to fit full-screen (true/false?) could all be hidden behind an "Advanced" mode, with sensible defaults as indicated. That way, a user would only need to select Scaling factor (for window), Resolution (for full-screen), and whether to run full-screen/windowed.

Crimson Wizard

Reuploaded with fixes to WinSetup, also added "Keep aspect ratio" checkbox (under "Advanced").
http://www.mediafire.com/download/d4vz54sb4t33tma/CustomRes_3_3_0_RC.7z

@Snarky: I strongly disagree with using lists for scaling factor. Remember, we can have high resolutions, like 1280x720, which may only be scaled up to x1.5 on 1920x1080 monitor.

Snarky

Just set it to "Scale factor:Maximum fit, Stretch to fit full-screen" (or leave it at these settings, as they should probably be the default).

IMO when you're getting into fractional scaling, you're in the realm of interpolated stretching, which is not the same thing as the basic upscaling filters. For example, if you have a 320x240 game and you scale it with hq3x to 960x720, you might still want to stretch that by x1.5 (=1440x1080) to fit a 1920x1080 monitor. But that's a separate operation from the hq3x filter: you're not scaling by "hq4.5x".

Therefore, I'm not convinced there's any need to provide fractional scaling factors as an option, and I think they confuse the issue. The only real use for them is to stretch the image to fill the screen, and that's provided by the "stretch to fit full-screen" checkbox. Or if you're running in a window, you could use "Window stretch: Interpolate" to resize the window to whatever size you like without worrying about whether it's 1.5 or 1.6 (this is how Snes9x works, for example).

Crimson Wizard

I feel like we talk about different things?
The scaling I was talking about was not the filter parameter, but the relation between window size and original game size. In the dialog I made I completely abandoned the filter scaling parameter.
Nearest-neighbour and linear (D3D9) filters are not restricted to integer scaling factor, they can use any factor, so they do not need anything set up for them (except for destination size, which is calculated from combination of window size and stretching mode). Hq2x and 3x have fixed 2x and 3x scaling factor, so they don't need any user parameter as well.

Snarky

I think the simplest thing might be to refer back to this previous discussion.

The point still remains that there's no real need for setting non-integer scaling sizes in the setup.

-If you're playing in a window, you don't need it to take up the whole screen, and if you do want to set it to a non-integer scaling size, it's probably better to do that by just resizing the window yourself.
-If you're playing full-screen, the only non-integer scaling you care about is almost certainly stretching it to full-screen, no matter whether that's x1.5 or x1.667 (or x0.8, in case you need to shrink it).

Crimson Wizard

#94
Uhhh... but AGS cannot resize window at runtime... so this all is about some future implementation?
Sorry, my brain is working slowly lately.
I added free scaling option specifically to address the problem of non-resizable window.

Snarky

I see it as a forward-looking proposal. While it works fine with current AGS limitations, the real benefits would be realized once the graphics settings become more dynamic at run-time. And I took this comment to mean that you think that's a near-term improvement:

Quote from: Crimson Wizard on Wed 15/01/2014 21:53:02
Quote from: Snarky on Wed 15/01/2014 21:36:38
As for moving the settings into the script domain (as Calin suggests), which I assumes means providing an engine API instead of winsetup, first: it requires the ability to change the settings "live" while the game is running, which AFAIK AGS can't currently do
Regarding what Snarky sais, my thoughts exactly, except for point 1; I think this problem may be solved.

I only know your current version from the screenshot in this thread, but to me it would seem that it has the following drawbacks:

-The Resolution and Scale settings (if I understand it correctly) affect each other in confusing ways.
-Setting "Graphics mode" based on detected screen resolutions doesn't really make sense in windowed mode (whether or not my screen supports 960x720, that's a perfectly valid graphics mode for a 320x240 game). In windowed mode, you're primarily interested in multiples of the native game resolution.
-If you switch between windowed and full-screen, you have to keep changing the scaling each time. (So it would need to be redesigned once it's possible to change this at runtime.)
-The "max scaling" doesn't really make sense for windowed mode. The max possible client area will be a bit smaller than the screen (by an amount that depends on many factors, including things like your Windows font size), will often be just below some nice integer value... and you don't want a window that big anyway.
-In fullscreen, you don't really care about non-integer multiples of the game resolution, apart from stretching to fullscreen (but for that, you probably don't care about the numerical value)
-There's no way to use e.g. hq3x and then stretch it further to fullscreen.
-There's no way to stretch to fullscreen without preserving aspect ratio (for people who really want to do that).

To be honest, I'm not convinced it's an improvement from the old version.

Crimson Wizard

#96
Quote from: Snarky on Thu 06/02/2014 20:35:58
I see it as a forward-looking proposal. While it works fine with current AGS limitations, the real benefits would be realized once the graphics settings become more dynamic at run-time. And I took this comment to mean that you think that's a near-term improvement:
I just mean that's possible to do :). But it will require rewriting the way drivers are created in AGS. Something I did not want to do right away.

Quote from: Snarky on Thu 06/02/2014 20:35:58
I only know your current version from the screenshot in this thread,
I changed how it works after your first comment. Now it looks like this:


In fullscreen you set graphics mode. In windowed to drag slider and can see both scaling value and resulting window size.
The "scaling" is game size scaling factor, i.e. how much the game will be stretched to fill the chosen window size.
Switching from fullscreen to windowed and back corrects scaling/resolution automatically to match nearest supported value. This may be bit annoying, but currently I don't see other way to solve this.

Quote from: Snarky on Thu 06/02/2014 20:35:58
-The "max scaling" doesn't really make sense for windowed mode. The max possible client area will be a bit smaller than the screen (by an amount that depends on many factors, including things like your Windows font size), will often be just below some nice integer value... and you don't want a window that big anyway.
There's no "max scaling" option anymore. Also in windowed mode the maximal scaling factor is calculated taking (desktop size - some value) as a reference.

Quote from: Snarky on Thu 06/02/2014 20:35:58
-There's no way to use e.g. hq3x and then stretch it further to fullscreen.
I think there's a misunderstanding. The filter you select will be applied no matter what, then the image is stretched to the chosen resolution.

Quote from: Snarky on Thu 06/02/2014 20:35:58
-There's no way to stretch to fullscreen without preserving aspect ratio (for people who really want to do that).
There's a "Keep aspect ratio" checkbox in "Advanced" section,

Snarky

Mmmyes, that makes a bit more sense to me (and comes a little closer to what I proposed).

What does "320 x 200 x 8" mean? The scale isn't set to x8 on either of the images.

I'm not entirely clear on how the "Graphics mode" is meant to work, I guess. Let's say I have a 1920x1080 screen, and a game that's 320x200. At x5 (the highest possible integer fit), that's 1600x1000, which is not a supported resolution. For maximal sharpness, I'd like to play it in full-screen at my native desktop resolution, windowboxed. How (if at all) is that possible?

If you select a Graphics mode that has a different aspect ratio to your game, what is the scale set to?

And what are the other options under the Graphics filter menu?

Crimson Wizard

#98
Ok, I see, I did not add a way to make separate frame scaling inside the window. I just did not know how to do that easy to user.
I've been told over and over that users are confused by difficult settings. I am out of ideas how to do that properly.

I need to remake this version. Add scaling factors to config file, then make some kind of control to choose scaling amount for the filter.

Radiant

#99
Just to throw in some ideas, what I think would be easiest for the user is this:

On the setup screen, remove the line "game resolution: 320x200x8" and the line "scale: x2.0"; take the pulldown "graphics mode", rename it to "resolution" and fill it with the possible values (320x200, 640x400, 760x600 and so on). This is because a user presumably knows what his desktop resolution is, so he can pick the value that works best for him. Then have the pulldown for "graphics filter" pick between filters (NN, HQX, etc) but not magnifications (and this pulldown would be grayed out if the user picks 320x200 for a game that is 320x200, since that doesn't need any filters); it is to be expected that toggling the "fullscreen" checkbox may change the content of the pulldown menus. This avoids having multiple controls that do the same thing, as well as one control that does multiple things.

Even nicer would be the ability to resize the game window at runtime, but I can imagine that may be hard to code. Windows has a standard resize code that allows you to specify a minimum size; for a 320x200 game the window should not be smaller than that. Then, whenever the user resizes the window (including the maximize button) find the highest multiple that will fit, and center that in the window on a black background. For example, if the user drags the window corner to make it 700x700, then the game will pick 2x scaling and become a 640x400 game (with a 30-pixel border at the sides, and 150-pixel at top and bottom).

$.02

SMF spam blocked by CleanTalk