Sunday, July 11, 2010

Updates for 11th July 2010

Texture compression has now been removed, unless anyone can come up with a compelling reason to keep it. Performance loss is in the order of 1 or 2 percent on ID1 timedemos and non-existent in bigger, more complex scenes.

Draw_PicFromWad and Draw_CachePic have been largely merged into a single function. I don't like Draw_CachePic and am going to remove it and just preload all the necessary pics at game startup time instead. This will make game startup take a little longer but will prevent temporary hitches when you access menus for the first time. I can see the sense in it back in the days when you had to co-exist with a software renderer and run on a machine with limited texture memory (only load what you need, and wait until you're certain you need it before loading it), but it's quite irrelevant, silly and over-complicating things today.

I also want to change the in-memory picture format. Having to cast the data member of a qpic_t to a glpic_t is a horrible hack that deserves to be grabbed by the ears and shown where the door is. That probably won't happen this time around though.

DirectQ now runs through a test ChangeDisplaySettings call before admitting a display mode that Direct3D reports back to the family. GLQuake did the same, but with D3D there should be no need for it - tighter coupling to the windowing system and video hardware means that it should give you valid modes all the time. It just feels a little safer this way though, especially now that I'm allowing the end-user to change more things with the selected modes.

I need to get a new beta version out to people for testing to see if the refresh rate changes I have made have been effective in eliminating reported crashes. I'm going to wait until I have the next round of changes made (to the 2D pic system) before doing so, however.

The current status is that correctly handling sub-pics for the QuakeWorld HUD is now the only real major item remaining on my to-do list. There are a few other more minor ones that are either less critical or will be left to the next release after.

Correcting brush model alpha in the fixed functionality path is not critical. At the present moment there is some kind of alpha present, but it doesn't blend correctly when you have multiple models layered on top of each other in the Z-order. The same probably applies to r_wateralpha. Either way I don't see it as a show-stopper as neither of these are used extensively in mods, and both work correctly in the HLSL path (which most people will have and be able to use).

There is also another issue with brush model alpha where there appears to be at least two standards in use for setting alpha. That used by Spirit's Engine Test Map doesn't work in DirectQ at the moment, but that used by Remake Quake does. I suspect that this might be a progs.dat or protocol issue, and will probably investigate further and fix it if possible before release.

Half Life BSP support isn't going to happen this time round. Most of the support required is already there, and an earlier version of the engine actually was able to load them OK, but I changed the palette handling a few versions back, and have changed it again for this version, and still haven't gotten round to integrating it properly yet. It may crash in other places too; this hasn't even been tested for a few months.

To be honest I see this as being more of a novelty feature than anything else. OK, it's kinda neat to be able to run Half Life maps in a Quake engine, but what does it actually gain you? What does it achieve? There are no mods out there that seriously use the Half Life BSP format, and until such a time as one appears this feature is purely window dressing.

Long map names in the Save and Load menus still need proper handling. For now I'm probably just going to chop them off at the max supported by the display. Having a clean and clear display seems more important to me than showing all of a cutesy map name.

External textures for HUD and Menu items need to be tested again. Not really a big deal as the new code was written with support for these in mind, but I just need to be sure that I've missed nothing.

That's about it for this version; most of what's needed could potentially be turned around in a very short time, but I do want to take some extra time out to ensure that nothing nasty has managed to sneak in. With hindsight it's possible that too much code has changed with this one, but done is done and going back would be a little silly right now. If nothing else it should make 1.9 a little easier!

1 comments:

MK said...

Agreed. Precaching all menu graphics also helps when running from devices with lower access speeds, such as CD-ROM drives and some cheap flash drives.

The Help screens are the only ones big enough to have any significant impact in the memory usage (320*200*6 = 384000 bytes), so you may probably leave them out until the Help menu is called.