The enforced layoff from the more intense stuff is doing me good, I'm getting the chance to tidy up all sorts of smaller nooks and crannies that I'd been letting things slip on.
Today I got skyboxes done, including loading sky from the worldspawn. I keep on bringing up skyboxes as an example of the lack of standards, but they are probably the classic example - they can come from /gfx/env, /env, and I've even seen one mod with them in /gfx; they can be any image format (not too big a bother that); can have an underscore between the name and the suffix or not; having all of them present is strictly optional; and the worldspawn key can be called any one of 4 reasonable things. Thankfully I built my texture loader to be able to cope with exactly that kind of abuse, so it wasn't too difficult to handle it all. Crazy and unnecessarily nonetheless.
Also some useful work on managing the sv.edicts array better; I no longer allocate 8192 at load time, but instead make a count of the entities in the map and allocate that number + 64 (but never less than 512), then expand as required (in batches of 128 - should this be lower?) at run time. It's not safe to expand dynamically at load time as the array is in use then, and doing so requires changing the pointer. This is a massive memory saving; about 5-6 MB for a typical map.
Wrote a PCX loader so I now support Link, TGA, PNG, DDS, BMP, JPG and PCX. I think that's enough image formats; Direct3D is capable of doing a handful more but they're a bit more esoteric. The TGA loader seems a bit fussy about formats, there was one I failed to load during testing, but opening it and saving it again in a standard image app worked fine. Obviously some kind of padding at the end. I might replace the builtin loader with one of my own; Microsoft's support for TGAs is a bit suspect anyway.
Been doing some thinking about DrawPrimitive vs DrawPrimitiveUP in D3D. All the documentation and advice gives dire warnings about DrawPrimitiveUP; it's slow, it's not flexible, performance will go through the floor, etc. Yet I've been using it pretty extensively, and have done fairly regular (about weekly) benchmarks in PIX, and I've never seen a difference. The stats fully support this; DrawPrimitiveUP is equally as fast, and is perfectly suited to situations where you don't know your vertex data in advance (I still use regular DrawPrimitive when I do). Seems to me that the overhead of locking, writing to, and unlocking a vertex buffer (or a number of them in some cases) each frame is just not worth it. Also seems to me that Microsoft have this fixation with loading everything into big static buffers and then drawing from those, which is probably a hangover from the old days when D3D used Execute Buffers. Still trying to justify a bad decision from over 12 years ago? Who knows.
Monday, January 12, 2009
Posted by mhquake at 11:35 PM