I've decided to roll back the memory code to 1.8.3 level as I was ending up creating something of a mess with too much handling of special situations going on. What I'm building up from there is looking a lot cleaner and clearer, so it was obviously the Correct Decision.
I'm also withdrawing the 1 TMU renderer from the current codebase. I've been reading the Q3A renderer (for the first time) a lot lately, and I'm quite shocked by the extent to which I've independently reinvented huge chunks of it in DirectQ. This leads me to the conclusion that it's not going to be a huge leap forward to generalise my current code better, in which case I'm going to be able to produce a better 1 TMU renderer. Trying to integrate the code I wrote into any conceivable work moving forward would not be a pleasant experience, and when a feature is holding things back to that degree the best thing is for it to either be removed or deferred.
Several long standing bugs have been fixed. One I'm particularly happy with is a heap-corruption bug in the progs.dat loader that goes all the way back to the days of MHQuake. I had worked around this by putting huge walls around the memory used by this, but now that it's gone I've been able to revert to the simpler, nicer way of ID Quake.
I've introduced an artificial limit of 65536 surfaces visible at any one time. This is not so bad as it sounds; even with r_novis 1 marcher.bsp (a good candidate for a big scene) hits maybe 11000 or so; view frustum and backface culling really does help a LOT here.
I'm also thinking that with my current code it should be possible to merge a lot of surfaces in each node together - they don't even need to produce a convex outline when done, just share the same texture and lightmap. I could easily and quickly eliminate duplicate vertices from the resulting triangle soup, although in practice I'm not certain how beneficial that would be. Preliminary tests indicate a saving of 33% best case, which needs to be weighed against the cost of additional load time (although I have code written to do the duplicate removal in linear-scaling time; takes about 100ms per 25000 verts).
Right now a major timewaster with big maps appears to be the need to run R_RecursiveWorldNode every frame. I know that FitzQuake uses a trick to only run it when the PVS changes, so I'm going to see what needs to be done to plagiarise that.
Finally, I'm interested in hearing from any of the 5 people (to date) who have downloaded the Windows 98 build. Did you download it for use on Windows 98, or did you download it just because? If the former, did it even work? If it didn't, what happened? Did you try compiling and testing the code yourself?
It's no major difficulty to produce such a build, but all the same if I'm going to continue doing so I'd like to know if it would be worth my while.
Saturday, April 24, 2010
Current Status of Several Items
Posted by
mhquake
at
10:51 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment