Been doing some benchmarking with the external texture loader in DirectQ. I've a stated intention to simplify this code, but the end result is that I'm not going to just yet. The primary reason is performance. A test simplified version ended up loading maps at up to one tenth the speed that the current (quite messy) version does, and I'm not prepared to take that hit.
I'll need to fork the codebase and do some experimental work before I'm happy to proceed down this route.
I'm at the stage where I honestly can't remember the status of some of the older bugs people reported with this, so if you'd like to remind me, and if they're still present, now would be a good time to make yourselves heard.
A potential crasher in the cvar subsystem has been caught; this is so highly unlikely to happen that it's silly, but just for the sake of doing things right it's nice to have.
I need to sort out some visual glitches that can happen when crossing water surfaces. This is generally only a problem if you have a powerup activated, but it looks ugly and wrong. I fear that the root cause of it is down to client/server timer separation where one of them thinks you're still underwater but the other doesn't (or vice-versa). If this is the case then it may be unfixable.
RMQ-wise we're gearing up for a demo release shortly. On the engine side there's not really much to be done (and I don't like bigger changes this close) but I'm on standby in case something needed does come up. There are a lot of interesting things shaking out of the final stages of work which it's definitely premature to talk about right now, but over the coming months as things settle down and decisions get made I'll probably write a little about some of those.
The one that it's not premature to talk about is IQM support. I've learned that there is now an IQM version 2 which fixes some subtle bugs in version 1. Changes are minimal, but they are still breaking changes. My initial thought was to junk IQM version 1 and go direct for version 2, but I'm starting to think that supporting both would be preferable.
We're not certain yet if we're going to require IQM for the coming demo, but overall we do want to put our collective weight behind supporting the format and do want to see it becoming something that gets more widespread engine support in the future. While I have my own personal list of things I actually dislike about it - with the inability to animate on the GPU being top of that list - as skeletal animation formats go (in the context of Quake technology) it is something that it just makes sense to do.
Thursday, June 9, 2011
Update for 9th June 2011
Posted by
mhquake
at
9:31 PM
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment