[Ohrrpgce] gfx_directx, zoom level

[Ralph Versteegen]

2009/12/27 Jay Tennant <hierandel8 at crazyleafgames.com>:
>> From: James Paige <Bob at HamsterRepublic.com>
>> Sent: Saturday, December 26, 2009 5:09 PM
>>
>> On Sun, Dec 27, 2009 at 05:44:30AM +1300, Ralph Versteegen wrote:
>> > 2009/12/27 Jay Tennant <hierandel8 at crazyleafgames.com>:
>> > >> From: Ralph Versteegen <teeemcee at gmail.com>
>> > >> Sent: Thursday, December 24, 2009 10:45 AM
>> > >>
>> > >> For a few years, the default zoom level between all the graphics
>> > >> backends has been 2x, and before that, they defaulted to fullscreen.
>> > >> I've always been a bit unsure about that default, and unhappy that
>> > >> there was no way to resize the window without using a commandline
>> > >> option. I've heard complaints that 2x is too small, especially on
>> > >> large monitors.
>> > >>
>> > >> Now gfx_directx lets the user resize the window to any resolution.
>> > >> Unfortunately the options to set the size to an integer multiple of
>> > >> 320x200, from earlier versions, are no longer there, but Jay says he
>> > >> will work on a replacement. Anyway, Jay set the default at 3x zoom.
>> > >> I'm finding this annoying in Custom, where it takes up the whole of my
>> > >> small monitor. If we want to try using it as the default, we probably
>> > >> should change the zoom to 2x to avoid annoying other people? I do find
>> > >> 3x or fullscreen better for playing. Maybe Custom and Game could use
>> > >> different defaults.
>> > >>
>> > >> I really wish we had preference files and a configuration screen.
>> > >
>> > > What if there were an ascii-text based custom.ini and game.ini? A list of preferences could be contained and loaded from either the backends or the engine. If loaded from the backends, they could also save their last state as the default for when the app runs next. So if a user runs game.exe at 960x600 in the upper-left corner of their screen with smooth rendering, the next time the app boots, it will attempt to build the window at 960x600 in the upper-left corner with smooth rendering, etc.
>> > >
>> > > We could write a set of standard interfaces, such as:
>> > > int gfx_QueryPreferences(gfx::Preferences* pPreferences, const char* szFile);
>> > > int gfx_SavePreferences(gfx::Preferences* pPreferences, const char* szFile);
>> > >
>> > > And if the engine is loading preferences (which would make more sense), a set of interfaces could communicate with the backend:
>> > > int gfx_SetPreferences(gfx::Preferences* pPreferences);
>> > > int gfx_GetPreferences(gfx::Preferences* pPreferences);
>> > >
>> > > The Preferences structure could contain state about width, height, top-left window corner position, full-screen state, smoothing state, screenshot format, vsync, etc. Not all the data would need to be used by all the backends. Any function that fails returns 0. Then we could move command-line options to the engine for setting preferences for uniform functionality.
>> >
>> > Yes, I agree completely. I've been meaning to suggest this for a few
>> > weeks, when I have time I'll talk about it in more detail. The engine
>> > should read/write the files and communicate with the backends.
>> > Probably the preference files should store options for each backend
>> > separately.
>>
>> I am on board for this too. In the olden-days I was uncomfortable with a
>> prefs file, but my reasons for opposing it have long since all melted
>> away.
>
> Could the files be used for more than the graphics backend? Maybe they should not be related to the graphics backend, except for the gfx_SetPrefs/GetPrefs. I suppose they could store backend priority, volume, and maybe file paths for app files. Well, maybe not volume. I think the preferred backend should be saved in the .ini files. And file paths? I don't know. Sounds like it's mostly related to the graphics backend anyway.

There are plenty of non-graphics-backend things that would go in the
preference files. Preferred graphics and music (hope to make that
run-time selectable some day as well) should definitely be in there. I
think that there should also be a set of editing preferences, but we
don't have much to put in them yet..