I've been doing some more cleanup of gl_vidnt.c - it's still an unholy mess, but it's getting less and less so by the day. This is mostly consisting of removing old software compatibility stuff, totally reworking video mode handling (so that it's actually marginally understandable) and removing a lot of the globals. Shortly going on to the video commands.
I see that Entar is crying out (?in jest?) against my use of the Registry. Muhahahahahah. Seriously though, some further comment on this does seem merited. It does make sense to use the Registry for this purpose; it's far cleaner and far more robust that pre-parsing a config.cfg file, and it is made for storing this kind of setting. For what it's worth, I only store the initial video mode settings in it, it uses HKEY_CURRENT_USER\Software\MHQuake, and it's been coded to fall back on the desktop mode if anything invalid is found in there.
I for one believe that video modes are also something that most people will only set once and then leave be forever after. They will also be used globally for all games, not separately for each game. I can't imagine that there are many people who prefer to play Hipnotic in 640 x 480 fullscreen but ID1 in 1152 x 864 windowed, for example (and I just know I'm asking for someone to come and prove me wrong here...) Having to set them individually in each config seems a bit of a silly thing, and remember: it's all about making things easier for the players at the end of the day.
The Registry has gotten a bit of a bad rep in the past, but this is primarily from the bad old days of Windows 9x, when if you so much as sneezed at it, things went wrong. It's a lot more robust and stable nowadays, and maybe late switchers to a proper NT-based OS (I was on Windows 2000 since the day it was released) just have a little bit of catching up to do in terms of confidence in it.
I can understand arguments both for and against the Registry vs. config files. I personally dislike having a multitude of config files scattered all over the place, but I can see them being useful for certain purposes (although I don't buy the "human-readable" argument: it's perfectly possible to create an unreadable mess of a config file, just as it's also possible to have a logical, clean and human-readable structure in the Registry). Believe me, one of the options I considered was a config file in Documents and Settings\Username\Local Settings\Application Data, but in the end that option lost. Why? Simply because there's a perfectly good and usable Registry API that already exists, that can handle multiple different types of data, and that is tried and trusted, tested for over a decade, debugged code.
Bear in mind that I'm not trying to justify a controversial choice here, certainly not having a pop at Entar (who's work I respect), and most definitely not trying to take sides in any holy wars (my previous paragraph should have made that clear!) I'm just outlining the reasoning and thinking behind my decision. If anyone still baulks at this, or refuses to use my engine because it uses the Registry for a mere 4 config settings, well so be it.
Finally, the bugs mentioned below have now been fixed.
Tuesday, June 3, 2008
More video work (and thoughts on the Registry)
Posted by
mhquake
at
9:52 PM
Labels: General Tech, MHQuake
Subscribe to:
Post Comments (Atom)
3 comments:
Yes, it was mostly in jest, though I do generally dislike programs modifying the registry, mostly because they could just be self contained in their own little folder, not bothering anyone else, or leave any residual data behind. Maybe it is just bad experience from earlier times. Although I will say it's much easier (and less dangerous) for a user to directly edit a config file than it is to edit the registry.
I suppose the same could be said about using the Application Data folders (leaving residual data behind, using folders outside of their own). I take your point about config files being less dangerous, although my own experience is that people who are inclined to modify the registry will do so anyway (and in far scarier parts of it than HKCU), whether encouraged or not. I wouldn't encourage or require anyone to modify the registry directly to change resolution, the engine will do that for them, and it has safe fallbacks built in if the settings in there are invalid.
the down side of using the registry is that it is inconsistant with all the other settings in the game. There are more commandline arguments than just the video settings, eg, particle limits, game directory, disabling the cd player code.
Imho its better to fix up the cvar/commandline code so cvars can be set in configs before the video mode is initialised. But this requires more effort.
Using a single config for all user settings/binds/resolution/etc in their home directory is more 'quakey' than using the registery, especially when you support more than just windows. Plus it avoids conflicts with other engines (darkplaces anyone?)
The registery works, its just platform specific and inconsistant.
Post a Comment