And once again I've done nothing since the last post. Well I did say that I was going to collapse for a month after getting 1.8.0 out - plus there's lotsa Real Life to catch up on, and generally having a good time (despite the appalling weather we're currently getting).
Right now I still can't make promises about when I'm gonna be picking things up again, but overall I'm of the opinion that the current break is a Good Thing for this release in that it gives bugs and required features a chance to shake out of the ether.
There will probably be something that's not DirectQ-related happening shortly, however. I'm not quite ready to say what it is just yet, but it will most likely happen sometime early next week.
I'll continue posting the occasional status update to confirm that I'm still around and haven't given up on this, and as soon as I do pick up again the first place you'll hear about it is here.
Friday, February 26, 2010
Almost March...
Posted by
mhquake
at
11:09 PM
6
comments
Tuesday, February 16, 2010
More fun with Sound
Switching sampling rates at run time is now done; I didn't have to rewrite any of the main sound subsystem to get this, so happy days.
I've decided to just go with the extra memory overhead from old sounds which are still in memory but no longer valid; this will be a coupla MB absolute maximum (and will be cleared on the next map change), but I'm assuming that restarting the sound subsystem (or changing the sampling rate) is not something that you'll be doing over and over again while a game is running. I might revisit it at some point later on.
Posted by
mhquake
at
7:50 PM
0
comments
Monday, February 15, 2010
Fun with Sound
I've been doing some more work on the sound subsystem, as there have been a few outstanding items with it. What I'm hoping that you will be able to do is:
- Specify a sampling rate on the command-line using -sndspeed; 11, 11025, 22, 22050, 44, 44100, 48 and 48000 will all be supported values (the lower figures are just bumped up to the higher ones to let you use whichever method you prefer).
- Change it at runtime using the s_khz cvar (name chosen because that's what Quake II uses) using the same values - this can happen even while a map is running.
- Restart the sound subsystem at any time using the snd_restart command. May be useful if sound goes screwy on you. It will auto-restart if s_khz changes (this is a very fast operation).
- Have a menu option for this too (possibly).
One thing that does happen is that - because sounds need memory allocated for them - we have a little extra overhead from the old discarded sounds until the map is either changed or reloaded. In practice it won't affect anything, but I do however think that I might change the memory handling for sounds to prevent this. I also want to change a few other things in relation to how DirectQ handles sounds in general, as the default ID implementation is now becoming quite clunky and awkward to work with.
Overall though I'm thinking that I'm going to put a good run at this one, as I'm overdue a decent batch of work, and this seems a nice cure for renderer burn-out.
Posted by
mhquake
at
10:03 PM
7
comments
Thursday, February 11, 2010
External Textures
OK, the new external texture behaviour is:
- DirectQ no longer cares where in your gamedir you put external textures; it can load them from anywhere.
- Prefix a directory name with "_" to skip all textures contained in that directory and it's subdirectories.
- The following formats are supported: .link, .dds, .tga, .bmp, .png, .jpg (also supports .jpeg) and .pcx, in load order preference.
- Loading from PK3, Zip, PAK or the filesystem is supported.
- The "_cable"/"_bolt"/"_arc"/etc convention is used to differentiate ID1 textures with the same name but different images; MD5 checksums are used to verify that the image actually is really different.
- Linked textures need not be in the same path or use the same storage type as the original .link file. Recursive links are fully supported (until you run out of stack space).
- The DarkPlaces naming convention is used for alias model and sprite skin/frame numbers (required because both s_light.mdl and s_light.spr exist in ID1).
- This applies to all texture types that are used by Quake with the exception of the particle dot, the automap "you are here" indicator, and crosshairs (some day it will apply to those too).
Posted by
mhquake
at
12:53 AM
2
comments
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.
Posted by
mhquake
at
8:45 PM
6
comments
Monday, February 8, 2010
No fog!
Just fooling around with a few maps getting back into the swing of things, and I've noticed that fog somehow became broken at some point. Added to the list of things to fix.
Posted by
mhquake
at
11:37 PM
7
comments
Maps and Demos Menus
Been doing some more work on getting these accessible from the simple menus. The first cut had them in the Single Player menu, which seemed logical but - owing to the lack of proper menu gfx - ended up looking something like this:
Rather vile I think you'll agree.
The second cut has them in the Options menu, which is a bit counter-intuitive but by doing so I was able to group them with the "Change Game Directory" option, like so:
Quite a bit better I would say, and at least we have a logical grouping. I'm still open to suggestions from anyone who might have a better idea, but bear in mind what happened with the SP menu, and that they can't go in Main for the same reason.
Posted by
mhquake
at
8:32 PM
4
comments
Skybox speedups
I've just picked things up again and the first thing that's been done is a potential speedup for scenes with skyboxes, achieved by adding back in the old code for skybox clipping.
I'm still chewing over my idea for reducing vertex submission even further however. There are a few tricky bits I can see coming up in it, and it might end up having a speed gain in one part of the renderer at the cost of an equal or greater speed loss elsewhere, so I'm not certain if it's worth it.
One possible test might be to drag out some older code and port a few things over to it, but time will tell.
Posted by
mhquake
at
8:12 PM
0
comments
Monday, February 1, 2010
It's been a short while...
...and will be a short while longer. After the last few changes for 1.8.2 I've started feeling the need for a break from this; mostly because the 1.8 renderer really burned me out a little and I'd gone as far as sheer momentum would take me.
But stay tuned nonetheless as I'm just breaking from the coding element; I'm still tumbling ideas around in my head and might have another decent speed increase coming along!
Posted by
mhquake
at
10:06 PM
0
comments