Monday, September 7, 2009

Classification of Features

There are a number of different ways I classify features for DirectQ. First up is features that I know I need. These are commonly something that was present and correct in software Quake but was either missing or a hack job in GLQuake, but are also bug fixes, performance improvements or usability improvements. Something that gives cleaner code can also fall into this category (but not at the expense of correct behaviour) as clean code can generally be less buggy code. I'll finally include ripping out a lot of legacy code (like IPX support - does anyone actually use IPX these days? It's 2009 for crying out loud.)

Secondly are features that I want. These can be allowed to include changed behaviour at times, so long as it's not gameplay affecting. Quake II style noclipping, the modified TAB behaviour, cvar autocompletion, the restructured menus, and so forth fall into here. Sometimes a cool idea occurs to me that I know won't get much use but is sufficiently interesting to me to get me coding (the customizable HUD is one I'll put into here). Some of these features can occasionally disappear and reappear between versions - 64 bit lightmaps recently vanished but I think the old sRGB colour space might make a comeback (it would be a LOT cleaner now as well). Don't get too upset if your favourite one of these vanishes sometime.

Lastly are features requested by other people. I obviously can't possibly implement every single feature request I get (although it's nowhere near as rampant as it was back in the old MHQuake days), and as a secondary consideration (which is actually probably of higher importance) I have very clear design goals with the engine. There are a lot of engines out there that are aimed primarily at mappers and modders, and mappers and modders love them, which is great. I'm aiming DirectQ primarily at players, where an entirely different set of design goals apply. A player isn't going to be interested in robustly loading a partially completed map that has a f--ked (can I say "f--ked" on here?) BSP structure, for example. What a player wants is to robustly run a completed map or mod without having to fool around with most of the arcane crap that Quake normally shoves in their face (why do other engines not also do this?) Of course, if a feature request is compatible with my design goals I will give it serious consideration.

Some features can move from one list to another. Proper alpha entity sorting (which is STILL not working correctly - must fix for 1.7.2) was fairly low priority until maps that had a lot of alpha entities stacked in the Z order started appearing; who knows what will happen tomorrow?

The primary objective of having a version of Quake that can run reliably and run well on hardware that either chokes or is just plain slow with GLQuake remains, of course.

2 comments:

Nyarlathotep said...

Can you give an example of hardware that chokes on GLQuake but should work well on DirectQ? I'm sitting here trying to think of a card that fits that description which is also new enough to have driver support for NT 5.0+, and nothing's coming to mind...

mhquake said...

Intel 915 for starters - VERY common on laptops and a LOT of desktops up to 2 years back, and the main reason why I made this engine in the first place. With stock GLQuake the driver goes into an infinite loop and blue-screens the OS every single time. Fixing the code to prevent this will work OK, but you'll never get more than abut 50 to 60 FPS from it. DirectQ gets over 120 FPS and is rock solid.