[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

Allegro windows cannot resize, library does not support that.

Radiant

Ok, scratch that part then, I got a bit carried away :)

Snarky

#102
Quote from: Crimson Wizard on Thu 06/02/2014 21:46:09
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.

“Everything should be made as simple as possible, but no simpler.”

I think offering the ability to set up the display options for all the possible conditions and preferences is inherently a complex problem. None of the apps I looked at for comparison (I also included video players like VLC and Media Player Classic) are "simple" in the sense of only having a few controls or settings. In fact, pretty much all of them have more settings to play with than AGS. (Of course, it's not given that these UIs are actually any good, but they'll at least be familiar to people who have had to do similar tasks before.)

In this situation, I think the most important thing is to make the controls logical and "task conformant" (the necessary steps should match the users' way of thinking about their goal), and to make the most common tasks quick and easy. This probably involves putting some settings on the "Advanced" screen, but shouldn't lead us to completely remove options that actually serve a useful purpose just because we think some users might find them confusing.

I guess the other thing I should mention is that I don't see big changes to winsetup as a high priority for AGS 3.3.x, and so I'm not so concerned with a stopgap solution as with a more longterm redesign.

Crimson Wizard

#103
I need to make a winsetup for this build, because otherwise it is barely usable: users have to type display parameters into the config file.

So, from what other said:
1. The filter scaling should be integer, because fractional scaling may look bad. Stretching for max fit in fullscreen is optional.
2. There should be a way to play game having (possibly scaled) game frame in the center of a larger black fullscreen.
3. "Maintain aspect ratio" and "Stretch to fit full-screen" should only be available in fullscreen, because windowed mode is resized to correspond to selected filter scaling (is it?).
4. "Stretch to fit full-screen" only available if filter scaling does not support "max fit".

So, something like this:


With "Graphics mode" field removed for windowed mode, and scaling filter moved up on its place.
E: or maybe "Graphics mode" list replaced with label that shows window size, for the reference.

Gurok

#104
Hey CW, if you're going to redo winsetup, here are some ideas:





This is only quick and there are a few options missing, but it's where I feel we should be heading. Feel free to ignore if this is too hard.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

#105
Uhhhh... maybe. I don't know.
I did not want to spend too much time on this, because I am trying to get to other things... damn, I am completely confused without a strict plan. Again. I am not sure what I should be doing. I want to end with this temporary branch, and move to 3.4.0 and redo everything there in a more clean way.

Besides, the idea was to completely abandon built-in winsetup. In such case there's no sense spending too much time remaking existing one.
If you want, you may make a new setup program right away.

Crimson Wizard

Snarky, can you please explain, what's the relation between "Scaling factor - Maximum fit" and "Stretch to fit full-screen checkbox" in your concept? Are they mutually exclusive?

Crimson Wizard

No, sorry, I made up my mind and I won't do this, at all. I am going to leave this branch as it is now.

It can be used already, you can set any size of the window in both fullscreen and windowed. What you can't do is to have a boxed view in fullscreen, you can only have stretched to max version (either keeping aspect ratio or not).

My problem is that my mind got completely messed up when there are a lot of things coming at once, and I do not know what to choose and what to attend to, and just loose time wondering and remaining in uncertainty.
I need to focus on a single task.

Snarky

That's fine. I actually assumed that this was already locked for v3.3 (as I said, I don't think messing with winsetup is really a high priority at this stage, precisely because so many of these things are stuff we have been talking about changing anyway). As for ditching winsetup completely, I thought you agreed that it would be better to have it around as an option, even if game makers are given APIs to set the configuration from within the game.

Quote from: Crimson Wizard on Sun 09/02/2014 16:28:32
Snarky, can you please explain, what's the relation between "Scaling factor - Maximum fit" and "Stretch to fit full-screen checkbox" in your concept? Are they mutually exclusive?

No, remember that in my concept, the scaling factor would only be integers, so by choosing that option and turning off Stretch to fit, you could have the (maximum fit) boxed view in fullscreen mentioned. Of course, if you have Stretch to fit turned on, it doesn't really matter which scaling factor you choose. It's possible that that's a weakness of the proposal.

Personally I like some aspects of Gurok's proposal, specifically having a visual indicator of what the settings mean. I'm not sold on the specific controls, but I suppose at this point I should make a mockup myself if I want to convince anyone.

Hope you don't mind us continuing the discussion, which isn't meant as a demand for you to go implement any of these designs.

RickJ

Quote
... game makers are given APIs to set the configuration from within the game.
This would make for max flexibility, move the problem from engine/editor developers into the realm of module makers.  Given that there are already modules that can read/write ini files what else in the way of API is required?  Wouldn't it be a sort of restart with the current game state preserved and the new ini settings?

I suppose it is easier said than done are most things. 

Knox

Congrats on releasing 3.3! Just wondering if you have any plans to get a newer custom resolution build released with all the 3.3 changes, etc? :grin:
--All that is necessary for evil to triumph is for good men to do nothing.

Crimson Wizard

Quote from: Knox on Mon 17/02/2014 18:07:36
Congrats on releasing 3.3! Just wondering if you have any plans to get a newer custom resolution build released with all the 3.3 changes, etc? :grin:

It is currently updated to 3.3.0 RC (new link in the first post), the only difference from 3.3.0 final is a 2.72 import bug; and I will update with 3.3.1 when it comes to that.

I am going to start remaking custom res in 3.4.0 branch soon, doing some pre-planning now. Hopefully that won't take too long, I will use this version as a reference and try to avoid mistakes I did here at first.

hedgefield

Hi Crimson, I tried to import a game I made with the old Skygoblin custom resolution build based on 3.2.1 and I get this error (well, first I got the custom res order so I changed it to 1024x768 temporarily but now I get this):

Quote
An error occurred whilst trying to load your game. The error was:

Input string was not in a correct format.

If you cannot resolve the error, please post on the AGS Technical Forum for assistance.

Error details: System.FormatException: Input string was not in a correct format.

   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)

   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)

   at AGS.Types.SerializeUtils.StringToResolution(String s)

   at AGS.Types.SerializeUtils.DeserializeFromXML(Object obj, XmlNode node)

   at AGS.Types.Settings.FromXml(XmlNode node)

   at AGS.Types.Game.FromXml(XmlNode node)

   at AGS.Editor.AGSEditor.LoadGameFile(String fileName)

   at AGS.Editor.Tasks.LoadGameFromDisk(String gameToLoad, Boolean interactive)

   at AGS.Editor.InteractiveTasks.LoadGameFromDisk(String gameToLoad)

Is it anything that looks familiar to you? Any advice for changing settings so that it would import, or is this a lost cause and should I stick to my old AGS build?

Crimson Wizard

#113
I believed it may be theoretically possible to make import from 1280x720 Skygoblin's game automatic, but I never actually got to explore this path. It was a while since I saw Skygoblin's code, I need to check it again and see how that could be done.
Unlike engine, which reads binary data, and that may make things more difficult, Editor reads XML, and there are ways to override parsing, if you know how to detect the "non-standard" version.
(Unfortunately it seems no one who was making "custom" builds paid respect to setting the unique version id :-\, so we'll have to look for other opportunities).


BTW, in the worst case you may try manually edit "resolution" field in Game.agf (which is a plain XML). I wonder if that will work :); the rest of data formats should be just the same.


UPD: This does not look difficult actually. Interesting thing is that Skygoblin could not alter AGS.Native library, because it was not opensourced at that time (I think), so he did not change game format at all, instead his build reads game resolution from config file.

Meanwhile, hedgefield, here's what you can do.
0. Make a backup of your original project :)
1. Open Game.agf with any plain text editor (e.g. Notepad).
2. Search for those lines (should be at the top of file somewhere) and replace this:
Code: text

<Resolution>CustomResolution</Resolution>
<CustomResolution>{Width=1280, Height=720}</CustomResolution>

with this:
Code: text

<CustomResolution>1280, 720</CustomResolution>

(yes, first line should be erased)
That should work.

hedgefield

Crazy, that totally worked! The game loads up fine now and runs normally. It sounded like a more complicated problem, but yeah I guess it was lucky AGS wasn't opensourced back then. Thanks!

When I first imported the game, the editor made note of a SpeechCenter not being installed so its data would be removed; I'm not sure if that was an editor component? It doesn't seem like it screwed anything up yet.

And I have to say I like this implementation of custom resolutions a lot more than the skygoblin style. It makes more sense. The way it throws an error when the resolution of a room is smaller than the game's resolution is cool too, instead of awkwardly blackboxing it. It seems pretty stable so far but I'll report back if I find anything. Otherwise I can recommend absorbing it into the stable branch.

Crimson Wizard

Quote from: hedgefield on Tue 18/02/2014 19:03:03
When I first imported the game, the editor made note of a SpeechCenter not being installed so its data would be removed; I'm not sure if that was an editor component? It doesn't seem like it screwed anything up yet.
SpeechCenter is an editor plugin: http://www.adventuregamestudio.co.uk/forums/index.php?topic=45622.0
It should not change anything in game itself.

Knox

Quote from: Crimson Wizard on Mon 17/02/2014 18:22:40
I am going to start remaking custom res in 3.4.0 branch soon, doing some pre-planning now. Hopefully that won't take too long, I will use this version as a reference and try to avoid mistakes I did here at first.

Awesome news! So basically if I've been using this custom resolution build for my game up until now, I can eventually switch to 3.4 when a version is ready?
--All that is necessary for evil to triumph is for good men to do nothing.

Crimson Wizard

#117
Quote from: Knox on Thu 20/02/2014 01:48:12
Awesome news! So basically if I've been using this custom resolution build for my game up until now, I can eventually switch to 3.4 when a version is ready?
It is in plan to keep them compatible, yes.

In the worst case scenario there may be a simple conversion tool (e.g. in a form of editor plugin) to import a project from alternate version. BTW, I am now considering this as a possible solution for importing from Skygoblin's version.

Ali

I'm afraid the current winsetup options work very poorly for a large game (1920 x 1080) that needs to be scaled down.

In windowed mode, instead of offering regular 16:9 resolutions (like 1600x900 and 1280x720) it offers weird fractions like 1536x864. Most of these seem not to be 16:9 and some run very slowly. In full screen mode, it also doesn't offer any of the common 16:9 resolutions (apart from 1920x1080).

Crimson Wizard

Quote from: Ali on Mon 24/02/2014 17:23:14
I'm afraid the current winsetup options work very poorly for a large game (1920 x 1080) that needs to be scaled down.

In windowed mode, instead of offering regular 16:9 resolutions (like 1600x900 and 1280x720) it offers weird fractions like 1536x864. Most of these seem not to be 16:9 and some run very slowly. In full screen mode, it also doesn't offer any of the common 16:9 resolutions (apart from 1920x1080).
In fullscreen mode it supposed to offer the resolutions returned by DirectX or Direct3D driver. If you look into your display settings, will any more resolutions be present? Also, will that work if you set up wanted resolution manually (in config file)?

The windowed mode is not made well for downscaling, it seems...
Looks like I'll have to remake this after all. Just need to find time.

SMF spam blocked by CleanTalk