tag:blogger.com,1999:blog-83569821849980344452012-02-08T23:01:13.742ZThe MHQuake Development Blogmhquakenoreply@blogger.comBlogger9741100tag:blogger.com,1999:blog-8356982184998034445.post-8324024004775021492012-02-08T01:24:00.003Z2012-02-08T01:30:11.356Z

Worked over the texture loader some today. I've added support for textures loaded from directories called the same as the value(s) of the "wad" worldspawn key (with multiwad support). This is in addition to, not instead of, the "textures/mapname/" convention, so now I support both. I also added support for the QRP standard (i.e a "_bolt", "_cable", etc suffix on the texture name) in addition

mhquakenoreply@blogger.com5tag:blogger.com,1999:blog-8356982184998034445.post-23099210152132287462012-02-05T02:05:00.002Z2012-02-05T02:17:44.658Z

RMQ got GPU animation of IQMs today; it turned out to be hugely simpler than I had originally thought it would be and as a nice bonus it has seamless CPU fallback if the hardware capabilities don't meet the requirements of each individual IQM. Of course this means that the slower case will run on the slower processor, which is generally not what you want, but in this case it's no worse off than

mhquakenoreply@blogger.com4tag:blogger.com,1999:blog-8356982184998034445.post-34515056915586986192012-02-03T17:10:00.000Z2012-02-03T17:10:17.042Z

Seems that for the past year and a half I have been reading from a dynamic vertex buffer created with D3DUSAGE_WRITEONLY. Ouch. What's amazing is that this actually worked. What's even more amazing is that it never seemed to impact performance overmuch. What's most amazing of all is that it never showed up in debug runtime or PIX analysis. I finally managed to catch it when consolidating

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-55438985665121605092012-02-03T02:27:00.000Z2012-02-03T02:27:48.834Z

A quiet day with not too much done. IQMs got alpha support and torch model animations got fixed up a little (they now use the correct animation intervals from the MDL file, and a missing last frame in each animation was restored). Also fixed up fence textures, so I think - with the exception of the static entities bug I mentioned previously (and which I still haven't a clue about the cause of)

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-47402392870346060512012-02-02T00:28:00.000Z2012-02-02T00:28:29.053Z

Got fog on IQMs and fixed up bounding boxes; I think only alpha is left to do. Spent some time chasing a few outstanding bugs. The old clipping weirdness bug is now well and truly fixed. That one was a result of me trying to be too clever for my own good during map loading. There's a fairly minor static entities bug left that sucked up far too much of my time and ended up not being tracked

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-13343372165728679702012-02-01T03:07:00.001Z2012-02-01T03:08:55.348Z

void D3DIQM_AnimateFrame (iqmdata_t *hdr, int currframe, int lastframe, float lerp) { // temp memory for building the animation D3DXMATRIX *outframe = (D3DXMATRIX *) scratchbuf; D3DXVECTOR4 *outvecs = (D3DXVECTOR4 *) (outframe + hdr->num_joints); // this memory should never be referenced if there are no frames or poses D3DXMATRIX *mat1 = (!hdr->num_poses || !hdr->num_frames)

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-53131929529469100202012-01-31T23:48:00.000Z2012-01-31T23:48:34.573Z

I can load them, draw them, animate them (although I'm not doing this properly just yet), they can have shadows, they're lit, they're textured. Viewmodel support is there, alpha not yet. Joint animations are being done on the CPU, vertex animations on the GPU. Joint animations will likely remain on the CPU (at least until I go to D3D11 where multiple constant buffers will enable this to be a

mhquakenoreply@blogger.com4tag:blogger.com,1999:blog-8356982184998034445.post-28149927254945548902012-01-30T20:50:00.001Z2012-01-30T20:52:18.205Z

External textures are almost done. Right now I'm left with trying to work out a solution for cases where textures have the same name but different images. Trouble here is that there are two standards for handling this that have evolved over the years, and ideally I'd like to support them both (previously I'd only supported the QRP standard, currently I only support "textures/mapname/", both are

mhquakenoreply@blogger.com2tag:blogger.com,1999:blog-8356982184998034445.post-80096281102631524542012-01-24T22:24:00.002Z2012-01-24T22:30:01.755Z

I've started on reworking DirectQ's external texture loader, meaning that the release will be delayed. I'd come really close to not doing this at all, but in the end it feels like the right decision: as this will be the last major D3D9 release it deserves to be a higher quality release, and it will give me a cleaner codebase to move to D3D11 from. I won't go into the reasons why the external

mhquakenoreply@blogger.com5tag:blogger.com,1999:blog-8356982184998034445.post-83704783216937719102012-01-22T23:52:00.000Z2012-01-22T23:52:32.390Z

I've been beating a little more on these, and am beginning to wonder if handling them in any kind of robust and performant manner would really necessitate an architectural overhaul. The real problem with them stems from the fact that multiple entities can share the same model. Because each entity must be in a different place, it follows that each entity can be affected by a different set of

mhquakenoreply@blogger.com8tag:blogger.com,1999:blog-8356982184998034445.post-5843946421406123462012-01-22T19:36:00.001Z2012-01-22T19:37:08.358Z

DirectQ just got another important addition to lighting, which is that BSP brush models now get dynamic lights properly (there are a lot of issues with giving them lighting from the environment which only a fully realtime solution could satisfactorily resolve). This resolves one major issue I have with this model type which is that if a mapper uses them for structural geometry or for props, and

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-3269609384512422302012-01-21T01:33:00.000Z2012-01-21T01:33:18.556Z

I spent a few minutes today cleaning up one thing with DirectQ textures; nothing major but an extra (and completely unnecessary) layer of abstraction was gotten rid of. After that Heineken Cup Rugby kind of took hold and my time disappeared in a pleasant haze of beer and shouting at the television in a bar. Productivity will be restored tomorrow (some neat ideas brewing for RMQ...)

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-37840217524076080512012-01-20T00:42:00.003Z2012-01-20T00:51:14.115Z

Didn't get much done today; just some brief testing of DirectQ's refresh rate changing (it worked). There are a few things I want to get stuck into shortly, however, so this is the deep breath before. RMQ is having a review of it's 2D GUI code. The stuff originally inherited from QuakeSpasm by way of Fitz (or should that be the other way around?) was fundamentally fine (although I would have

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-52625040724086843732012-01-19T22:22:00.002Z2012-01-19T22:27:57.717Z

Over the years I've evolved a number of different solutions to the problem of updating dynamic lightmaps. This is one of the major bottlenecks in Quake and - depending on your hardware - is capable of dropping framerates down to single digit in extreme circumstances. To set the context, GLQuake (in it's multitextured path) did some of the worst things possible with lightmap updates, and Quake

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-69815238066137463082012-01-18T02:30:00.002Z2012-01-18T02:39:41.146Z

Another slight code reorganization - recovering default pool resources from a lost device or video restart has moved to the start of a frame rather than happening in place. This was done to prevent an old problem where you'd lose the device, then recover it, then a system event (such as a window resize) might cause you to lose it again immediately afterwards. Now it only recovers these

mhquakenoreply@blogger.com11tag:blogger.com,1999:blog-8356982184998034445.post-52074431964058744372012-01-16T23:45:00.001Z2012-01-16T23:47:13.325Z

The main D3D-related video code is now down to 900-odd lines. That's about twice as much as my D3D11 version, but much of it is lost device handling, capabilities checking and fallback modes, which don't exist with D3D11. Been spending a lot of time playing around with switching modes, Alt-Tabbing back and forth, and so on, and things seem solid and behave correctly. An old DirectQ bug where

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-31072963561402701252012-01-16T18:18:00.003Z2012-01-16T20:37:32.769Z

A very productive time fooling around with video modes - I know that I said I wasn't going to work any more on DirectQ's video code until I moved to D3D11, but I decided to put in some prep-work on restructuring in advance of this.Historically, DirectQ hasn't supported refresh rate changes (aside from a brief time when I had it in but it crashed horribly). The reasons for this are a combination

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-39255759879859395652012-01-16T00:06:00.001Z2012-01-16T00:09:07.483Z

Some more work has been done on the input code, getting rid of a lot of jerkiness and roughness that manifested under certain circumstances. A lot of this was "low level" jerkiness that really wasn't too evident in regular gameplay, but could be reproduced by e.g. setting host_timescale to a low-ish value. There are all kinds of subtle details in the input code and the timing of when you

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-75730331717646808432012-01-15T05:02:00.001Z2012-01-15T05:03:16.089Z

I've added DXT texture support to RMQ, with the intention of helping to reduce download sizes and speed up load times, but an obvious question arises: what if the end-user's hardware doesn't support the required extension? My initial thought was to unpack the DDS to an RGBA format and upload that instead. We still get the reduced download size, and the player can play the game. However, it

mhquakenoreply@blogger.com2tag:blogger.com,1999:blog-8356982184998034445.post-7114098783175850942012-01-12T19:47:00.000Z2012-01-12T19:47:36.889Z

My previous intention has been to release one more DirectQ version - 1.9.0 - which continues to support legacy hardware, then remove certain items of legacy support from an intermediate version (1.9.5?) before moving to D3D11 for version 2.0.0. I've changed my mind. I'm still releasing 1.9.0 with legacy support, but after that I'm going to D3D11 and version 2.0.0 straight away. There are a

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-68757728755938095852012-01-11T18:02:00.002Z2012-01-11T22:44:13.096Z

Speeds of the D3D11 engine are coming right up and it's looking as though it's shortly going to be faster than DirectQ in all cases. D3D11 is quite different in how you need to structure things than OpenGL or even D3D9; you can't just blast out a few drawing commands and hope that the driver will be able to figure out the best thing to do on it's own. Instead you actually have to sit down and

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-17865222420235168812012-01-10T23:48:00.001Z2012-01-10T23:49:44.133Z

I just ported the FitzQuake protocol to my D3D11 engine, because I wanted to test it's performance under certain high-stress situations. The end result was quite pleasing. The obvious first test was my 400 Knights Death Map. Here the current stats are something like: FitzQuake - 50 to 60fps; DirectQ - about 350fps; RMQe - about 300fps; QuakeSpasm - just over 50fps; DarkPlaces - about 100fps.

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-39492890876366679812012-01-10T18:48:00.000Z2012-01-10T18:48:49.315Z

Have I said that before? Well I'll say it again. I now have video mode changing fully working, including transitions from windowed to fullscreen and back, changes between modes when windowed or fullscreen, refresh rate, vsync and the ability to pick whether the mode is centered or stretched on the target window. I don't yet have adapter or output selection; from what I can gather so far these

mhquakenoreply@blogger.com2tag:blogger.com,1999:blog-8356982184998034445.post-12140675994411092362012-01-10T02:44:00.000Z2012-01-10T02:44:13.446Z

I bit the bullet and did video mode changing. It's not the prettiest code, but most of that is down to the nasty old classic ID Quake menus and the lack of more refined cvar control - neither of these problems will apply to DirectQ. As before, I start in a windowed mode and switch to fullscreen during startup if requested. The reason why is because it's safer and less obnoxious on the end-user

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-51066307919874451002012-01-09T20:49:00.001Z2012-01-09T20:49:52.126Z

The new D3D11 video code is coming along very well indeed. I'm taking the opportunity to clean out all of the nastiness in gl_vidnt, move things around to more logical places (there's code in there that should be in sys_win, other code should be in in_win) and organize it better. The objective is that I'll have a nice set of clean and functional video code that can be almost lifted over to

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-26430890774131987882012-01-09T12:39:00.001Z2012-01-09T12:40:17.299Z

The D3D11 port is now functionally complete aside from the video mode stuff. I just finished things off by adding r_wateralpha and gl_texturemode support, and it rocks. For gl_texturemode I added anisotropic filtering too. This one is interesting: traditionally I had thought that anisotropic filtering was something that gets added in addition to the standard filtering modes; it turns out that

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-26938310470521368762012-01-08T23:06:00.002Z2012-01-08T23:11:45.429Z

The D3D11 port is pretty close to complete. Here's what's left to do: gl_texturemode Right now I'm just forcing 4x anisotropic filtering at startup, but I want to get this done fully, even if it's not really a critical feature. It seems like it should be easy enough. gl_flashblend 1 mode AKA the alternative to dynamic lights - draw a shaded ball around each light. Not really a big deal as

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-31710870456887745982012-01-08T04:36:00.003Z2012-01-08T07:44:02.300Z

There was maybe 2 or 3 days work so far in that port, and most everything is done now. There's still some drawing left to finish off and bugs to iron out, but otherwise - yeah, it's cool. Overall the experience started out as hugely ugly, but quickly became very enjoyable indeed. Object creation was the main source of nastiness; everything has gone back to filling in a struct and passing the

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-63938308929434061932012-01-07T15:55:00.001Z2012-01-07T20:02:50.935Z

16 byte submission per particle, geometry shader billboarding.

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-17149451819713021422012-01-07T02:13:00.000Z2012-01-07T02:13:44.211Z

I'm currently porting GLQuake to D3D11. This was prompted by one requirement of my recent GPU lightmaps experiments - I needed bitwise operations in shaders, and they're not available in SM3 or below. So far - it's interesting. I'll rant a bit about the overall experience when done, but for now it's enough to say that things could - and should - have been a lot better. At the moment I have 2D

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-88125771926099420782012-01-04T17:41:00.002Z2012-01-04T19:40:43.183Z

I've done an implementation of GPU lightmaps in my test Direct3D engine. This was already done for RMQ (and a forked version of DirectQ) but with this one I bumped the hardware requirements up to full Shader Model 3 and took advantage of extra instructions, floating point textures, longer shaders, extra constants registers space, vertex texture fetch and dynamic branching. Speed is very

mhquakenoreply@blogger.com6tag:blogger.com,1999:blog-8356982184998034445.post-77145907741303898082012-01-04T01:42:00.001Z2012-01-04T01:53:04.418Z

A nice improvement has just gone into dynamic light handling. DirectQ will now move each dynamic light into the same space as the brush model entity it's (potentially) affecting before calculating the light contribution, meaning that dynamic lights are applied properly to moving brush models. You can see this in e1m1 if you ride the first platform down to the open area. Fire your shotgun at

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-62418404983911029582012-01-03T23:06:00.001Z2012-01-03T23:07:41.150Z

Previously DirectQ has used something of a hack for interpolation; this was needed to fix the muzzleflash animations on weapon models and worked by disabling interpolation for certain vertexes if they had moved beyond a certain amount between the first two frames in the model. While it works perfectly fine for all viewmodels in all mods I've tested, there remains a possibility that at some point

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-54343718488115521632012-01-03T19:19:00.000Z2012-01-03T19:19:12.532Z

The death-knell for my Windows XP/D3D9/Intel graphics PC finally sounded today when I switched it on and had a ton of errors pop up about failing fans and other such fun. I managed to keep it running for long enough to pull some stuff off it, but I'm wary about switching it on again. Given the age of the machine, it's not worth hunting down replacements and fixing it up, so it's gone to the

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-80967262508528517442012-01-02T20:44:00.000Z2012-01-02T20:44:39.472Z

New year, more work being done. With the RMQ engine ready for release I'm taking some time to tidy up a few things in DirectQ. Some of the major outstanding defects will need a good many more passes over the code to correct, but we're getting there, slowly but surely. A texture animation bug where some switches/buttons wouldn't go into their alternate animations has been fixed. GUI/HUD

mhquakenoreply@blogger.com6tag:blogger.com,1999:blog-8356982184998034445.post-60790355149492411792011-12-29T23:25:00.002Z2011-12-29T23:33:43.636Z

The RMQ demo should be coming any day now; engine work is complete barring any last minute emergency bugfixes and content is coming together very well. We won't be releasing source code with the main demo release, but I will be putting together a "devkit" release (separate from, but hopefully to coincide with, the main release) containing all engine and tools source, a few notes on some

mhquakenoreply@blogger.com2tag:blogger.com,1999:blog-8356982184998034445.post-73312413603167351592011-12-25T13:12:00.000Z2011-12-25T13:12:44.458Z

Download from here. This release focusses on code quality and bug fixes rather than on adding any radical new features; if the previous release of DirectQ worked fine for you there is probably no need to download this one. It contains the beginnings of an "enhanced" particles system, but that's quite unfinished. You can turn it on and use it if you wish, but be aware that what you're seeing is

mhquakenoreply@blogger.com21tag:blogger.com,1999:blog-8356982184998034445.post-31436580104834244192011-12-13T21:44:00.002Z2011-12-13T21:45:53.368Z

I've been quiet for a while but not idle. A good chunk of recent time is going into tuning the RMQ engine for the upcoming planned demo release, and things are quite exciting. It's fair to say that I'm really enjoying what I'm currently doing with it, and that it's shaping up to be a strange and interesting beast. This is likely to continue until the demo is released, and I expect probably for

mhquakenoreply@blogger.com6tag:blogger.com,1999:blog-8356982184998034445.post-70150403146849376322011-11-30T19:49:00.000Z2011-11-30T19:49:02.639Z

Here we go. Like I said, this isn't really noticeable in static screenshots, but anyway... The top one is the original shader, the bottom is my replacement. First of all, ignore the framerate differences. This just comes from writing the image to file and sometimes it shows up in a screenshot, sometimes it doesn't. Secondly, I did warn you that it wasn't very noticeable in screenshots.

mhquakenoreply@blogger.com12tag:blogger.com,1999:blog-8356982184998034445.post-40431076077659223362011-11-29T23:07:00.001Z2011-11-29T23:13:10.037Z

I've been playing around a little with Doom 3's main interaction shader. This is something I likely could have done before the source release (although getting the env params from the vertex shader into the fragment shader may have been slightly tricksy), but it's fun to do it now. So, pretty much everything that was in the vertex shader has now moved over to the fragment shader, normalization

mhquakenoreply@blogger.com13tag:blogger.com,1999:blog-8356982184998034445.post-12458435933307645912011-11-24T22:02:00.000Z2011-11-24T22:02:46.998Z

Just been looking at the stencil shadow code again. What's really annoying about this is that what Creative have patented essentially boils down to this:-1 + 1 = 0 1 - 1 = 0 0 - 1 = -1 0 + 1 = 1This really comes through when you see it expressed using glStencilOpSeparate, you just see the lines of code stacked up, and it's so obvious.

mhquakenoreply@blogger.com6tag:blogger.com,1999:blog-8356982184998034445.post-27893752107104077092011-11-24T20:09:00.001Z2011-11-24T20:11:44.262Z

Still uncertain if I'm going to actually do anything serious with the Doom 3 source. Been playing around with it a bit more, and I find myself making what are relatively minor changes here and there - there may sometimes be quite a bit of work involved for sure, but nothing is leaping out as a "oh yeah, this would really improve the engine for me" type thing. In other words, I don't actually

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-6691713703576522872011-11-23T19:15:00.000Z2011-11-23T19:15:29.636Z

Now that the Doom 3 source is out, I've been having a quick look over it and deciding what on earth I'm going to do with it.My initial objectives are to get a sane codebase to work from, so for now I'm just running through it and doing some reorganization here and here.A few notes:The working codename for the Quake 3 engine was "Trinity"; Doom 3 is called "Neo". Cute.It's a Visual Studio 2010

mhquakenoreply@blogger.com2tag:blogger.com,1999:blog-8356982184998034445.post-15751517323732881392011-11-21T22:28:00.000Z2011-11-21T22:28:28.712Z

OpenGL is just a constant struggle against broken drivers. Right now I'm moving RMQ's code from old-style glEnableClientState/gl*Pointer calls to generic attribute arrays, basically because I have an extreme loathing for glClientActiveTexture (plus I also need them to be able to specify MDL positions as 4 bytes instead of 3 floats for a video RAM saving to offset that which I lost from lightmaps

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-80998692300159813902011-11-17T20:50:00.000Z2011-11-17T20:50:24.344Z

The way things are curently going, it's looking like I'm going to be committing to GPU lightmaps in DirectQ as well. There are a couple of awesome things coming out of this code that make both the slight performance hit and the texture memory overhead a more than worthwhile tradeoff. The smoother gameplay I mentioned in my previous post is the main one, and this on it's own is enough to swing

mhquakenoreply@blogger.com7tag:blogger.com,1999:blog-8356982184998034445.post-22980504264224031012011-11-17T02:09:00.000Z2011-11-17T02:09:52.215Z

I'm porting my GPU lightmap setup to RMQ at the moment, but this is without commitment to any final decision. The objective is to try it out and see what happens when it's hit with some really heavy data sets. Some interesting things are falling out of this work. For RMQ we're going to need 5 simultaneous textures to light the world; one for diffuse, 3 for lightmaps (each is one of the RGB

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-23305934670010462792011-11-16T01:09:00.000Z2011-11-16T01:09:59.480Z

Now that I've got my face stuck in Rage a little bit less, it's time to revisit the topic of GPU lightmap updating. You'll remember that I had made some inroads into this with a fork of DirectQ a while back. Lately I've been playing around with it some more in an experimental GLQuake build, and have pretty much cracked the problems I had encountered before.Here's the important part:!!ARBfp1.0

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-66667560159705487412011-10-26T19:11:00.000+01:002011-10-26T19:11:57.427+01:00

I have more or less working sky domes in DirectQ. For the curious, this allows a single 360 degree panoramic texture to be used in place of a skybox (or the default sky layers). The kind of texture I'm talking about is one that looks like this: Some things remain to be worked out. If you search the web for this kind of texture, you'll find two main types. Some of them are for mapping on a

mhquakenoreply@blogger.com7tag:blogger.com,1999:blog-8356982184998034445.post-91277113643890924122011-10-22T03:08:00.000+01:002011-10-22T03:08:38.746+01:00

I found out how to turn off the excessive light bloom/glare in Rage; a simple r_skipGlare 1 will do the trick. Here's a shot: This one is also significant because it's from much the same viewpoint as a "Rage 2010/2011" comparison shot that's available on the web, for example here: http://img40.imageshack.us/img40/3333/idasbest.jpg. This should hopefully make it clear that the so-called 2011

mhquakenoreply@blogger.com5tag:blogger.com,1999:blog-8356982184998034445.post-1874061473843687802011-10-18T19:35:00.001+01:002011-10-18T19:35:57.286+01:00

Now that I've finished Rage I've gone back to a save game (before entering Capital Prime) and am basically just sandboxing the game. Doing races, driving around killing bandits, and picking up missions I'd missed out on first time through, without having to care about following a main plot line. Of course because a lot of areas are closed off you can't really sandbox it, but it's still fun.

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-46737514326131719232011-10-17T00:36:00.000+01:002011-10-17T00:36:36.272+01:00

That was tremendous fun; a solid 28 hours of gameplay (and there was loads I missed out on so a replay is going to be pretty much essential) and the only real let-down was - yup, you guessed it - the ending. I reckon it's a setup for "Enemy Territory: Rage Wars". The sole major gameplay problem I had was with mouse movement. It's just too unpredictable/fast/imprecise in the menus and too slow

mhquakenoreply@blogger.com5tag:blogger.com,1999:blog-8356982184998034445.post-63615421695328976532011-10-11T23:52:00.000+01:002011-10-11T23:52:39.101+01:00

...that ID included this in the game. Given the amount of negativity and general bullshit flying around there's a risk it could be taken up the wrong way. This, on the other hand, is beautiful. What you don't get to see is that it's the aftermath of probably the most intense and nerve-wracking firefight so far. Maybe a future iteration of megatexture will allow for persistent blood decals

mhquakenoreply@blogger.com6tag:blogger.com,1999:blog-8356982184998034445.post-47614885574947380442011-10-10T01:30:00.004+01:002011-10-10T01:51:55.308+01:00

In 1998 it was coloured light. In 2004 it was bumpmapping. The 2011 candidate for "too much! overdone! tone it down!" is bloom. What do you think? That aside, the game is wonderful. Yes, so the textures are lower-res than other modern games. So what? Big swingin'. It's a tradeoff, and anyone who complains about that really mustn't have played much further than the first few minutes of

mhquakenoreply@blogger.com4tag:blogger.com,1999:blog-8356982184998034445.post-65728272350059947522011-10-07T23:30:00.000+01:002011-10-07T23:30:48.415+01:00

It's running quite well for me (but then I knew it would as I don't have ATI on my main machine) but it's not without problems. OK, things are nowhere near as bad as some of the more hysterical corners of the internet might lead you to believe. I almost feel sorry for some of those people living their negative hate-filled little lives, but I won't waste time ranting any more about them as I've

mhquakenoreply@blogger.com2tag:blogger.com,1999:blog-8356982184998034445.post-2018505864141387992011-10-06T03:07:00.000+01:002011-10-06T03:07:13.698+01:00

...if the server runs in any given frame then the renderer doesn't run in that frame. Exceptions are: if things are running slow ("slow" is defined as less than 72 FPS), or if you're at the console or in the menus. The effect is to smooth out performance and gameplay a LOT. In any given frame there are two things that take up most of the time: the server and the renderer. Everything else is

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-39472150445903706802011-10-04T22:04:00.002+01:002011-10-04T22:11:42.230+01:00

Here's an overhead view of what I've currently got: It's loosely based around the R_LavaSplash (AKA "Chthon Rising") code, but tightens in the cloud a little, reduces the number of particles in it, doesn't raise it so much, and fades it out faster. The idea is to have something that looks a little more like a solid explosion with volume, but also not obscure the view as much as you might see

mhquakenoreply@blogger.com8tag:blogger.com,1999:blog-8356982184998034445.post-64842039737243036242011-10-04T19:36:00.000+01:002011-10-04T19:36:52.352+01:00

By now it should be obvious - the effect I'm aiming for here is "something that isn't dots but doesn't look too wildly different". This is in deliberate contrast to other engines, and the reason why is what I've mentioned before - when a particle effect goes off you shouldn't feel compelled to stop playing and look at the eye candy (meanwhile an Ogre is getting busy with trying to saw your

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-13669183052047146852011-10-04T19:07:00.000+01:002011-10-04T19:07:51.770+01:00

I was initially unhappy with this texture, but it's somewhat better now. If you look closely at Quake's teleport textures you'll see that they are actually a black field with lots of little star shapes in it, so a star shape seems the best thing to represent it. I mixed in some blue particles to add a little variety. This is normally gone by so fast that you don't even notice it. I might

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-86665883138433077052011-10-03T23:45:00.001+01:002011-10-04T01:21:25.189+01:00

Here's the rocket trail. It occurred to me that I talked a lot about how subtle the effects were but then I went and posted shots of the two most OTT. This is more indicative of what things are like (the corona around the rocket is an option that has always been there, by the way). Previous screenshots were from an earlier, more heavyweight implementation; I've since switched them to using

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-15886350549160589672011-10-03T20:11:00.000+01:002011-10-03T20:11:04.077+01:00

If you've looked at DirectQ's source code you will be quite well aware that I have, and have had for some time, a quite explicit intention to one day add a "fancy particle system" to it. I've also mentioned this from time to time in passing. It seems as though that day is today. The intention here is NOT to replace outright the original "dots" system but to provide something that looks vaguely

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-91966059745984198612011-09-29T18:47:00.000+01:002011-09-29T18:47:11.763+01:00

It's looking as though the next release of DirectQ is going to be the last one that can fully guarantee support for Windows XP. Bottom line is that I'm soon going to be in a position where I just no longer have access to a Windows XP machine for testing on. In those circumstances I'm not really going to be able to fire up XP, run tests, debug, etc. I can't stand over DirectQ on XP as a

mhquakenoreply@blogger.com7tag:blogger.com,1999:blog-8356982184998034445.post-23528100684194623422011-09-28T20:00:00.001+01:002011-09-28T22:01:21.808+01:00

I've been playing a little with the vsync code this evening. One thing that annoys me slightly is that NVIDIA and Intel don't honour the D3DPRESENT_DONOTWAIT flag. This is a nuisance because if I could use it I would be able to have a situation where I could run the client and server independently of the renderer and retain smooth input response with vsync enabled. Some fooling around with

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-87226353804994192112011-09-28T01:37:00.001+01:002011-09-28T01:37:56.383+01:00

I've been cleaning up some of the MDL code and managed to get a few extra percent speed out of it. Previously each MDL lived in it's own individual vertex buffer, now they all live together in a single big buffer (there's actually two separate buffers - one for position/normal and the other for texcoords). A previous attempt at this resulted in some glitches with Nehahra (what else?) but after

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-2766343449309706892011-09-25T16:14:00.000+01:002011-09-25T16:14:03.805+01:00

It occurs to me that I've talked a lot about the new HDR lighting mode, but I haven't actually shown you anything. Let's change that. Here's a few shots of a pretty standard Quake rocket explosion. Nothing fancy, the kind of thing that happens all the time in regular ID1 Quake. I've tinted the explosion orange so that you can see the results better, especially in the second case. First up we

mhquakenoreply@blogger.com21tag:blogger.com,1999:blog-8356982184998034445.post-1549822876735493152011-09-25T13:31:00.000+01:002011-09-25T13:31:56.761+01:00

As originally posted by GB last year: http://kneedeepinthedoomed.wordpress.com/2010/11/07/orange-light-green-walls-far-out-experiences-with-colored-light/ Further work and experimentation has positively identified the criminal in this case as clamping. Now, encoding the lightmap as a HDR texture format and decoding it in your fragment shader goes a long way to resolve the effects of this

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-65527696292550829862011-09-25T00:14:00.003+01:002011-09-25T01:34:07.648+01:00

It feels slightly bad to be pulling back on something I'd said I was doing, but I guess it's better to do it now than to wait until after a release.Lightmaps have changed yet again.I'd brought everything to the stage where all I had to do was just add the menu options, but then realised that the whole thing had become a horrible mess. There were slightly weird bugs cropping up, performance was

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-28050316610119599372011-09-22T23:31:00.000+01:002011-09-22T23:31:29.447+01:00

I've been tweaking the lightmaps a little more (nothing is ever truly "concluded"), and some changes are coming through. The ability to switch off overbrights came back. Nothing really happened to make me back off on my prior hardline stance, I just decided to put it back on a whim. While being a purist in terms of your goals can be a good thing, it's also nice to give people options. I did

mhquakenoreply@blogger.com9tag:blogger.com,1999:blog-8356982184998034445.post-78649131465518626092011-09-21T19:01:00.000+01:002011-09-21T19:01:54.186+01:00

The culmination of my recent work on the lightmapping code has been reached, and it goes something like this. The experimental HDR texture formats are gone. Too much messing, performance issues and quality tradeoffs involved in trying to get a better range out of 8/8/8/8 textures. 64-bit lightmaps are back in DirectQ. These are now the default mode and used if available. There is some speed

mhquakenoreply@blogger.com6tag:blogger.com,1999:blog-8356982184998034445.post-10370078095973257052011-09-20T23:18:00.000+01:002011-09-20T23:18:52.262+01:00

I've backed out the new lighting code. Firstly, it exhibited some serious performance problems in scenes with lots of dynamic lights. What used to be 2 or 3 milliseconds per frame shot up to 20 or so milliseconds per frame, all in the renderer and on account of additional CPU load. That's not nice. I did some patented "quick 'n' dirty" workarounds (e.g. reverting to the old style when the

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-67077166281290118422011-09-20T00:07:00.000+01:002011-09-20T00:07:39.549+01:00

The new overbright lighting model can handle up to 9 times the dynamic range of GLQuake. It preserves the same level of detail; we don't lose that pesky bit of precision (I could actually tweak it to gain an extra bit or two, but the extra dynamic range would go down to 5 or 3 times GLQuake). It runs a little faster. I think that's what we call a result.

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-71750692568095922632011-09-19T22:26:00.000+01:002011-09-19T22:26:25.414+01:00

OK, I tried something with that extra 8 bits and it didn't work out. Here's how it goes. I don't like the fact that overbright lighting loses 1 bit of precision compared to GLQuake's flattened lighting. I want to get that bit back. Now, it may be the case that it's only one bit, but the difference is there, it's quite subtle, and I can set up a test case that proves it. In the past I've

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-90525689010234425352011-09-19T21:09:00.000+01:002011-09-19T21:09:44.647+01:00

Earlier on today I implemented detail textures and water caustics in DirectQ. This is not something that's going to make it into a release, but it was an interesting exercise nonetheless. Why not release it? There was a certain cost involved with my current setup that was unacceptable. I'll come to that later, but for now I'll just say that if not for that cost I likely would be releasing it,

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-89470234761641374992011-09-19T00:26:00.000+01:002011-09-19T00:26:28.952+01:00

I've bitten the bullet and begun some work on the new DirectSound port. Right now it's pretty basic; it can load a sound, play it (without any consideration of volume, attenuation, entity channels, etc), stop it when done, and unload it during shutdown. The really nice thing about the choice of DirectSound is that it can painlessly coexist with the old sound system during changeover. All I

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-83133047938479380012011-09-18T15:10:00.000+01:002011-09-18T15:10:09.559+01:00

I've dropped support for 8-bit sound from DirectQ; sounds are now upsampled to 16-bit at load time and all further sound processing is 16-bit all the way. I've also removed the upper limit (was 512) on the number of sounds that may be loaded. This is something of a prelude to a more general cleanup of the sound code overall. So, a few things have gotten cleaner as a result of this, but there

mhquakenoreply@blogger.com8tag:blogger.com,1999:blog-8356982184998034445.post-79942308702353346072011-09-16T23:29:00.005+01:002011-09-16T23:41:11.622+01:00

I've now implemented the indexed triangle strip (with static vertex buffer and dynamic index buffer) option for hardware T&L devices. This caused me much pain and suffering to get working right, so here are some "notes from the field" on the entire topic.As a general rule, hardware T&L devices are much much fussier than software T&L devices. Software T&L lets you get away with a lot of crazy

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-897022914908030762011-09-16T20:37:00.002+01:002011-09-16T20:43:30.202+01:00

It's a Quake BSP. The format is BSP2 but that's just standard Q1 BSP with some shorts changed to ints. It's the Quake engine. It's a souped-up Quake engine designed to run this kind of thing fast, but at it's heart there is still the same old Quake engine stuff. See that little red banner just to the right of bottom-center? That's maybe 2 to 3 times the size of the player. That's the

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-45954089614765607982011-09-15T23:06:00.002+01:002011-09-16T02:07:20.393+01:00

I'm currently porting DirectQ's new surface refresh code to RMQ; in the end I decided that it was the right thing to do. While - as I've said - OpenGL performance has never been as good as D3D in my tests (and DirectQ pulls off a few extra tricks - like using hardware instancing - that aren't practical for RMQ), overall RMQ performance is now starting to pull close. There are a few scenes in

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-70567165177915442082011-09-14T16:55:00.000+01:002011-09-14T16:55:55.932+01:00

You could be forgiven for thinking it, but I'm not making this up. DirectQ just got a fairly significant speed boost in big maps/big scenes; something in the order of up to 50%. This came about from the new surface refresh code I mentioned before, which is now maturing nicely. As with all other such boosts, this one is only noticeable when things get under stress. If you're the kind of person

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-13698068443709994052011-09-13T17:19:00.001+01:002011-09-13T17:28:10.745+01:00

RMQ's new BSP format is now complete in it's first revision. We have working versions of QBSP, Light and Vis that output a BSP in the new format, and we have an engine that is capable of loading and running the format. We're calling it "BSP2". This shouldn't be viewed as some kind of usurpation or arrogance on anyone's part - the name just fell out naturally in the course of informal

mhquakenoreply@blogger.com8tag:blogger.com,1999:blog-8356982184998034445.post-70645714551273696642011-09-12T14:15:00.001+01:002011-09-12T14:18:45.207+01:00

Two interesting updates today. Firstly, RMQ's new BSP format is coming along. The QBSP compiler is almost done (just one item - unrelated to the format, actually - remains to be teased out) and Light and Vis are next. Engine support is complete. The format is just a simple extension of Quake's BSP 29 to use ints instead of shorts in certain places, and the objective is to remove hard limits

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-55304860792874065282011-09-12T02:25:00.002+01:002011-09-12T02:48:16.786+01:00

With the Doom 3 source release hopefully coming closer, I've thought about it a little more and it's now looking likely that I will be doing something with the code. I haven't yet decided if this will be for public release or private use but it may make for some interesting discussion. There are a few things I want to try out in a more modern rendering environment than Quake allows, and Doom 3

mhquakenoreply@blogger.com6tag:blogger.com,1999:blog-8356982184998034445.post-18626366930879023642011-09-10T23:52:00.000+01:002011-09-10T23:52:41.340+01:00

I've completed the slight diversion into GPU lightmap updating (I actually completed it a week ago but had to disappear for a short while) with some quite interesting results. The overall verdict is that it's not going to be immediately viable but will definitely be something that it will be worth revisiting at some point in the future. It was also worth doing now to satisfy my own curiosity on

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-44442589511797326212011-09-02T19:42:00.000+01:002011-09-02T19:42:10.591+01:00

Download the Patch 1 Release from here: http://directq.codeplex.com/releases/view/72737.

mhquakenoreply@blogger.com36tag:blogger.com,1999:blog-8356982184998034445.post-87736502501718071272011-09-02T14:21:00.000+01:002011-09-02T14:21:30.306+01:00

The DirectQ update will be happening later on today (maybe 5/6/7 hours time) - keep yer peepers peeled! Following that I'm going to fork the code and do some experimental work on dynamic light updates. The idea of updating lightmaps entirely on the GPU has been nagging me for over a year now, and the only thing holding me back has been an unwillingness to mess too much with working code, and

mhquakenoreply@blogger.com4tag:blogger.com,1999:blog-8356982184998034445.post-24655794121886800892011-09-01T01:00:00.000+01:002011-09-01T01:00:20.850+01:00

The DirectQ patch release will be out incredibly soon. I have been waiting on confirmation regarding a bugfix for lightmap corruption that one person reported, but it's not coming in a timely enough manner and nobody else seems to be experiencing this bug (or at least to have reported it) so I'm going to publish and be damned. This is just intended as a patch release for the recent 1.8.8 so it

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-9788584686804982282011-08-30T19:46:00.001+01:002011-08-30T19:52:24.142+01:00

I finally made the big breakthrough and now have a solution to both DirectQ's and RMQ's integer millisecond timers not giving you the framerate you ask for via host_maxfps. At the most basic level this is because we're counting time in milliseconds and as integers; for Quake's standard 72 FPS the problem is that for 72 this translates to 13.88888888... milliseconds per frame, and the time passed

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-8834761841655210002011-08-29T00:21:00.000+01:002011-08-29T00:21:26.571+01:00

Been doing more work on RMQ's IQM support. I've managed to move a good chunk of the animation - the final per-vertex position and normal transform - over to the GPU, with consequent performance gains. The joint setup remains on the CPU, as does setup of bone matrices for each vertex. This has meant that IQMs can now go into static VBOs, which helps a little more too. A problem was hit when I

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-30814942307283818032011-08-28T17:04:00.000+01:002011-08-28T17:04:44.348+01:00

Been steadily transitioning the RMQ engine over to shaders for the past few days, and things are now nearing completion. It's been a huge cleanup across the entire codebase, with a lot of messy fixed pipeline crud just yanked out. Take sky drawing for example; for the scrolling sky layers there were previously a total of 3 passes required; one to lay down a depth buffer based on the original

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-64790223316654205642011-08-23T19:17:00.003+01:002011-08-23T19:44:53.302+01:00

It's looking as though the RMQ engine is going to be a shaders-only engine too, although in this case it won't be GLSL but will be using the older ARB_vertex_program and ARB_fragment_program extensions. These are what Doom 3 used (although RMQ will remain more lightweight) so support for them is widespread and quite rock-solid. The extension specs themselves date back to 2002, so I guess saying

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-76172680026487709882011-08-18T20:32:00.000+01:002011-08-18T20:32:34.547+01:00

DirectQ is likely going to get a patch release maybe sometime next week; there are a bunch of small updates which individually are nothing major, but taken together warrant it. My D3D 11 experiments continued a while back, but have now stalled again. I got texture loading done - it's not a nice API for loading textures (to say the least) but I managed to get something that looks reasonably sane

mhquakenoreply@blogger.com10tag:blogger.com,1999:blog-8356982184998034445.post-61181741174650594552011-08-14T15:12:00.001+01:002011-08-14T15:23:38.632+01:00

Squished another Nehahra bug. It seems as though, if you have a model called "player.mdl", the most logical thing in the world is to use it for non-players (and, of course, use something completely different for the player). Sigh. OK, I'm going to need to get my thoughts together and write up something outlining my official position on support for Nehahra "features".

mhquakenoreply@blogger.com1tag:blogger.com,1999:blog-8356982184998034445.post-44233508532582069622011-08-12T01:14:00.002+01:002011-08-12T01:17:02.294+01:00

Now that DirectQ 1.8.8 is out, it's getting time to start hitting at the RMQ big map problem. Bottom line is that we need to support over 64k clipnodes, and probably vertexes (this one was hit twice but the mappers hacked around it) and a few other things too. This is pretty much a non-negotiable requirement, and in the absence of any indication from the community as to what an acceptable

mhquakenoreply@blogger.com12tag:blogger.com,1999:blog-8356982184998034445.post-40471442095067411012011-08-11T17:59:00.001+01:002011-08-11T17:59:50.453+01:00

And here is the link.

mhquakenoreply@blogger.com2tag:blogger.com,1999:blog-8356982184998034445.post-91130954662311160002011-08-10T22:17:00.002+01:002011-08-10T22:18:30.136+01:00

Hoping to get the DirectQ release out tomorrow; it would have been today but I needed to look up some stuff in other source ports for cross-checking compatibility of some cvar names. While doing that I managed to sneak in a few extra last-minute bonus features. Worked over screenshots a little more. PCX screenshots are now fully run-length encoded so size is down a little. I also added gamma

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-59039401292143272092011-08-09T19:02:00.000+01:002011-08-09T19:02:06.136+01:00

Getting back into the swing of things a little today; it's been over a month since I really sat down and did Quake code to any degree of seriousness, but fortunately I'm not too rusty. To ease myself back I added PCX screenshots to DirectQ. This is a total non-feature as it's lower quality than TGA, BMP or PNG, has a bigger filesize than PNG, DDS and JPG, and takes longer to save than anything

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-62713220903354041552011-08-08T18:25:00.001+01:002011-08-08T20:47:16.183+01:00

Real-Life crap is still ongoing, but I'm going to be easing myself back in shortly so expect updates and releases to start coming more frequently soon. First of these will be the full 1.8.8 release of DirectQ. This isn't really too much evolved from where I left it off, but does contain a handful of extra (important) fixes and features. That should happen any day now. Next block of work will

mhquakenoreply@blogger.com3tag:blogger.com,1999:blog-8356982184998034445.post-23624974493886657282011-08-01T23:43:00.000+01:002011-08-01T23:43:14.714+01:00

Poking my head above the parapet to follow up on my previous post. As usual, Raymond Chen said it first and said it better, so here's a pretty essential piece of additional reading: http://blogs.msdn.com/b/oldnewthing/archive/2010/05/31/10017567.aspx. The comments are also good for seeing how different perspectives work out (or don't work out, as the case may be). You'll need to fight through

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-32894930065572272782011-07-14T19:49:00.001+01:002011-07-14T20:10:15.939+01:00

I originally posted this on I3D, but I believe that it also has value for going here.  I've expanded it a little from the original post, which can be read here. Some thoughts on feature requests Engine development is not a democratic process, and not all engine feature requests are born equal. If you're developing or maintaining an engine, it's inevitable that you're going to get feature

mhquakenoreply@blogger.com17tag:blogger.com,1999:blog-8356982184998034445.post-38182165723378890522011-07-06T20:04:00.000+01:002011-07-06T20:04:18.484+01:00

Work is still outstanding owing to Real Life commitments. Yeah, it's a pain, but right now the last thing I want to do when I come home in the evening is crank up the editor and look at some code. As soon as I can start picking things up again you'll be the first to know.

mhquakenoreply@blogger.com0tag:blogger.com,1999:blog-8356982184998034445.post-49547354904764468512011-06-27T23:34:00.000+01:002011-06-27T23:34:29.742+01:00

The ProQuake match timer and teamscores are in. I guess that'll make some people happy. One slightly sticky bit was finding a suitable piece of on-screen real-estate for the match timer; ProQuake itself just overwrites the last two positions in the frag bar but I've shifted it upwards a little so that I can retain them. Otherwise it's just been minor nips and tucks here and there. It's

mhquakenoreply@blogger.com9