View previous topic :: View next topic |
Author |
Message |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Thu Dec 04, 2008 4:47 pm Post subject: |
|
|
Getting rid of the double-switch can involve quite a bit of work - either deferring all video startup (and anything else that relies on it) until after the configs are loaded (and you better make sure you have your cvars registered outside of the relevant _Init functions) or loading the configs twice. Either way it's messy.  _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Thu Dec 04, 2008 5:47 pm Post subject: |
|
|
mh wrote: | Getting rid of the double-switch can involve quite a bit of work - either deferring all video startup (and anything else that relies on it) until after the configs are loaded (and you better make sure you have your cvars registered outside of the relevant _Init functions) or loading the configs twice. Either way it's messy.  |
Certain cvars don't fit well within the config.cfg system of doing things. I'm sure this has been discussed before, I think there is a thread where you had discussed the idea of storing certain ones elsewhere.
The ones that are entirely inappropriate for config.cfg way of doing things are:
1. brightness/gamma/contrast
2. video setup
3. anything to do with the mouse input
4. memory and gl rendering cvars that aren't gamedir preferences (gl_fullbright would be an example)
5. Stuff like AVI capture cvars
This is because there is no purpose of every gamedir having their own set of those cvars in a config.cfg. The above type of settings would almost exclusively be something you'd want every single time.
Adding to list of good tutorial ideas:
Saved command history (I believe this feature first appeared in SonsQuake, but I know this only from the JoeQuake readme.txt or maybe the source).
But furthermore, I like how ezQuake improved on the command history; JoeQuake's cmdhist.dat is not "human readable" whereas the one in ezQuake is a text file. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Thu Dec 04, 2008 8:49 pm Post subject: |
|
|
Baker wrote: | Certain cvars don't fit well within the config.cfg system of doing things. I'm sure this has been discussed before, I think there is a thread where you had discussed the idea of storing certain ones elsewhere.
The ones that are entirely inappropriate for config.cfg way of doing things are:
1. brightness/gamma/contrast
2. video setup
3. anything to do with the mouse input
4. memory and gl rendering cvars that aren't gamedir preferences (gl_fullbright would be an example)
5. Stuff like AVI capture cvars
This is because there is no purpose of every gamedir having their own set of those cvars in a config.cfg. The above type of settings would almost exclusively be something you'd want every single time. |
I remember that idea!
Unfortunately, I've learned that any kind of changed behaviour like that is a breaking change so far as mods are concerned. It's unlikely, but you never really know when a mod is going to use one of those cvars in an unexpected manner. I mean stuff like "my mod only works on GLQuake, I need a spare cvar to stuff a setting into, so - hey! - I'll use vid_mode". Party like it's 1996.
Not that any mod author here would do that, but here is far from a high percentage of mod authors. And the reaction will be "your engine sucks, my mod blows up on it". (Do I sound like Raymond Chen yet?)
Of course, any cvars you introduce yourself are fair game. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Sat Dec 06, 2008 12:16 am Post subject: |
|
|
mh wrote: | Getting rid of the double-switch can involve quite a bit of work - either deferring all video startup (and anything else that relies on it) until after the configs are loaded (and you better make sure you have your cvars registered outside of the relevant _Init functions) or loading the configs twice. Either way it's messy.  |
Loading configs twice is probably the way to go -- inelegant, but not really that messy.
Another approach is to add a PostInit callback for all modules, so that Init creates the cvars, but PostInit would act on them after the configs have been read, for example VID_PostInit would actually create a window.
Hmm, I guess a third approach would be to create cvars as they are encountered in config files, even though they are unrecognized. When later they are initialized, the pre-existing config value could be preserved.
This is also one of the ways to address the problem of people who use two engines, where each engine drops the other engine's unique cvars, losing settings between sessions. (Though another, possibly better way to fix it is for each engine to save their own enginename.cfg which gets read before quake.rc) |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Mon Dec 08, 2008 11:58 pm Post subject: |
|
|
frag.machine wrote: | A tutorial showing how to implement a reliable way in GLQuake to change screen resolution and modes on the fly. I tried copying this from some engines but it was erratic to say the least (and usually just crashed when running in older GL cards and/or with buggy drivers). |
Done.
I included the changed source files as well, as the tutorial is a little cumbersome with the quantity of changes in gl_vidnt.c
http://forums.inside3d.com/viewtopic.php?t=1293 |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Tue Dec 09, 2008 10:29 pm Post subject: |
|
|
Baker wrote: | frag.machine wrote: | A tutorial showing how to implement a reliable way in GLQuake to change screen resolution and modes on the fly. I tried copying this from some engines but it was erratic to say the least (and usually just crashed when running in older GL cards and/or with buggy drivers). |
Done.
I included the changed source files as well, as the tutorial is a little cumbersome with the quantity of changes in gl_vidnt.c
http://forums.inside3d.com/viewtopic.php?t=1293 |
Heh, thanks... I just downloaded and taking a first look on it. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Sun Dec 14, 2008 8:24 am Post subject: |
|
|
A tutorial I know I wish existed is one that does the DarkPlaces method of substituting missing models with a generic "this model is missing" "model" on startup instead of crashing and burning.
Speeds up testing QuakeC when something isn't right and all you care about is the QuakeC, not whether or not some model is there.
As I imagine this is probably not hard to do, I might investigate and write it up in the next week or so. |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Tue Dec 16, 2008 2:31 am Post subject: |
|
|
maybe just substitute the portion that would call "missing model" with a generic precache of the NULL model?
Code: |
if (cl.model_precache[i] == NULL)
{
cl.model_precache[i] = Mod_ForName ("progs/NULL.mdl", false);
}
|
maybe? |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Dec 16, 2008 3:46 am Post subject: |
|
|
r00k wrote: | maybe just substitute the portion that would call "missing model" with a generic precache of the NULL model?
Code: |
if (cl.model_precache[i] == NULL)
{
cl.model_precache[i] = Mod_ForName ("progs/NULL.mdl", false);
}
|
maybe? |
Almost. But the above is depending on external file!
Adding a feature to an engine to be able to run QuakeC when the model is missing shouldn't depend on a model that could be missing
i.e. What if it can't find null.mdl? |
|
Back to top |
|
 |
MeTcHsteekle
Joined: 15 May 2008 Posts: 397 Location: its a secret
|
Posted: Tue Dec 16, 2008 3:52 am Post subject: |
|
|
hmm, i think acquiring a null.mdl wouldn't be a problem because a lot of mods seem to have them, and you can always make your own with almost no effort, unless you want a cuowal null model.... _________________ bah |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Dec 16, 2008 5:05 am Post subject: |
|
|
It looks like the basics of what DarkPlaces is going is adding a "loaded" field to model structure and setting it to true if the model was successfully loaded.
If it isn't loaded it prints a warning on load first and later come rendering time, it doesn't draw the model and uses an alternate effect to just render an object where the missing model should be. |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Tue Dec 16, 2008 6:27 am Post subject: |
|
|
what if null.mdl can't be found?
Oh wait, that's easy to fix, just create a null_null.mdl |
|
Back to top |
|
 |
Spirit

Joined: 20 Nov 2004 Posts: 476
|
Posted: Tue Dec 16, 2008 10:05 am Post subject: |
|
|
Why not "embed" a simple model in the engine itself? I guess that is how Darkplaces does the colourful diamond. _________________ Quake Maps |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Dec 16, 2008 10:46 am Post subject: |
|
|
Spirit wrote: | Why not "embed" a simple model in the engine itself? I guess that is how Darkplaces does the colourful diamond. |
Yeah, that might be what I end up doing. |
|
Back to top |
|
 |
|