Future Tutorial Ideas ...

[mh]

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.

[Baker]

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.

[mh]

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.

[mh]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I thought about this and decided to do the following: http://mhquake.blogspot.com/2008/12/tho ... y-and.html

[metlslime]

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)

[Baker]

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

viewtopic.php?t=1293

[frag.machine]

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

viewtopic.php?t=1293

Heh, thanks... I just downloaded and taking a first look on it.

[Baker]

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.

[r00k]

maybe just substitute the portion that would call "missing model" with a generic precache of the NULL model?

Code: Select all

      if (cl.model_precache[i] == NULL)
      {
         cl.model_precache[i] = Mod_ForName ("progs/NULL.mdl", false);
      }
   

maybe?

[Baker]

maybe just substitute the portion that would call "missing model" with a generic precache of the NULL model?

Code: Select all

      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?

[MeTcHsteekle]

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....

[Baker]

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.

[metlslime]

what if null.mdl can't be found?

Oh wait, that's easy to fix, just create a null_null.mdl

[Spirit]

Why not "embed" a simple model in the engine itself? I guess that is how Darkplaces does the colourful diamond.

[Baker]

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.