With Release 1.8.2 looking to be quite stable and solid, it's time to start having fun. This is where I dive into some of the more technical internals of the code and work on stuff that isn't a dramatic bugfix or an immediately obvious improvement.
First up is a slight improvement on the timer. ID Quake has serious timer problems on some modern PCs, so DirectQ has used an alternative timing mechanism for the past while (I actually did it for a completely different reason, so that fix was a consequence). However, DirectQ will experience timing problems if your OS has been running for more than 49-odd days. I've reworked this so that now it's the case that you might have problems if DirectQ itself has been running for more than 49-odd days. I've also added code for to handle even that, but obviously I'm not going to test it (and even if I did, you would have to wait almost 2 months for the result).
(Update: no can do on that last point. I need to subtract one number from another and store the result in a 32 bit unsigned int, so there's only so high you can go. What are you doing running DirectQ continuously for 49+ days anyway?)
I've also been experimenting a little with DirectDraw. I've long wanted to do a native DirectDraw version of WinQuake, so I grabbed some online tutorials and wrote a small test application that just fills a window with random data. DirectDraw in a window is SLOW. I mean 6 fps slow. I did manage to optimize this so that it got to 13 fps, but still not usable.
Of course the way Quake needs to use DirectDraw is hardly optimal; a real DirectDraw app would work quite differently. So the experiment was a failure but interesting nonetheless.
More news as it happens.
Wednesday, March 31, 2010
With Release 1.8.2 looking to be quite stable and solid, it's time to start having fun. This is where I dive into some of the more technical internals of the code and work on stuff that isn't a dramatic bugfix or an immediately obvious improvement.
Posted by mhquake at 6:24 PM
Tuesday, March 30, 2010
Today I didn't get much solid work done, but have experimented a little more with my shader post-processing setup. The decision for now is to leave the standard refresh as is, but to use render to texture with post-processing as a replacement for both the underwater warp and the regular polyblend (bonus flash, damage tint, etc). This works out faster than the regular polyblend, but does involve a slightly more convoluted code path. Never mind though, it's done and what we now have is more solid performance.
I need to research more on render to texture and techniques for optimizing it, as I suspect that I could be pulling more performance out of it, so this (and the possibility of further effects such as motion blur) is on the list of possible things for 1.9.0; the 1.8.x series will retain the more basic setup.
In other news, I've just had a crazy idea for lightmap updating, which would involve creating the lightmaps as render target textures, then running the updates on the GPU. In theory it could be blisteringly fast as it wouldn't involve a copy of data from system meory to video memory. In practice I don't know as it's just the beginnings of an idea. At the very least I would need to get a test app together for bashing this into shape.
Posted by mhquake at 10:32 PM
Yesterday - after my difficulties with fog - I did some work on the underwater warp. There is now a post-processing shader that handles it per-pixel for r_hlsl 1 mode. Ordinarily this would be slower than the old way (which was per-vertex at a reasonably fine tesselation level) but I was able to integrate the underwater screen tint into the shader, thereby avoiding the second blend pass for that (I got it effectively for free) so it's actually faster.
This is where things get exciting. The underwater warp is done via render-to-texture, and I think I can set things up so that everything always goes through render-to-texture, but still retains the same speed as before. This means that I can also get the screen tint for damage and item pickups for free, and it also opens the possibility of doing other post-processing effects reasonably cheap. It seems as though motion blur would be possible with minimal FPS drop (it would involve no more than a texture lookup and 1 or 2 extra instructions), and HDR bloom would also be very fast.
This is quite theoretical and does go slightly against the trad ethos of DirectQ, but at the same time if I can get effects like this with minimal performance impact I see no reason to not include them as disabled-by-default options.
Posted by mhquake at 11:21 AM
Monday, March 29, 2010
One of the things that was broken for me (although apparently not for some others) in DirectQ 1.8.2 was fog. I didn't get round to even investigating it prior to release but I have done so now.
I had suspected that the cause was somehow hardware related, and it's bad news.
It seems as though Shader Model 3 or above removes the built-in fixed functionality fog. So hardware that supports SM3 or higher (and this is everything from the GeForce 6 series - or equivalent - and upwards) is no longer required to support fog render states in hardware. Doesn't matter if you compile your shaders to SM2, or even if you don't use shaders at all, it's the model supported by the hardware that is the deciding factor here. A lot of this probably depends on the vendor; one of mine supports per-vertex fog (which will break on the water and sky shaders) but not per-pixel, and it seems that even that can't be relied on going forward.
Now, this is not a problem for OpenGL: fog is in the spec and therefore fog shall be supported, even if it means a software fallback or a wacky blend to get it. But D3D doesn't work that way. D3D exposes the raw bones of the hardware and nothing more; despite being COM and OOP it actually is a much lower level API than OpenGL.
None of this is definitive and I'm still doing the research, but there is plenty of info to support it and the only thing lacking is official confirmation.
Next comes the bit where I consider my options. Assuming that the non-support of fog turns out to be true, here's what they look like.
The first and easiest is to just drop fog entirely, at least for now. There is potential to come back to it when the renderer goes through a few more evolutions and possibly implements everything in vertex shaders (which D3D - oddly enough - does support in software if required - they would even run on a Voodoo 2).
The next option is to implement one of those hacky workarounds I mentioned, possibly blending everything with a cubemap for a fake fog effect (I believe DarkPlaces does something like this). Gouraud shaded polygons could also get it, but the pain and suffering involved in that approach means it's not something I'd undertake lightly.
The final option is to hack together something that works with fixed per-vertex fog for everything aside from water and sky, which would have fog calculated in their shaders instead, and no guarantee that it would be invariant with fixed or even continue to work in the future. Not an option in other words.
On balance I'm inclining towards option 1. Transitioning everything to vertex shaders is definitely on the cards for 1.9, so the requirements to support it will be there. (Did I mention that D3D vertex shaders would even work on a Voodoo 2? I probably should just in case I give the idea that I'm locking people out here.) The other options just involve creating a mess that would then have to be extracted.
Better to not have a feature (at least in the short term) than to have one that kinda works half the time but can't even be relied on.
Posted by mhquake at 10:02 PM
Sunday, March 28, 2010
OK, so I mentioned that I was intending to work some on DirectQ's interpolation code. The original plan was to gut the current code and then start bringing on the QII interpolation code, but that didn't quite work out. Turns out that the old QER code is so deeply embedded into the engine that there would be some major surgery involved, so Plan B swung into action.
This involved dredging up the old QER tutorial from The Wayback Machine, reading it again with a fresh pair of eyes, going "meh" cos the code is really and truly quite horrific, then going into full-on experimental mode with what I've already got.
Step 1 was to make sense of the variable names. The QER guys used "pose1" and "pose2", for example, which doesn't really help with determining which pose number is the current one and which was the previous one. All well and good when you're writing the code in the heat of the moment, but not good at all when you come back to years later and try to bugfix it or add functionality. They also did the same with origin and angles, so good old-fashioned "try it one way and if it doesn't work try it the other" came to the rescue and provided me with sensible variable names.
From there I've cleaned it up a lot and generally made it more easy on the eyes.
All this is well and good, but it's nice to include a bonus feature for anyone using the engine, so I switched the interpolation from linear to cubic. This came with minimal CPU overhead and will give a smooth curve between points instead of a straight line. It's quite subtle, but once you do notice the difference (smoother and more even animations) it's hard to go back.
Of course it's not as perfect as spline interpolation, but that involves quite a bit of extra overhead on top of cubic, and I don't think right now that the difference would be as worthwhile as the step from linear to cubic was.
From here the next steps are to find places where I've front-loaded code into the renderer and move them back to the client where possible. I had already done this as long ago as MHQuake with orientation and position interpolation (which very cleanly fixed some issues that QER had messy code in the renderer for), but now I think there's scope for some of the animation code to also move.
The end result will be cleaner, more maintainable and give you a better visual result too. All nice.
Posted by mhquake at 8:14 PM
The Draw_Character function has turned out to be a major performance bottleneck. I discovered this during my VMware tests of DirectQ on Windows 2000 and XP, when bringing down the console (or bringing up a menu) would drag framerates down into single digits.
Now, the VMware display driver is obviously not intended for serious game performance (although while it sucks at D3D it is quite good at OpenGL), but one thing that a low performer is great for doing is identifying trouble spots like this. If you test on high performance hardware everything is going to run fast anyway so you'll never know!
Of course it was necessary to confirm that this actually was Draw_Character at fault, and not some weird aberrant extra calls to SCR_UpdateScreen during the console drawing, so the simple thing was to just comment out the function body and see what happened.
The optimization then consisted of batching up characters (for bonus points I did all the other 2D stuff too) so that multiple polygons could be drawn in a single pass. The definitive confirmation was when I tested this on the same setup and got no speed drops.
The real culprit seems to have been my use of Triangle Fan primitive types. Even switching these to Triangle Lists, at the cost of 2 extra vertexes per Quad, was a major performance boost, and the few places remaining where I still have Fans still give the same speed drop as before. The next step is to take one of those, switch it to a List, and see what happens.
All in all it's been interesting stuff, with a good end result to show for it.
Posted by mhquake at 3:46 PM
In the continuing quest to get DirectQ running on anything I've now removed all static linking dependencies from the DirectX components. Naturally enough DirectX 9.0c is still a baseline requirement, but otherwise it should now be quite version-neutral.
A nice side-effect of this is that I can now use more advanced features of some components if they are available, but I don't require them to be available.
The non-DirectInput mouse code seems to have gone messy at some point in time; not certain if it was in a released version or if it's new. Overall though it's not such a big deal as the days when DirectInput might possibly have not been available on a machine are well behind us. Given that DirectQ requires DirectX 9 to be installed for the renderer anyway, I don't think I need to worry much about that.
I'm pretty pleased with today's result, even though I had originally planned to work on interpolation. That's for another time.
Posted by mhquake at 2:56 AM
Saturday, March 27, 2010
I've decided to resolve the old "This application has failed to start because d3dx9_38.dll was not found" problem by dynamically loading the DLL and entrypoints instead. The way I do it is by counting down from a sufficiently high number (DirectQ is known to work with versions up to the latest, which is 42), attempting to load the DLL for that number, and if succeeding attempting to load all of the entry points for the functions I use. If all of those succeed I accept that DLL as the version I'm going to use.
This is a far more acceptable solution to me than enforcing a specific version of D3D9 on you, and will even work with your crusty old Windows 2000 RTM machine that you put the first version of DirectX 9 on and have never upgraded since. At some point in the future it might even be possible to make the D3DX version used user-selectable, so that you can - for example - experiment with differences between using the D3D9 and D3D10 shader compilers and pick the one that works best for you.
If all of this sounds suspiciously like the old wglGetProcAddress malarkey that you had to do when setting up OpenGL, well that's because it is. Frankly I smell a rat, and think that this is something that MS should have put into a single master DLL so that pain from it wouldn't be inflicted on the rest of us. Oh well.
On the other hand the advantages of being able to experiment with different versions due to using dynamic loading are a Good Thing to have, so it's an ill wind etc...
Update: I can now dynamically load different versions of the D3DX DLL at runtime (including while a map is playing). This is pretty neat and will enable you to select between the D3D9 and D3D10 shader compilers if you want (I don't know if the D3D11 compiler is available to D3D9, although from a check of my XP box it looks like it is).
It's controlled by a d3dx_version cvar which defaults to 42, the highest version I have tested with. The lowest legal value is 24, basically because there are no prior versions of the DLLs available. Setting it to -1 will use the best available version.
From the looks of things, 33 appears to be the D3D10 compiler and 42 appears to be the D3D11 compiler. Note that my HLSL shaders don't compile on any version prior to 32, so it'll revert back to fixed mode.
This of course isn't robustly tested, so you shouldn't be wildly switching between different versions at run time (and then complaining to me that it crashes).
Posted by mhquake at 6:38 PM
Friday, March 26, 2010
Or at least I'm pretty certain that it will be 1.8.3, although at this stage I don't really know yet. Depending on whether or not it becomes necessary, I might yet cancel 1.8.3 and go straight to 1.9, but time will tell.
Firstly, regarding the DirectX SDK version, it's looking likely that I'll be using the March 2008 release. This gives the same reduced executable size as February 2010, uses the same Direct3D 10 shader compiler (which incidentally is a D3D10 component that works on Windows 2000 and XP) but only has a d3dx9_XX.dll requirement of 37 (February 2010 needs 42).
I've consolidated a lot of the versioning of components into one place and made the whole thing considerably more robust. This wasn't a problem with previous releases, but might become a problem in the future so it makes sense to do it.
Web download has been slightly modified to deal with certain edge cases. These are quite rare and involve things such as your network connection temporarily going down and then coming back up again part way through a download, so they're not crucial, but the code just seems a lot more solid as a result.
Some performance optimizations for complex scenes have been done. Release 1.8.1 and 1.8.2 used an idea (stolen from FitzQuake, muchas gracias) to run R_CullBox on surfaces so that vertex submission to the 3D card can be reduced, but - like FitzQuake - they ran it on every surface. Now what I'm doing is detecting if a surface is in a node or a leaf that actually intersects the frustum and only running it on those surfaces. This cuts the number of R_CullBox checks down quite dramatically, especially in bigger scenes.
I'm also bringing in some code from Quake II in appropriate places. I haven't really done a direct head-to-head comparison, but I'm working on the assumption that the Quake II code - because it's really just an evolution of Quake 1 - contains fixes and improvements that are for the most part warranted (although in some places - such as it's handling of dynamic lightmaps - that's clearly not the case). This is really just going to affect certain aspects of setup for the renderer, optimization of math routines, some inline asm, and so on; I have no intention of making any physics or other gameplay-affecting changes.
The next major change will be interpolation. DirectQ's current interpolation code is fundamentally f--ked. It was derived from the original QER tutorial and patched over the intervening years in various incarnations of MHQuake to deal with edge cases where it broke down (which were unfortunately all too frequent). It works after a fashion but is very nasty and fragile. This will be a 2 step process, with step 1 being to completely gut the current code, then step 2 will be to bring on something nicer and cleaner (and therefore more maintainable).
That's all for now but there will be more. Stay tuned.
Posted by mhquake at 11:45 AM
Thursday, March 25, 2010
The release build of DirectQ 1.8.2 clocked in at almost a whopping 2 MB. I had certain suspicions as to the cause of this, and at least one of those has now been confirmed - my use of an older version of the DirectX SDK. By compiling against a more recent version the size reduces to a trim 871 KB. Presumably the older version is statically linking a lot of stuff that has since been moved out to a DLL.
The downside is that doing this will mean the return of the dreaded "d3dx_37.dll cannot be found" errors.
A compromise solution would involve using the more recent SDK (for performance improvements, bug fixes and added functionality) but dynamically linking against the D3DX stuff. I can choose an older D3DX DLL to link against (one which is on a fresh install of Windows Vista and 7) which would ensure that the required functionality would be present.
Another way of doing this - which almost made it into 1.8.2 - is to find the latest version of the DLL on your machine and use that, only downgrading to an older version if it's not present.
On balance either of these seems a better approach, but might lead to a debugging and maintenance nightmare if different people are using different versions.
The approach I prefer is "just update your DirectX". It gets everyone onto the same playing field, and I think that at this stage most people should be aware of what's needed. I've certainly documented it myself often enough. I can include a Direct3D readme with future distributions to cover everyone else.
All of this assumes of course that a DirectQ compiled with the more recent SDK will run on 2000 or XP. It should be OK (the SDK I'm using - Feb 2010 - has a runtime that's available for Windows 2000 after all), but still needs to be tested before committing to this approach. (Update: it runs Just Fine.)
For what it's worth, the more recent versions of the runtime (since about 2005 or 2006) are no longer even available for Windows 98, so if I take this approach it will completely rule out any possibility of a Windows 98 build ever happening. To be honest that doesn't bother me much as DirectQ has never run on 98, and there hasn't been any major outcry for it.
Posted by mhquake at 11:00 PM
The incident which almost delayed the release of 1.8.2 was caused by the Nehahra mod, and specifically it's use of different names for some of the menu graphics. Nehahra basically has 3 main menu graphics, any of which may be used in different circumstances, depending on whether you're running the game only, the game plus demo movie, or the demo movie only.
Now, the one of these that interests DirectQ is the game only mode, as DirectQ does not support the demo movie (I'm not even certain if that's available for download by us mere mortals who don't have FilePlanet subscriptions).
However, in this mode the main menu graphic is called "gamemenu.lmp" whereas it's otherwise always called "mainmenu.lmp"; the Nehahra mod only loads "mainmenu.lmp" when you're playing the game plus demo movie mode.
The code I had written to detect this worked fine in the Debug build of DirectQ but didn't in the Release build (in fact it completely broke the menus even if Nehahra wasn't running). So Microsoft are partially at fault here too for having a compiler that generates inconsistent behaviour; you must assume that the results of a Debug build are not necessarily valid for a Release build. This seems crazy to me but i'm only a lowly hobbyist here so what could I possibly know?
So in the absence of being able to break into the debugger during a Release run to see what the f--k was going on, I was left with two choices. I could either have delayed the release indefinitely while going through laborious testing or I could have constructed a cheap and nasty fix. I chose the latter, and the end result turned out to be better overall anyway.
There are two parties at fault here (a third if you include me for not testing Release builds earlier, although I'd argue that I shouldn't have to). Microsoft for starters for deciding on this bizarre different behaviour, and the Nehahra team for constructing a series of unpredicatable hacks.
Overall I have quite a distaste for the Nehahra mod so maybe my opinion is coloured a little by that. In many ways it's similar to Hipnotic (which I also dislike), being a collection of hacks rather than a robust and cohesive overall product. Too much of it is in slavery to the Great Gods of QC for my taste as well.
So that's what happened and that's how I came to release yesterday after all.
Posted by mhquake at 5:24 PM
Wednesday, March 24, 2010
Direct link: http://directq.codeplex.com/releases/view/42494.
And you can also get it from the menu on the right, as always.
A last minute hiccup with the menu system in the Release build almost delayed this one for quite some time. I'll write more about that later on.
There will probably be a release 1.8.3 to fix any late breaking bugs in this one as well as to straighten out some of the things I didn't get to finish properly. It's still too early to say whether or not there will be any further releases beyond that in the 1.8.x family.
What 1.9.0 is going to look like is starting to come together well in my head now, but there's no way I'm going to commit to even saying anything at this point in time.
Posted by mhquake at 10:29 PM
We're dangerously close to it now. The only remaining item on my list is the broken fog, and I think I'm going to leave that be for now as it seems more hardware dependent than anything else.
A few points regarding some of the other items:
- Web download has now been transitioned to Windows API code and should run a lot cleaner, with no "Internet Explorer components" (that aren't really) in use.
- PQ messaging is there but right now the client only responds to ping times. It's not beyond the bounds of possibility that I might delay to extend this a bit more, but it depends on how messy the original code is.
- DP_TE_PARTICLERAIN and DP_TE_PARTICLESNOW have been implemented as a test bed/proof of concept of DP extensions.
- FRIK_FILE has not been implemented; there are huge dependencies on other parts of the code that I've changed beyond recognition (Zone memory, PR temp strings and file handles) so it needs quite intensive rewriting and testing before I can say "yeah, this works". I'll probably need to cook up a mod of my own just as a test bed.
- Previous dependencies preventing it from running on Windows 2000 have been straightened out.
- An old bug preventing you from being able to kill Shub has been fixed.
- Several bugs relating to invalid model and skin indexes in mods like Prydon have been fixed.
- A "levelstats" command to dump info on the current level to the console has been implemented. I had intended to include a dump to file option but didn't in the end. Set condebug 1 to do this yourself.
- Speaking of which, condebug 1 mode has been greatly enhanced as a means of providing multiplayer game info; it no longer temporarily locks your game while writing large amounts of text to the console. condebug 2 will revert to the old behaviour.
One final point regarding the public domain thing I wrote about a while back. Having thought about it a bit more, I'm now inclining towards not doing it. It's not that I think the GPL is any kind of ultimate paragon of licensing excellence (I don't) but more a case that there are logistical implications I need to think through further.
The next post should either be an announcement of release or a notification that I'm delaying for whatever reason, so sit tight!
Posted by mhquake at 8:52 PM
I'm in the process of switching my web download system over to pure native code. I suppose my use of the phrase "Internet Explorer Components" opens the risk of giving a bad impression; one that I'm using ActiveX and will be leaving your PC exposed to virus attacks. This isn't the case and in reality it's just a DLL that wraps the underlying network transport, which is really no different to the underlying network transport used for anything else.
At the same time the damage is done so far as IE is concerned, and I do want to avoid anyone getting the wrong idea about what the code is and what it does. So pure native it is, and this has some additional advantages in that chunks of the code can be greatly simplified. The main thing is that it no longer requires a COM object to handle the progress notification callback, which was sort of a case of the "OOP Zombies" thing I've mentioned before.
Anyway, the basic code is complete and functional, and has been tested through a proxy server. I'm going to test and confirm it through dial-up later on, and then migrate it across to the main codebase.
Posted by mhquake at 5:21 PM
I think DirectQ can now run on Windows 98. Of course I haven't been able to test it properly because I no longer have any hardware that even has Windows 98 drivers available for it, and therefore I need to run it in a non-hardware-accelerated VM (even VMware's display driver - which gets me 130 FPS in GLQuake on Windows XP - won't work with Windows 98).
So my testing has gone as far as double-clicking on DirectQ.exe, noting that it gave me a missing GDI+ DLL error rather than the dreaded "your OS belongs in the Palaeozoic, begone sirrah!" error, and therefore assuming that at least the exe I can produce will run on it.
Further testing tomorrow with GDI+ installed and the reference device will provide more info.
Assuming that all goes well and that the end product does at least run (even if it's at 1 FPS on the reference device) the story will be:
- I won't be generally distributing a Windows 98 build. This is to prevent overly-conservative types from downloading it in preference to the normal build.
- You're going to have to ask me for it.
- The procedure to ask me for it will be a PM on either QuakeOne.com or Inside3D.
- There may be a delay before you get it. Sometimes it will be minutes, sometimes it will be weeks, and it will depend on what else I have going on in my life at the time (I'll be wandering around the Sahara again later on this year, for example).
- I'll upload to one of the main file-sharing sites for you and notify you via reply PM. I normally use SendSpace for these things, but if you have a preference you'll need to tell me.
- You'll just get the exe, no source code. The source code will be the very same as for the normal build. I don't intend changing anything for what is now a fifth-tier platform.
- I make no guarantees that it will work for you. If it crashes or otherwise fails you're going to be pretty much on your own, unless you download the regular code and build it/debug it yourself. I believe this is reasonable owing to my complete inability to debug on Windows 98 (no hardware acceleration = less than 1 FPS performance).
- I make no guarantees of performance on Windows 98, and I make no guarantees of any kind of optimization for Windows 98 (I have no hardware acceleration after all, so it's impossible for me to tune it). If you want that you'll need to download the source code and do it yourself.
- I'll be putting code in the Windows 98 build to crash on anything later than 98, so don't go asking me for it unless you actually do have Windows 98. This is to prevent those conservative types I mentioned before.
- Not every regular build will have a corresponding Windows 98 build, and Windows 98 builds are subject to being stopped at any point in time, with or without notice.
- I won't be going out of my way to advertise the fact that it exists. This one post - and any other update I may or may not care to give - will be the only notification.
Posted by mhquake at 1:07 AM
Tuesday, March 23, 2010
OK, after some further work I've now finalized the web download process. So far as you're concerned it works in the same way as ProQuake and Qrack downloading, but behind the scenes a few things have changed.
I'm not using libcurl anymore; it's native Windows code all the way. I suppose the argument for libcurl is that it's portable, but since I'm Direct3D I've already sold that particular farm.
This means that - as before - all you need is DirectQ.exe for this to work, no additional DLLs, no DLL version hell, just nice and clean and easy.
The native code depends on some Internet Explorer components. If you're one of those people who likes to remove Internet Explorer from your PC using unofficial hacks this WILL PROBABLY NOT work for you. I don't actually know to be honest; it's possible that the components required will remain behind as they live in Windows rather than in Program Files.
In any event, I dynamically load everything and have some robust failure cases written so the engine at least won't crash. You'll just need to download the missing models yourself.
Another difference is that it no longer creates the temp file in your Quake folder. Instead it uses the TEMP folder from your user profile, so if anything bad does happen partway through the download you can take some consolation that your Quake folder won't be polluted by orphaned left-behind bits.
I've added a download progress indicator to it, and removed the output from keepalive messages while downloading (the keepalive messages still happen, they just don't write to screen). The progress indicator just puts a percentage completed to the console at roughly 10% intervals. This should help reassure you that the download is actually happening, and enable you to cancel it if you want (by disconnecting) if it's taking too long.
Some of the more verbose messages have been tightened up. The original code printed the name of the file you were downloading I think 3 times (!!!) during the process. I reckon you only need to see it once - when the download starts - and then either a plain and simple success or failure message.
I've also fixed some genuinely weird looking bugs in it; free-ing a static buffer, for example. I've added some more meaningful error messages and cleaned up the original (quite messy) code too.
Another nice result.
Posted by mhquake at 7:15 PM
Monday, March 22, 2010
...or rather not...
My new texture loading system messed up mapshots quite a bit, in that it didn't exactly play nice with different game directories. End result was that if you had a game save in warpspasm (for example) you stood a good risk of seeing the image from a save with the same name in ID1. Likewise with map images in the "Maps" menu.
This took some messing around to fix, and I fear that I may have broken mapshots being stored in PAK files as a result.
On the plus side I did manage to construct a list of all games currently loaded as part of the fix, so I'll be seeing where else I can use that. I do desperately want to rework the Change Game menu some time, so I can see a use for it there.
I've also ended up removing the ability for user-configuration of the save and screenshots directory. Bottom line is that I had to remove save owing to the need to definitively identify a mapshot, and it was logical to remove screenshots after that.
The directories used are now called "save" and "screenshot" and that's it. I don't suppose this is going to bother too many people, as I doubt it was ever used.
On to the release date. I had originally intended that to be later on this week, and I might even still hit that. But I might also overrun a little.
Time will tell.
Posted by mhquake at 11:07 PM
I'm still working out the final details, but it's going to be heavily based on the Qrack/ProQuake system. One critical difference (that's already resolved) is that DirectQ will NOT need the DLLs (libcurl.dll and zlib1.dll) in your Quake folder for general gameplay. So if you have no interest in this feature you don't need to have them, and you will be able to just run DirectQ normally as before. They are however required for downloading to work.
I'm not too certain how to go about distributing the DLLs yet; I might just include a download link in the readme. I guess that most people who would be interested in this feature already have them anyway...
Just to be nice I added a download progress indicator. I was going to do a graphical one, but I realised that all the action happens in the console anyway so it's just some console spew. At least if the downloads taking too long you get some feedback on what's happening.
Posted by mhquake at 6:46 PM
Sunday, March 21, 2010
I've just found another crash bug, but this one was a little weird. It seems that some mods like to send invalid skin numbers for alias models; for example, a model might have only one skin, meaning that the only valid skin number is 0, but the mod might send a skin number of 1.
This is one of those things that worked - despite being wrong - in the past. With DirectQ it crashed hard owing to the skins being dynamically allocated.
Since it's not such a big deal in terms of memory I've reverted to the old static array of 32 skins, and have also gone through it at load time and pointed any skin that wasn't set back to skin 0.
So yes, I'm now bug-compatible with some mods!
Posted by mhquake at 10:04 PM
I've said this before loads of times but it seems like it's one of those things I'm destined to repeat...
There are certain behaviours of DirectQ that I won't change; even if other engines change them, even if someone asks politely (or impolitely!) for the change. Nope, won't do it.
The main reason why is that for every one person who wants the change there is guaranteed to be another who doesn't want it. This is a fairly clear-cut case of not being able to please everybody, and in such cases I generally do what seems good to me.
Sometimes that involves giving a choice between the two behaviours, but sometimes it doesn't. The problem with giving a choice is "what do you make the default?" You can guarantee that whatever you pick, there will be people who prefer it to be the other way. You can also guarantee that there will be people who are completely unaware that such a choice exists, even if I put it in a menu with text saying "HELLO! Choice for XYZ here!"
Yes, all of these things have happened in the past.
An example. I had a request to make the gun model smaller with values of FOV above 90. Now, the way DirectQ handles the gun model with these is to draw it as if FOV was 90, and this has met with approval from people. So straight away we're in a situation where we have two contradictory behaviours and it's impossible to satisfy both.
Further investigation of the matter reveals that the way DirectQ handles FOV is actually correct. Fire up start.bsp, set fov 110, go to the torches above the pool in the e4 hall, jump on a ledge and have a look. The gun model is correctly scaled.
So now we're in a Dilbert-esque "put the bugs back in" scenario.
What all this means is that sometimes the answer to a request is going to be "no", even if you think it's a reasonable request, and even if you think it's a good thing to have. Not everybody might think the same way, and sometimes the requested behaviour is just going to be the wrong behaviour.
Posted by mhquake at 8:51 PM
It's looking possible that I may be able to release a version of DirectQ 1.8.2 that will run on Windows 98.
Now, to call Windows 98 an operating system is much the same as calling the Wright brothers plane an F16. Sure enough Windows 98 will run applications and browse the web, just as the Wright brothers will get you into the air. Some of the bits are even similar, but the comparison ends there. Windows 98 in other words is not really suitable for general modern OS use.
So this is by way of saying that even if such a version does materialise, it might not run on your Windows 98 box. Firstly there are going to be a whole heap of prerequisites; including the Visual C++ 2003 runtimes, GDI+, a 2005 version of Direct3D and so forth. Without those DirectQ just cannot run. I know it sucks mightily, but these components are actually quite important for DirectQ.
Even if you cut the mustard on software, you will still need the hardware. DirectQ is somewhat more GPU and CPU intensive than GLQuake (although it does use less memory). At a bare minimum a Direct3D 7 class device is an absolute requirement, and I honestly have no idea if even that will be enough - it's a theoretical minimum imposed by the code. This means something like a GeForce 3 will get you entry-level performance, and you'll need to go to a GeForce FX or GeForce 6 class device for the full D3D9 effect.
So if your hypothetical Windows 98 box can meet those requirements then I guess you might be able to run it inbetween the BSODs, rampant page file access, Active Desktop updates, reboots every time you so much as look at it sideways, and constant virus attacks.
Posted by mhquake at 6:25 PM
The reason for this is because of the XInput API, which is used for providing support for the XBox 360 controller and which is not available for Windows 2000. The 360 controller will work via the standard Quake joystick code, but it's functionality is quite poor.
Would anybody cry if I removed the 360 code? Because otherwise it works quite beautifully on Windows 2000. In other words, which is more important: controller support or Windows 2000 support?
Update: I went with plan C, which was to dynamically load the required XInput DLL and entrypoints (there's only 2 of them) at startup, which gives both 360 support and Windows 2000 support.
Now to see if I can get this baby to run on Windows 98...
Update 2: When I say "run on Windows 98" of course I mean it as an intellectual exercise moreso than anything else. It would be nice to have it of course, but it's not something I would otherwise break the engine for...
Posted by mhquake at 1:04 AM
Saturday, March 20, 2010
Not too much done today, but some important fixes made it in.
Firstly the non-standard alias model skin name fix has been extended to include sprites too. This was important as sprites also included the extension in the default external texture name (to distinguish between s_light.mdl and s_light.spr, as mentioned before).
Secondly I've fixed the "always run doesn't increase back speed" bug. For a while there I had convinced myself that this wasn't actually a bug, but was the way ID Quake behaved. Going back to ID Quake source told me it was otherwise. I believe this bug has been present in DirectQ for over a year now.
While doing that I made some subtle changes to the behaviour that I think you'll like. With ID Quake you had choices between a speed of 200 or 400, and if you set your cl_forwardspeed or cl_backspeed variables to anything lower or higher, using the menu would stomp over them.
Now in DirectQ setting always run on will only stomp over the variable if it's less than 400, and likewise setting it off will only stomp if greater than 200. That means that there's still a range between 200 and 400 that's going to be effectively off-limits from the menu, but it's an improvement all the same.
Thirdly I fixed a bug in end.bsp where the spiked ball movement was quite weird. This came in as a result of physics code to handle brush rotation, and I guess that the new code wasn't happy with that particular entity. Ooops. For now, end.bsp is quite unfinishable in DirectQ 1.8.1, so the fix is to run that map in 1.8.0 - at least until I get 1.8.2 out.
There's been lots of little fixes and tightening up like that being done for 1.8.2, and while none of them are anything radical on their own, taken together they are going to give an end-result that's just a much much more polished and overall nicer engine.
Looking at my to-do list now, there's not really much left. The big one that I've been putting off is fog; it's sometimes broken, sometimes it works fine, and I honestly don't know what's going on. I might just defer it to the next next release.
More (hopefully) tomorrow.
Posted by mhquake at 7:51 PM
Friday, March 19, 2010
In between foaming at the mouth over horrid old software, here are the DirectQ 1.8.2 updates for today.
First one is 2 TMU support. Whoo-hoo! It only took me a year to get there! I've relaxed the hardware capabilities checks at startup a little bit as a result of this; the minimum requirement is now a DirectX 7 class device.
You should note that there is one 3 TMU scenario left in the engine where I didn't bother coding it properly. This one is where a brushmodel has both alpha and fullbright texels, and I just don't bother with the fullbrights. This code is up for rewriting sometime soon (but probably not too soon), so you'll just have to live with it for now I'm afraid. Hopefully these are rare enough.
I'm not even going to bother with 1 TMU devices, as these are pretty much uniformly first-generation cards (Voodoo 1, Banshee, RIVA 128, etc) and so don't stand a hope in hell of running DirectQ anyway.
Second one is more robust support for external textures on alias models. I recently discovered that my previous support just didn't even work, so I went back and reworked it. I also added support for the second common naming convention, so now you can use either modelname.mdl_0 or modelname_0.
The important thing to be aware of here is that the modelname.mdl_0 convention is actually the correct one, but unfortunately previously released skin packs used the other. The reason why it's correct is because ID1 has both an s_light.mdl and s_light.spr in it, so modelname_0 is not even compatible with ID1! (Can you guess why not?)
Here's another case where a bad standard became something of a de-facto standard early on, and now something that won't even work with the original game needs to be supported.
Third one is the screenshot/external texture conflict noted a few days ago. In the end I just decided to skip over checking anything in the current screenshots directory. I don't suppose too many people will be changing this anyway, so no big deal if it doesn't work all the time.
In other news, I found out why MASM never worked with Visual Studio 2003 (you need to remove the quotes from the macro paths in the custom build steps) so that made me happy.
Till next time.
Posted by mhquake at 11:33 PM
I've lately had occasion to do some work using Visual Studio 6 on Windows 98. This was for an old application that needed to run on '98, so I decided to go as primitive as possible, and pulled out the MSDN DVDs from 2004 or thereabouts and went to work.
Windows 98 itself was a barrel of laughs. It came up alright as a Virtual PC, and - remembering how swap-happy that OS was - I was able to create a RAM disk in config.sys and put the pagefile on it. Limit of 32MB for a DOS RAM disk because we're in 16-bit land, but for Windows 98 that's fine. This was the kind of setup I always wanted back then, and it was nice to finally have it, but the good times stopped there.
Needless to say that the OS misbehaved constantly, with loads of BSODs and "This Application has performed an illegal operation and will be shut down" on Explorer.exe if you so much as looked at it sideways. No, it wasn't the RAM disk pagefile; putting it back to HD fixed nothing. The OS was just criminally unstable.
Next up was Visual Studio 6, and the first bad memory that came back to me was the lack of screen real-estate. Not being able to tuck away all the little workspace and build windows and have them pop back out on a mouse-over was really annoying. The project settings dialogs were shockingly bad, the debugger was appalling primitive, no tabbed environment, unfamiliar keyboard shortcuts, just nasty. None of these actually prevented me from working on code, but the overall cruddiness just gave an aura of bad vibes, and the awkwardness in usability severely impacted my productivity.
So I finally heaved a sigh and went with Visual Studio 2003 on Windows 2000. It can still do what I need, and the sheer quantum leap ahead in just about everything was a total relief.
Now, it annoys me when Linux Weenies make pronouncements about how bad Windows is in general, when - if you have half a brain - it's obvious that they're really only referring to old versions that don't even exist anymore. No, Windows is no longer based on DOS, and no, it no longer does co-operative multitasking, for example. But going back to how horrible that recent experience was, I did very much get the feeling that just about anything would have been an improvement.
Posted by mhquake at 7:28 PM
Thursday, March 18, 2010
Alt-Tab friendliness is complete, we now have gamma switching, music pause/resume and sound stopping correctly.
The "quit" option in the main menu was broken, and instead of popping up a dialog giving you a y/n choice it just flashed up the dialog and exited anyway. This is now fixed. Typing "quit" at the console will quit without the dialog; this is intentional as I assume that if you went to the bother of typing "quit" you've already made up your mind that you want to quit and don't need an "are you sure?" Menu options can be selected by accident however so the dialog is staying there.
With the demos on startup thing, the decision is this. You get the normal demo loop on startup as per ID Quake. No menu or console, you'll need to do this yourself. On a game change you get the menu popped up.
Still haven't made up my mind re: the directq.cfg vs config.cfg thing. I'm going to think on it a little longer. It's looking strongly like it's going to be directq.cfg though. Config.cfg will still be loaded of course, it just won't be saved.
Cvar aliasing is proving to be cool. Some examples: some engines use cl_fullpitch for the full range of up/down looking, ProQuake uses pq_fullpitch. I can now use both. DirectQ used m_look for mouselooking, freelook is the standard elsewhere. I can now use both. This is great as I can now change cvar names any time I want, but keep the old name as an alias, so your old DirectQ configs remain valid, so that cvar names can start transitioning to what you expect them to be from other engines, and so that you can use whichever of the two names you like yourself.
Meanwhile here's another interesting bug for you. I wrote a while back about how I can now load external textures from anywhere in your gamedir(s), not just from /textures. It looks like I have a screenshot name that's the same as a texture name...
Given that the screenshot directory and the screenshot base name are both configurable in DirectQ, I'm wondering how I'm going to work around this one!
Posted by mhquake at 7:24 PM
Wednesday, March 17, 2010
Alt-Tabbing out from DirectQ now restores your OS gamma properly. I still haven't addressed the sound yet, but that's definitely going to happen too. DirectQ hasn't been as friendly towards frequent Alt-Tabbers as it could have been in the past, so it's nice to get that done.
A bug has been spotted in Nehahra and other mods that use custom menu pics with additional options in them. This is quite an evil and hacky thing for a mod to do, as it effectively ties the mod into a specific engine. I don't know if a general purpose solution is going to be easily available yet. In Neharha's defence it does date from an earlier time, but it's still legacy mess that needs to be coped with.
I've restored the old full-disk scan method if DirectQ is run from a folder that doesn't contain your game files. This time it asks your permission before doing a full scan.
It's important that people understand that this is only a third-line fallback, not default behaviour every time. Some people got their jollies from assuming the worst last time I talked about this - let's see if it happens again.
Posted by mhquake at 7:15 PM
Tuesday, March 16, 2010
I got round to doing it after all.
What this means for me is that I can now refer to a cvar by more than 1 name.
What this means for you is that I can take a cvar where I've given it a non-standard name (r_lerporient, for example), keep the non-standard name as an alias, but revert back to the standard name as it's correct name.
So what that really means is that both r_lerporient and gl_interpolate_frame (or whatever it was called) both refer to the same cvar. So it doesn't matter which you have in your config. So I can start standardising my cvar names better and gain better compatibility with other engines while at the same time not lose compatibility with old versions of DirectQ. Which is nice.
Posted by mhquake at 11:20 PM
I ended up not doing the cvar thing today, although that's going to be easy (I'm just going to reuse stuff from the alias system).
Instead I tuned the occlusions system a little bit more after observing that one mod was creating over 100,000 query objects! Surely something wrong there.
We can now reuse objects for different entities as soon as they go idle, which - in conjunction with the dynamic cutoff - reduces that mod's usage to about 15, while still retaining the full performance benefits of using occlusion queries in the first place. Big difference.
In practical terms this means that you'll get some extra performance (as so many objects don't need to be checked each frame - but it's not that big a deal as most of those 100,000 would have been idle and therefore not checked anyway) and a nice speedup on map loading (as so many objects don't need to be destroyed and recreated each time).
Posted by mhquake at 9:40 PM
A small but significant improvement made it's way into the occlusion queries system today. Previously the case was that hardware occlusion culling was only applied to models if their complexity was above a certain threshold (more than 96 triangles). This worked fine enough but it was always the case that simpler scenes with a low number of models used to suffer the overhead of query issue and result fetch when it might have been just as fast to just render the things. What's so special about 96 triangles anyway? Why should a gain of one single triangle make the difference? Scene complexity certainly isn't a binary factor.
The solution was to implement a dynamic threshold based on scene complexity. This uses the number of triangles actually rendered in the previous frame (more on this shortly) and scales the threshold so that if the previous frame was complex models in the current frame are more likely to have queries issued, whereas if the previous frame was simple queries are less likely.
There's a lot of "fuzz" in this; the scaling factor chosen was quite arbitrarily and the previous frame thing assumes that a scene isn't going to change too much from frame-to-frame (the occlusions system already makes use of that assumption to prevent stalling the pipeline, by the way). In practice though it works out very well, with small gains and better all-round performance levelling.
Next up I'm going to give the engine the ability to refer to the same cvar by multiple different names. This should help DirectQ coexist better with other engines.
This is getting exciting now.
Posted by mhquake at 5:58 PM
Monday, March 15, 2010
Items are being marked off the to-do list pretty well now, so it's getting to the stage where I start speculating about possible release dates.
Of course I'm still going a little slower than normal with my work, but starting to build up some momentum now. However there are a few items on the list - like debugging fog - that I can't really guess how much time they'll require. Having said that it's looking quite likely that sometime towards the end of March (if not sooner) is one possible release date.
The latest work done was a little more on the sound system. We now have the old "Sound Options" menu back, and unfortunately even the so-called "Simple Menus" are now becoming a little full. What it does give you hovever is the ability to set sound parameters in-game without needing to go near the console or command-line, which I'd argue is a usability improvement that justifies it. (You can still use cvars or the command-line if you want of course, and sometime soon I'm going to add the cvar list to the CodePlex site).
The other big thing to be marked off the list is scoreboard ping in Multiplayer games. As I mentioned before I've put a few walls around this feature, so that it only gets parsed if you're playing with a valid gametype and connected to a Protocol 15 server. An extended protocol should just send pings to the client without needing any nasty hacks.
One final change for today was that I've restored the use of "config.cfg" and the Necropolis demo. I might yet make them optional, but for now they're back, as firstly I think that loading Quake and seeing e1m3 play is part of the charm and atmosphere, and secondly I think that using a different cfg file - while it may provide for better engine cohabitation - actually is a usability fault as it's doing something that the player doesn't expect.
Any comments on that from anyone?
Posted by mhquake at 9:56 PM
I've started documenting DirectQ on the CodePlex site; currently I've got Windows Version Requirements, Hardware Requirements and Software Requirements up (as well as a few error troubleshooting hints), and I intend to expand this as time goes by.
The direct link is: http://directq.codeplex.com/documentation.
I'm of the opinion that this is a better approach than including a text file with each release, as sometimes late breaking bugs may happen that need to be documented, and other times a feature that I may think is easy to figure out turns out not to be so.
Posted by mhquake at 6:20 PM
Sunday, March 14, 2010
Ping in the scoreboard is one of those features where you turn over stones and things crawl out from under them. Things with far too many legs.
Now this isn't a problem with something like ProQuake which is a dedicated multiplayer client, doesn't support huge maps or alternative protocols, and can easily afford to treat special cases as the normal case as a result. For something like QRack it needs to be handled, but not so much as once again it doesn't step too far beyond supporting what ID Quake (and ProQuake) supports.
For an engine like DirectQ it is a problem that needs to be addressed. This underlines the reason why I'm normally reluctant to implement dedicated multiplayer-only features which are only of benefit when connecting to ProQuake servers: as well as the overhead of actually doing the initial implementation of the feature, there is also the overhead of making sure that it plays well with everything else, and a continuous ongoing overhead of making sure that things stay that way.
If I hadn't already announced that I was doing this, the obvious easiest solution would be to just drop the feature and say nothing at all. That might still happen, but right now it's tickling the part of me that's marked "hmmmm, interesting" well enough that I'm going to continue.
So what I'm planning on doing now is putting walls around this feature. The code required for it will only get run if you're in a multiplayer game that's using protocol 15. If I can reliably detect a ProQuake server from the client side I'll wall it off to ProQuake servers only as well.
Otherwise who's to say that adding support for this won't screw up a demo recorded using protocol 10001 for example?
This is where the ongoing absence of QuakeSrc.org is really going to be felt badly in the future. Inside3D is picking up some of the slack, and is doing a great job, but the requirement for a standards registry that everyone buys into is still badly needed. The proposed Quake Standards Base is a nice idea for sure, but I would vote for stabilising what's already there as a priority requirement before we even think about moving forward again. Unless the major engine authors start getting together and agreeing on things instead of going off in their own directions we'll end up with every engine supporting it's own mutually incompatible set of standards, and any attempt at being "all things to all men" will be doomed to failure from the start.
It was with this thought in mind that I decided to implement FitzQuake protocol 666 (and the BJP protocols) in DirectQ. I hadn't elaborated it to myself at the time, but I certainly did view it as some kind of vague requirement.
None of this is to advocate some kind of "design by committee" approach. We all know that doesn't work and produces watered down half-assed results. Throwing out ideas and getting feedback on what's good or bad about them is the name of the game here.
And so we come back to the original matter of ProQuake scoreboard ping, and the way it's implemented in the engine. Not to denigrate the original author of ProQuake, but if this feature had been properly built up with at least one eye on making it an accessible standard, it would have been far superior. The trouble with wildcards is when that wildcard becomes a de-facto standard (almost always despite itself, as it's very rare that it's the best or most elegant alternative) it always necessitates a period of pain and suffering while everything else tries to bring itself up in a compatible manner.
We've seen this happen so many times before that one would think we would have learned by now.
Posted by mhquake at 1:18 PM
Thursday, March 11, 2010
Been working on the Multiplayer side of DirectQ today. ProQuake scoreboard ping is going to be in there as well as maybe a few more ProQuake client features. I have no idea about ProQuake servers though, so it's needed to go away for testing before I can confirm whether or not it actually works. I really do need to read up on this myself though.
I've also finally fixed the crash when you connect to a server but don't have the map it's running. Now it just gives a Host_Error instead. Some day I'm going to do auto-download, but not today. I like the idea of auto-download, but to be compatible I need to find a library that I can statically link to - I'm very much against the notion of DirectQ requiring extra DLLs in your Quake directory.
This is something where I wish that the clients that currently do auto-download had copied the Q2 method instead and used an svc_download message; but even so that would have required server modification too. Ah, the joys of ancient game engines and legacy technology!
One other thing - I'm going to need to do further testing of DirectQ's online performance. Right now it's net buffer sizes are set up for extended protocols and huge maps in SP, which may be causing some issues with MP games. Overall the net buffer sizes in ID's Quake code are a mess - there's something like 611984361 different #defines that they depend on. It'll require some careful work to rationalize this properly...
Posted by mhquake at 11:52 PM
Wednesday, March 10, 2010
I've decided that I'm going to make DirectQ 1.8.2 and onwards a (limited) Public Domain work. This is something I've wanted to do for a long time now, as I have some serious reservations about the FSF and the GNU GPL, specifically their free software purity thing (another issue I have with the FSF is that I despise Unix - I'm all for a Free OS so long as it's not a Unix-like). So I'm really doing this because I don't want my work to be covered by a license that I don't necessarily agree with the ethos of. I'm fully aware that by doing this, a Big Bad Wolf might steal my work, pass it off as their own, make profit from it, and not give anything back. That's OK. I don't work on DirectQ for power, money, women, fast cars or glory; I work on it for my own personal enjoyment.
And before you ask - yes, I've checked on the GNU website and have confirmed that this is fine to do.
Versions 1.8.1 and before will remain GPL. Additionally, DirectQ contains code for which I do not own the copyright. This code includes the original ID Quake code, the MD5 generator, the unzip.c code, anything I've sourced from tutorials or other folks engines, and maybe a few others. The licenses attached to this code will need to remain in force, so the Public Domain release will only apply to my own original changes. It will however retroactively apply to all changes in 1.8.2 onwards that are original work by me, irrespective of when those changes were made.
What this means is that a piece of my code sourced from the 1.8.2 or later codebase will be Public Domain, but the same piece of code sourced from any earlier version will be GPL, even if the code has been completely unchanged between versions.
Until DirectQ 1.8.2 is actually released none of this will apply, of course.
Posted by mhquake at 9:32 PM
Tuesday, March 9, 2010
Just finished up adding the EBFS and DP extensions frameworks. There's quite a bit of ugliness in here - use of cvars which can be changed by the player, function remapping (for when the framework was in a transitory state almost 10 years ago) and so on, but I did the lot, ugliness and all.
Repeat of Advance Warning
This doesn't mean that DirectQ now supports DP extensions. The framework required to support them is there, but no extensions have been added to the engine.
Once again, if someone would define which extensions are the "common" ones, I'll probably add them. I might also go through an older DP codebase and add some from that sometime.
But - and again, once again - without a means to test these I can't guarantee any kind of compatibility (or even that they'll work).
Posted by mhquake at 6:47 PM
I've gone back to sound for a bit and resolved the temporary memory overhead (it wasn't really a leak as there was still valid pointers) from changing the sampling rate while a map was running. This was always only about 1MB or so, so it was never a big deal, but it still feels good to have done it. While doing this I also spotted a genuine leak when changing games so that's fixed as well now (it would only have been an issue if you changed games hundreds of times while running).
Been looking over the EBFS, DP Extensions and Frik File tutorials on a mirror of the old QuakeSrc page, and I think I'm going to go for them. I do have an extension framework already, but it was never tested so I don't know if it works or not.
In the absence of someone pointing me at a mod, all of these will also remain untested. Also, EBFS and DP will be just the framework for supporting extensions - don't expect DirectQ to suddenly start sprouting actual real extensions.
If you care enough about having these features in DirectQ you know what to do.
Posted by mhquake at 5:35 PM
It took a while to track down the code that was blocking this, but I've finally found it. There were actually two places that needed to be addressed; the first was the code that handled the mouse state in windowed modes when the menu or console are up (going into keybinding mode needed to regrab the mouse), the second was in the main mouse input loop for DirectInput where I have a check that just flushed the buffers and got out if the mouse shouldn't be active (this helps to prevent buffered up commands from unwinding when you go back into the game).
It's looking like scoreboard ping is just not going to happen at all. I was hoping to be able to at least give you your own ping time back to the server, but on further investigation of the code it seems as though not even that is available to the client. The alternatives are either breaking the protocol or implementing the kludgy hack that is the ProQuake messaging system. I'm not going to break the protocol, and the ProQuake messaging system is a kludgy hack. Basically what it does is write ping times into a string, something like "Client ping times:100 200 127 212" etc, which must then be parsed out. Why it couldn't have treated the string as a byte array and used the standard Msg_Read and Msg_Write functions I'll never know, but it's too late to go back now.
Anyway, I have huge reluctance to do this as string parsing in C can be evil. Plus DirectQ is not a dedicated multiplayer client - it's a general-purpose client that can be used for multiplayer. Implementing dedicated multiplayer features will steal time from elsewhere, with the end result that something more generally useful might end up not being done.
Somebody asked for "common DarkPlaces extensions" but nobody rose to the bait when I asked "define which extensions are 'common'". This is a shame as I'd like to start implementing some of these, DirectQ already supports the necessary checkextension framework, and I've even done some of the required code for some. But I need to be told which extensions are "common", because otherwise I'll just do code that never gets tested and may not be even useful. At least I need to be pointed at a mod (and make it an SP one please so that I can test more easily, and crash without breaking someone else's game) that uses some of these mythical lesser-spotted "common" extensions.
Otherwise it won't be done.
The same goes for Frik File, and any other extension of the default Q1 behaviour, by the way. Give me the name of a mod that can be tested in an offline and safe manner and I'll do it, otherwise I won't.
Posted by mhquake at 11:51 AM
Wednesday, March 3, 2010
Just so you know, here's what built up on the to-do list for 1.8.2 so far. Some of these are bugfixes, some are new features, and I haven't included stuff that's already done. (Update 5th March 2010 - started marking off current status of each of these items.)
- Menu options for sound sampling rate - done.
- Correct sound resampling for higher rates.
- Proper sound memory cache - done.
- 8 bit sound toggle during gameplay - done.
- Fog is broken.
- Frik file?
- Common DP extensions (which? Define "common".) - framework done.
- Console cursor is broken - done.
- Client ping on MP scoreboard - done.
- Elapsed time on MP scoreboard - done.
- Mousebuttons in keybindings menu are broken (possibly in windowed modes only?) - done.
- Reset gamma and turn off music on Alt-Tab (who woulda ever thought that people Alt-Tab out of and back into Quake so much? Certainly not me.) - done.
- Does always run not increase back speed? Check - done.
- Check gun model size with FOV > 110; possibly reduce - won't fix.
- Levelstats command - in progress.
I'm currently in the process of easing back into things. I don't feel very inclined to go right back to some of the coding marathons that the original 1.8.0 involved, so it's going to be small chunks of work on a semi-regular basis for at least the immediate future.
Posted by mhquake at 7:17 PM