> From: James Paige <[email protected]>
> 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 <[email protected]>:
> > >> From: Ralph Versteegen <[email protected]>
> > >> 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.
_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
http://www.doteasy.com
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
