Wednesday, February 10, 2010

External textures, fog, and other miscellaneous grief

I'm hitting into some anticipated trouble with my external texture loader at the moment, specifically the total lack of standardisation for locations to load certain texture types from. Specific examples: skyboxes can come from gfx, gfx/env or env, hud pics can come from gfx, textures/gfx, textures/wad or textures/gfx/wad, and model skins can come from progs or textures/progs. All of these need to be supported as they are all currently in use by mods. Having to do a search through the filesystem for each and every possible location, and for each and every possible file type, then flagging special types that need additional paths no longer cuts it. This has already led to some quite messy code, so it's time to start tackling it head-on.

The plan is to enumerate all supported file types irrespective of their location on startup or game change. These can be stored in an array (possibly with pointers to the first letter of the name also stored for faster searching) which then needs to be checked only once for each texture that's loaded. The combination of a single check from memory instead of from disk that's valid irrespective of file type or location should give us substantially faster map loading too (at the expense of slightly slower startup and game changing). It will also mean that nice things like a skybox browser (with preview) or even a screenshot browser would become possible, but I'm not going to commit to either of those.


Some weird crap happening with fog. It transpires that if you size down the screen, then size it back up again, fog actually does work. This definitely needs more investigation. When I brought fog back to 1.8 I literally copied and pasted the old code across, so I'm not too surprised that things are behaving funny.
I think I'm likely going to end up implementing a "lite" version of the Q3A shader system for DirectQ. This would - in it's initial incarnation - be completely hard-coded into the engine itself, but could in the future evolve to outside the engine (but with a set of hard-coded defaults). I'm not certain yet if this is going to be a 1.8.x or a 1.9.0 feature, but I'll find out. Bottom line is that there are things I need to do with the renderer - including the famous re-integration of the different paths - that will need me to move most of the way in that direction, so I figure I might as well go all the way.

6 comments:

Jeffrey said...

..Now I like the sound of implementing any sort of version of the Q3A shader system into DirectQ. Now this begs the question when are you implementing support for MD3? I don't know of any shader mods for Quake, but I know of several MD3 weapon, item, and ammo model replacement paks I use in Darkplaces, FTE, JoeQuake, & Qrack on a regular basis.

mhquake said...

I haven't implemented MD3 yet basically because I don't like the models available - I would be of the opinion that they're not consistent with the Quake 1 look and feel.

That's no real reason of course, so if I can get MD3 rendering from the same code as MDL it might be an idea. It will be competing with other priorities of course.

Jeffrey said...

OK... Well the average “Joe” may not care, but that’s not the point. I can understand you have your priorities, but using my argument above why (in your mind other than you personal preferences) would implementing shaders take precedent over model support? The Rygel texture add on pack as an example has md3 replacements for eyes, lava ball, teleport ball, etc. I do believe I even has some md3’s in my prydon mod as well (can’t remember). It’s your hobby I’m just curious. Thanks…

mhquake said...

Groundwork and laying foundations is where it's at. I'm not talking about implementing Q3A style shaders for gee-whizz effects, I'm talking about building a renderer that's clean and extensible, has less bugs, and won't cause grief or upset if any new standard needs to be supported. Right now for example MD3 could be done, but would require writing, testing and bugfixing a full second renderer for models. A Q3A shader system that's reasonably generic would remove about 50% of the work, and would also make MD2, alpha test surfaces, and a lot of other weird stuff that already exists in released maps easier to do (and therefore more likely to be done).

DirectQ's renderer by the way already has more in common with Q3A than it does with Q1, so really all we're talking about is a state system and a means of inputting triangles to get there. Reading .shader files will naturally follow, but it's out of scope for now.

Other priorities are bugfixing and making sure that things work the way they should (the 2D HUD objects I did yesterday, for example).

Jeffrey said...

..That was a really great reply to my question. Thank you! Rock on...

mhquake said...

Pleasure. I'm a big believer that if I'm going to say "no" or "not yet" then at least I should explain why.