Tuesday, December 28, 2010

New Years Wishes

Rather than making a new year resolution, this time round I'm going to make a new year wish. After all, you do need to spoil yourself every now and then.

So here it is. For 2011, can I please please please have a "no close-ups of insects on the home page" option on Wikipedia? Please?

For everyone else, enjoy the last few days of 2010 - it's been a mighty strange year but you could never accuse it of being boring!

See you all next year!

Friday, December 24, 2010

RMQ Christmas 2010 SP Demo is Out

After a gruelling marathon in which it seems as though Murphy's Law had full and free reign to torment us to the greatest possible extent, we've overcome all adversity and have actually managed to ship something. This was a totally crazy, intense time, with the recent fullvis problems just being the tip of a particularly large and evil iceberg.

But we got there and it's out.

RMQ Blog Announcement
Download link

Inside3D (Discussion)
QuakeOne (Discussion)

Credit for this one really belongs to the entire RMQ team as a single entity; I think it's fair to say that - especially in the last few days - we had everybody chipping in and doing something to help make sure that it happened. It would be unfair however to not mention GB's mapping marathons as we watched everything come together over successive commits, and the mighty Supa's mastery (mistressy?) of QC, making the creaky old beast flex muscles it never even knew that it had.

All hail!

Thursday, December 23, 2010

Phew!

Now that the veil of secrecy has been lifted, and - all going well - the rest of you will be able to enjoy the end result of this recent work over the next few days, I can talk more about what's been happening recently.

The very first thing you should do is read this: http://kneedeepinthedoomed.wordpress.com/2010/12/23/i-mapping-robot.

OK, the key point here from an engine/tech perspective is GB's comment: "I think we do need detail brushes".

This was a brutal map to fullvis, as you might gather. What's not mentioned (because it's not relevant to GB's post) is that I may very well have fried, or come close to frying, a 2x dual core Xeon box with this one too.

The current situation is that RMQ is hard up against the limits of what Q1 formats can handle. There is another map that is an almost constant battle to keep the number of vertexes below 65536. That one hasn't even been attempted to be fullvised yet.

So something needs to be done, obviously. What is that something? We don't know yet, but we're damn well going to find out. Tech should enable content creators to realise their visions, not embroil them in a constant frustrating struggle.

And that's all for now.

Thursday, December 16, 2010

Even more D3D11

So I'm now at the stage where I'd guess I have sample working code to enable maybe 75% of what's required for a port. I've finally managed to get textures working, and - once again - they've proven to be a hugely overblown monstrosity to create.

The full list of what I've now tested includes render targets, depth buffers, depth state, sampler state, the Effects framework (I'll talk more about that shortly), shaders, vertex buffers, input layouts, dynamic VBO and texture updating.

I've reviewed other state objects and am satisfied that they're no worse (but sadly no better) than those I've tested. I've also reviewed matrixes and have determined that they work more or less identically to those in D3D9.

The D3D11 Effects framework is a strange beast. Microsoft no longer provide a binary implementation of it, so to use it you need to compile it yourself from source (provided with the SDK) and link it with your program. Not that big a deal (it'll fall under the GPL system library exception) but a very strange decision nonetheless.

HLSL without using effects is another option, of course, but I couldn't get textures to work this way (or alternatively, the documentation is incredibly poor and utterly failed to point me in the right direction).

I haven't looked at constant buffers or compute shaders yet; these might be options for another time. Constant buffers seem like they might be useful, but I can't really see how compute shaders could offer anything in a Quake-related context.

The D3D11 paradigm is very much one of fill in a struct (or 2, or 3, or 4), pass that to a create funcion, and then apply the objects created at runtime. This very much front-loads the work at setup/startup time, with actual runtime code being quite light. This confirms my own observations from playing around with the SDK samples - some of them take a very long time to start up, but once they get going they seem to run fast enough (faster than D3D9 in some cases).

So what's the next step? I'm almost motivated enough to try a port, and I like the idea of going back and doing what I had originally done with DirectQ, which is to do a very basic GLQuake port. I'm still undecided about this just now, so it's something I'll sleep on, but - if I do it - it won't be a repeat of last time, where the test port suddenly transforms into the new main codebase. I've definitely seen enough to convince myself that D3D11 is not a viable way forward for a Quake technology project, and that retaining DirectQ at D3D9 is a better decision.

So any port I may decide to do will just be for personal entertainment purposes, nothing else. To ensure that it stays that way, it will probably be Q2 or Q3A rather than Q1, and it may even be released, but that all depends on whether or not I actually do it.

Tuesday, December 14, 2010

More D3D11 Tests

It's been a while since I mentioned this so I just thought I'd update with the current status of my D3D11 tests.

My simple "hello world" application - currently at the stage of putting a coloured triangle on screen - is now up to 450 lines of code (this is with lots of duplicate code from the SDK samples merged and refactored). Recently I went utterly hog-wild and created a depth buffer, the full code for which added almost 100 extra lines to the app.

My initial impressions of D3D11 (and 10, which is almost identical) - i.e. that it's a return to the bad old days of D3D3 all over again - are further reinforced by this experience. Two things here - creating a state object for your current depth/stencil state and creating the depth/stencil buffer itself - are identical in concept (if not in implementation) to execute buffers and DirectDraw surfaces.

Handling all of the different depth/stencil states that Quake requires seems like an - interesting - task. Depth enabled but no write, depth enabled with write, z-fail, z-pass, and all combined with various stencil states too. About 16 in all, each of which needs - say - 20-30 lines of code to set up.

It's almost as if everyone has forgotten what D3D3 was really like. I'd laugh only it's not funny.

Anyway, the upshot of the experience is that DirectQ is definitely going to stay at D3D9, thank you very much. It was a nice idea (and having a definite reason to drop the fixed functionality code would have been good) but it seems as though D3D evolution has taken a rather strange turn lately. What had become a very elegant, functional and easy to use API is now right back at it's ugly roots, and maybe we'll need to wait until D3D15 or so before sanity returns.

Despite that I'm going to plough ahead with the test app and implement textures. At this stage I'm only doing it for a sense of grim satisfaction so there's no real timescale here; I'll update on this particular one as and when I get round to it, which will likely only happen when I'm taken by a peculiar mood.

Sunday, December 5, 2010

Updates for Sunday 5th December 2010 - Experimental Work

As well as actual work in live codebases, sometimes I like to do some experimental stuff. Sometimes this gets released, sometimes it doesn't, but overall it's useful for broadening my knowledge and experience.



This may not look like much but what you're actually looking at is particles generated on the GPU via a geometry shader (OpenGL). I had already made an attempt at this in the RMQ engine which needed to be abandoned as it turned very ugly very fast, but this one seems to work well. I haven't benchmarked it versus textured quads yet, as the GS code is quite crude (it's basically a copy and paste of the original C code); the initial objective was to just get something that worked.

I have to say that the OpenGL documentation here is horrifically poor. I've generally found this to be the case when it comes to shaders, but this particular instance is another level above (or should that be below?)

As soon as I tune it and determine if it's useful for porting to RMQ I'll probably put up a shot of it running in Quake.