...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
...appears to be done.
Posted by mhquake at 8:26 PM
Tuesday, February 17, 2009
I was going to release today, but then I remembered that I had promised to do resolution changing properly, so yah boo sucks.
Anyway, the most part of that is now done, I'm currently just working on updating all the different structs, global variables, etc that Quake uses to store the same data. Messy, but that's Quake. I have a note made to clean it all out some day.
Oh yeah, the crosshair has finally made it into the menus.
Posted by mhquake at 11:56 PM
Haven't done too much these past few days, but just got a few essential bits and pieces in places today. Some of the QIP bugfixes, removing the limit on file handles, and implementing the basic framework for DarkPlaces extensions. Don't get too excited on that last one - right now all it does is return "false" for everything, but I might implement a few DP extensions sometime (it's nice to have the option).
On the QIP bugfixes, I've done their max velocity fix but I'm feeling a bit wary of it: seems to me that it's a case where doing things "the right way" will change gameplay. I might revert it yet (or make it optional but off by default).
I think I'm finally going to fix up in-game resolution changing for 1.5; it's been outstanding these past few releases, so it's due being done. Thing is though, I'm of the opinion that resolution changing i not exactly a critical feature, most people running a game will set it once and then leave it set. Still though, the engine will feel more complete with it done.
Particles... I'm getting the itch real real bad here. I want to get 1.5 out before I dive in, but all the same, the temptation is fairly significant.
Posted by mhquake at 12:38 AM
Saturday, February 14, 2009
Wednesday, February 11, 2009
Tuesday, February 10, 2009
I've just done a fairly substantial rework of the particle system; no custom particles yet (still classic Q1) but the render has been totally gutted and updated to support selection of different particle textures, arbitrary size, arbitrary alpha fade, arbitrary growth, and possibly a few other things. The default at particle creation time is exactly the same as the classic Q1 dot particle.
I've also been able to optimise particle vertex submission a little bit, so it should run faster on many systems than 1.4 did, and will run faster on all systems if the number of particles needs to be increased at any time. This was always on the to-do list, and wasn't reliant on the extra flexibility above, so it's nice to finally get it done.
I still support unlimited particles, which is great for pointfiles. Incidentally, 1.4 had a bug where pointfile particles were clipped by solid leafs - that's gone too.
All in all a nice evening's work.
Posted by mhquake at 9:10 PM
Monday, February 9, 2009
Thursday, February 5, 2009
First thing I'm going to do is take a short break for a few days; work on this engine has been fairly intensive for the past two months and I feel that I need to step back a little. It's a good time to do so as 1.4 has reached a level of stability that I feel reasonably happy with (only one crash bug left in general use so far, and that's rare enough).
Right now I consider it about 95% "feature complete" so far as porting the renderer to Direct3D is concerned (which was the initial objective). There's still some minor things I need to fix and finish, but the only major new thing that will go into the render is a particle system. The default for that will remain as "classic particles", but I think some form of "enhanced particles" is pretty much essential in any modern port. Nothing OTT, just smoke and blood sprites, stuff like that. Existing functionality may be tweaked and/or tuned, of course (especially in cases where something might turn out to be broken).
The engine has evolved quite a bit beyond just a straight port; some of it being essential bugfixes, some being highly desirable features (not necessarily always render-related) that every engine should have, and some being just me going off and doing something that seemed cool.
I think that the next major inclusion will be game changing. This is a straightforward thing to add, shouldn't take much longer than a couple of days (besides, I've already written the code 3 times in the past). I also want to add more menus for interacting with content - maps and demos specifically, although a screenshot viewer sounds like it might be a nice idea.
I'm planning for a pick up of this early next week, but knowing me it could end up being a day or two on either side of that.
Posted by mhquake at 10:48 PM
Wednesday, February 4, 2009
Tomorrow's release will have all calls to malloc and free replaced with Windows API calls. This has been a worthwhile exercise, as I've been aware for some time that MSDN documents that the behaviour of malloc is different between debug and release configurations. One of my personal bugbears is exactly that - differences in behaviour between debug and release configurations. I've been bitten before by having a debug configuration work perfectly only to see the release build go down in flames (and with no way to debug it). Never again.
For what it's worth, I'm using the Heap* calls, as they seem to do what I want how I want with the minimum of goofiness to get in the way.
I like posts headed "getting there..." - gives me a warm glow inside.
Anyway, the good news here is that I think I've pretty much cracked the water translucency problem, with the help of some old code I'd originally written maybe 6 years ago. It's evil, it's ugly, but the theory seems sound and it's working in the test cases I've run it on so far.
I'm going to test a few more, just to be certain I'm not totally off the wall with this one, and then - all going well - we're in Release City on Thursday!
Tuesday, February 3, 2009
Random techie rant ahoy!
OK, you have an Operating System (I know, I said "Web Browser", but bear with me for a bit). It's crude and simple but does the job in a kinda semi-acceptable manner. Upgrades come over time, new versions are released, and gradually it gets better. Eventually it gets to the stage where pretty much everything is just fine, thank you very much. Still some idiosyncrasies but the version that's current has been around for long enough for everyone to get used to them. No, nothing really wrong with it that the odd restart every now and then can't fix.
And then a new version is released. Lots of shiny new bells and whistles, but damn it it's slooooooooooooooooow, unstable, things that used to work no longer do, and after playing around with it for a day/week/month you get rid of it and go back to your old Operating System.
But there's a shadow hanging over you, because you know that sooner or later your old version will no longer be supported. Then it will no longer be available. Then standards for all the applications that run on it will change and only the new version can be used.
So sooner or later you're going to have to jump, despite the fact that the new Operating System is still slooooooooooooooooow and unstable and all the rest. Everyone knows it, but the developers have their heads in the sand, they're doing absolutely nothing about it. There's even a crank minority out there that thinks it's somehow better this way.
Now, for a little experiment.
Replace the words "Operating System" above with "Web Browser".
Yes, Firefox 3, I'm talking about YOU.