Indexing the alias models has been a substantial improvement and I'm now getting framerates in the 40s in scenes in ne_tower that used to drop into the 20s. Right now I've dropped back to drawing each model individually (just to keep the indexing step simpler), so so the next step is to batch them all up together again. This should see more improvements, and I think at that point I'll have taken alias models as far as I'm going to for this release.
I'm going to need to abandon chained linked lists here as they're just not working out for me; crashes still happen with fundamental stuff like running screenshots. Instead I'll either pop them into a flat array and qsort that, or maybe even just qsort the visedicts list. (I'm getting a bit concerned about how many times I'm using qsort per frame though, but there are other areas I use it where it can be removed: alpha sorting can be done via the BSP tree, for example, and instanced model surfs can be linked in clever ways into the texture chains; I'll wait and see if it becomes a problem).
Before I do any of this, and especially before I press ahead with the remaining items in the render, I need to go back and clean out my handling of sky and solid surfaces. There's quite a huge C++ class managing them at the moment (I might release it just for laughs some day; say in about 2064...) which I had written to simplify adding arbitrary surface types at arbitrary stages of the render setup. Now that I've gotten that out of my system (like I said I would a few days ago) I'm going to simplify the whole setup and tune it for the specific requirements of these surface types. This should see some more improvements, and potentially speeds getting back to close to 1.7 levels for ID1 timedemos.
While tracking down the SCR_UpdateScreen crashes I've made some other small changes. Instead of confronting people with the console when starting up, DirectQ now has a loading screen with a progress meter showing how far into startup it is. The console is still there, and you can still use it exactly the same way as before, but I think it's nicer not to dump new users directly into a command-line interface (yes, there are new Quake users), especially in 2010.
I think I'm going to remove "exec quake.rc" and replace it with default/config/autoexec, then bring us to the main menu at startup. I think this is probably preferable to the Necropolis demo, which everyone is probably sick of by now. Having done that I'll then replace writing config.cfg with writing a "directq.cfg" instead, so that DirectQ will play nicer when living in the same directory as other engines. The directq.cfg will also then be included in the startup order, and config.cfg will only be used if directq.cfg is not found.
This is fairly speculative stuff right now, so I'm interested in opinions and feedback. I'll note however that other popular engines also do the "no demo loop" thing, and use of custom cfg files is standard for QuakeII ports, so precedent is set and my conscience will be clear.
Monday, January 4, 2010
More fun with Alias Models/Speculative stuff
Posted by
mhquake
at
6:15 PM
Subscribe to:
Post Comments (Atom)
1 comments:
I'm all for a directq.cfg and removal of the "exec quake.rc"!
(Also that loading screen thingy sounds like something all clients should have ;)
Post a Comment