Here's what we have so far for 1.7.666b:
- Set minimum far clip to 4096 so that it plays nice with maps/mods that expect it.
- Fixed menu shortcut keys/commands not allowing you to exit from menus properly.
- Fixed vid_restart and state restore at fullscreen console.
- Cleaned up game changing a little.
- Restored mouse pointer is visible in menu and console screens with windowed mode.
- Forced r_wireframe to always off in multiplayer (potential wallhack).
Waterwarps are a slightly contentious issue, and I want to take the opportunity to explain why they are the way they are (a fixed subdivide size of 24 with no option to change it).
We all know that default GLQuake waterwarps are horrid. Now, there are a few different possible solutions to this, and I have explored the following:
Using a bigger subdivide size
Huge performance improvements, but water surfaces break up horribly again.
Using a pixel shader
Previous releases of DirectQ did this, and it worked fine and performed well, but it did end up locking out anyone who's 3D card didn't support pixel shaders.
Using render to texture
I had this in once, and once again it worked fine, but it could consume up to 80MB of video RAM for a set of 4 textures, and it was really really slow (especially if you didn't have hardware mipmapping available).
Abandon classic Quake warps and do it another way
DarkPlaces does this, any my honest opinion is that it's incredibly ugly. There might be other ways as well, but we're getting into the territory of creating new art, which is something that can't be manufactured on-demand.
Restore a variable subdivide size
I thought about this, I really did, but it falls into the territory of offloading responsibility to the user. There's also the question of what the default should be. I know that whichever I pick someone somewhere will report it as a bug, and continue reporting it as a bug even after 6 months when I've already explained what's happening and put up posts everywhere explaining it (that's already happened with other things, by the way). I prefer a more general purpose solution if possible.
The position is that we have to accept a tradeoff of some kind, and the factors involved include more than just performance; there's also compatibility with a wide range of systems, resource usage and visual appearance to take into account. Where things currently stand is that DirectQ's chosen tradeoff is - to my mind - the lesser of many evils, so that's the way it does it.
It's at the back of my mind that I do need to get back to it and make it better, but it's something that will need to wait until the correct idea comes to me; it can't be done on-demand.
This is actually a good example of the kind of behind-the-scenes thought process that goes into a lot of DirectQ features. If something is changed from the way GLQuake does it, there is nearly always a reason, and it's not lightly done: alternative options are always considered.
5 comments:
"Two items I haven't touched yet are waterwarps and the graphical corruption on certain brushmodels. For the latter, I haven't seen it at all on any maps or mods I've tested on a variety of hardware, and the people who reported it haven't yet come back to me with more info."
I am pretty sure the corruption is a result of NOT having the Visual C++ RunTime Lib installed..
Polarite reported similar issues, and they went away after installing the prerequisites.
About the sub_divide thing: If you think the current solution is the best trade-off then by all means, stick with it! I really like the way it looks and i can live with the performance drop (for it's probably not even noticeable on a proper gfx card)
Something else I noticed though, is that when i shoot a rocket (and nothing else is going on) then FPS drops from 200 down to 110, only to rise back to 200 when everything related to the firing of that rocket is dealt with.. (not sure if the performance drop is related to lighting/interpolation/sound/particles/whatever)
About the Anti-Aliasing: on this GF5200FX, Anti-Aliasing does not seem to work with DQ1.7.3 either.. (not tested with any other hardware yet, will do)
One more multi-player specific issue: player colors (shirt/pants) do not always render correctly, that is, often the actual shirt/pants color differs from the colors displayed in scoreboard and even the actual setting.. (not a big deal in FFA mode but kinda problematic for teamplay)
About r_instancedlight: Yeah I guess making 0 (zero) the default for multi player is best, since this is what most players will expect (coming from glquake derived clients)
No can do with the particles. It's the very same code as I've been using since about 1.3, and - if anything - it got faster recently (moving to indexed rendering).
I'll look into the skins; that's important.
I might also add app-controlled AA; D3D has good support for multisampling built-in, and it's easy to implement.
I haven't been able to consistently replicate the weird "triangle flashes" when picking up ammo and health.
It's an on and off again type thing. I'm going to chalk it up to trying to play games on shoddy hardware (Onboard Intel garbage).
Gah!
About the skins: Here is screenshot of a gibbed head while the player has not respawned yet..
Hmmm - is that still happening with the new version? It looks as though the skin wasn't being changed when the model changes.
Post a Comment