...appears to be done.
I'm not overly happy with it though; but it works. In general, I think that there's something fundamentally wrong with Quake's video startup code (much of which I've inherited from GLQuake, despite any appearances to the contrary) and that someday I'm going to completely gut it and rewrite from scratch.
As usual, this has been tested and has demonstrated stability on Intel and NVIDIA graphics. I don't have an ATI to test, and I've better things to be doing with my money than spending it on ATI cards (throwing it in the air and shouting "wheee! money!" is one).
Overall I'm much happier with how Direct3D handles this than with how OpenGL does. Not having to go through an intermediate GDI layer definitely displays one advantage of using an API that is more closely coupled to the OS (being able to retrieve capabilities properly is another, although at least 75% of that was pig-headedness on the part of OpenGL's designers rather than something that wasn't possible).
If you're a Linux/Unix/BSD/etc person and you're interested in running DirectQ under WINE, you should be aware that DirectQ extensively uses HLSL for it's rendering - I think the sky is the only thing remaining that's still fixed func. There may be serious perf considerations here depending on how your WINE is configured. The best recommendation I can give is to try out some other HLSL based code (one of the DirectX SDK samples should suffice if you have it available), and if problems persist with that then it's most likely your WINE config at fault. If the other code is fast and stable but DirectQ is slow and/or problematic, I'm interested in hearing.
Wednesday, February 18, 2009
Resolution changing...
Posted by
mhquake
at
8:26 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment