Tuesday, November 30, 2010

Updates for Monday 29th November 2010

Not much to say this time, just been ploughing ahead with bugfixes, minor changes, nips and tucks, and so on. Some of the bigger ones are:

BSP models are now properly lit. This is optional (of course) as in some maps they're not really intended to be. RMQ is moving to MDL for most of these, but there are still a few cases where BSP comes in handy (it can also bring the number of verts in a map - and vis times - down a bit).

The Save/Load menus have been overhauled a bit more. They now only show the actual saves you've made, with one empty slot at the top for new saves, and are capable of showing any save irrespective of it's name. There will be a few exceptions to that last one for RMQ as it does checkpoint saves during a map and autosaves when you enter a map.

Some MDL skin bugs have been fixed. These caused a little bit of trouble as the original code didn't support external MDL skins, and they needed to be made work seamlessly with texture padding and in cases where not all skins in the model have an external replacement.

Some parts of the code have gained some more speed; one example is the mini-coronas drawn on dynamic lights.

Regarding cvars and defaults, for DirectQ I've been setting cvar defaults to more or less the same as what GLQuake (and WinQuake, where appropriate) did, but for RMQ I'm of the opinion that - as the engine is being specifically made for the mod - I can set the defaults to what the content creators wish to have in the mod. This means that in some places the engine won't have an absolutely "pure" GLQuake look, but then again it's not meant to.

Till next time!

Wednesday, November 17, 2010

RMQ Engine Test Release - 17th November 2010

Here it is folks.

RMQEngine-2010-11-17-Test.zip.

Please read the readme, it explains a lot about the purpose of this release and contains other important info you'll need to know (especially if you want to use it on Linux).

Monday, November 15, 2010

BengtLightColoured R2 is Out

Get it here.

The delay on this one has proven to be fortunate as there were some last-minute bugs in it that needed fixing, and would have necessitated a third release otherwise.

Friday, November 12, 2010

DirectQ Update - 12th November 2010

It's been a while so I figure you're entitled to know where DirectQ 1.8.7 is currently at.

The important thing first-up is that I'll release it as soon as I'm happy that it's ready. That's always been the case and there's never been any reason to change that approach.

However, I'm not happy that it's ready yet. The past coupla weeks I've been playing catch-up a little on the RMQ side of things, because it's also important to fulfil my obligations there.

What would be really neat is to actually do both releases at the same time, but that's a "nice to have" thing rather than something I'll bust myself to have happen.

Overall it's reasonably stable and solid, with performance back up to where it should be, but there is one thing that still manages to drag framerates way down that I haven't been able to track down yet. However, things are now settling well on the RMQ side, so I'll get the chance to do some investigation over the weekend.

If I was to release it now, that one thing would be a problem for you, and that's not fair on you.

Wednesday, November 10, 2010

Bug Hunting!

I'd hoped to get stuff released by now, but have been distracted for the past while by an annoying RMQ bug that only happens under a very specific and unlikely set of circumstances. Normally in cases like this I'd be inclined to give the same answer that the doctor gave to the guy who said "it hurts every time I do this", but in this case it indicates something not quite right in a fairly important subsystem, so I need to invest the time and effort in chasing it down and squashing it.

I'll probably take some time tomorrow - even if I don't fix it - to package up and release the coloured lighting tool. That'll be tomorrow evening, and my time zone is GMT.

Till then.

___________________________

Update - Didn't get the chance to do anything today with more bug hunting. Think I've finally fixed it now though, so I'm just waiting on confirmation. It'll be at least tomorrow before I can release the light tool at this stage though.

Sunday, November 7, 2010

MHColour 2010 is Released

Get it here.

This release fixes a bug that prevented some people from being able to add BSP or PAK files to the list view. I've also updated the project files to Visual C++ 2008 and adjusted the .rc file to compile on the Express version.

No other changes have been made (wait for MHColour 2011!)

Saturday, November 6, 2010

More Coloured Light

I've been doing some work on the light tool, just fixing more bugs/omissions and working on the display output. For the latter, an unfortunate aspect of the original code is that it assumes linear execution of the lighting function. Moving it to parallel execution brings some interesting decisions to the table...

After experimenting with various options I've eventually settled on displaying progress separately for each thread. This does mean that the output is going to be considerably more verbose than the original (8 threads gives 8 times the output) but at least it's now accurate on a per-thread level, and allows you to track progress of each thread individually, which is cool.

I'm resigned to the fact that whatever I do with this is going to make somebody somewhere deeply unhappy, but in the end I think erring on the side of not messing with the original code too much is the right way to go, and this way lets me retain it largely intact.

Hopefully this release 2 will be out over the next few days.

____________________________


Speaking of releases, the RMQ engine pre-release should also be out roundabout the same time.

Thursday, November 4, 2010

Coloured Light Update

There's going to be a Release 2 of the coloured light tool based on feedback, comments and requests. Some problems with the first version include no sunlight colour support, the "press any key" message at the end, and the messed-up timer output.

In some cases the problem comes from insufficient information on my part, in others it comes from the Visual C++ 2008 compiler not playing nice with the original code (or should that be the other way around?), and in others it comes from debug code that should not have been in the release version.

I can put my hand in the air and accept responsibility for those that are my own doing, but it's more positive to move forward and fix these things. Software doesn't spring fully-armed from the head of Zeus, you know.

So anyway, this is now built and tested, but I'm holding off for a little in case anything else it needs springs to mind. The great thing about standards in Quake is that there are so many of them, and I do want Release 2 to be the last one, so if there's any extra behaviour it needs to get (like support for colours on more than 1 sunlight - is it needed? is it expected? what the hell is the standard anyway?) I need to know.

Bottom line is that I can't maintain this going forward, I'm not a tools guy, it was originally just an experiment that tickled my curiosity the right way, and I'm already busy enough with other stuff.

RMQ Support - Implementation Notes

Just been crushing some ATI bugs lately; their OpenGL driver still sucks. Well, it doesn't really suck, but in general it's the case that if you can't do something in D3D then you really shouldn't try to do it with ATI.

Meanwhile, here's some notes I've been putting together regarding requirements for running RMQ stuff. The engine pre-release is still on track for some time next week, and there will likely be an updated version of these notes included with it. These are just to give anyone who's interested in adding support a head-start.

____________________________


Without saying too much about stuff that hasn't been publicly released....................

What's been released in the 2 demos so far is only the very small tip of a very large iceberg, and really doesn't indicate in any way the full extent of what's going on.

What RMQ really needs most right now is big map support. This is absolutely mandatory and engines that don't have it will fail to load most RMQ maps. There is as-yet unreleased content that is right on the absolute maximum limits for some items so this needs to be robust and comprehensive. Think warpc and then ramp it up some.

A few DP extensions will be used but will not be absolutely required (yet, at least). Supporting them will make the game better though. DP_QC_STRFTIME is used on occasion but nothing will break if you don't have it. DP_SV_CLIENTCAMERA (not called by name in the DP source! search for clientcamera) may be needed later, but not until after the next demo is out. FRIK_FILE has been asked for and the engine has it now but it's not used yet. There may be more.

Alpha-masked texture (what I've been calling "fence textures") support isn't necessary but these textures are used in maps and they'll look better with it. They only need to be supported on brush models.

Alpha surfaces will be needed; I don't think there's any in the upcoming demo map, but they are used elsewhere. Sorting these by model is not enough, they need to be sorted by surface for RMQ.

Fast handling of sprites would be a very nice thing to have.

There's going to be a lot of horde combat and big open areas with complex geometry. Anything that renders these fast is good. DirectQ has a R_RecursiveWorldNode replacement that uses maybe 5% the CPU that ID Quake's does, so that might help (it's easily adaptable to C and doubled framerates in some places when ported to the RMQ engine).

If the maps which have already been released crush an engine then it doesn't stand a chance with the rest of this stuff. If the maps which have already been released run slowly on an engine then the rest of this stuff will crush it.

Worst-case polycounts so far were about 20,000 epoly and 30,000 wpoly, but this was on a fast-vised map. The RMQ engine can handle these counts (as well as everything else going on - sound, server, etc) at maybe 50-60 FPS on my NVIDIA GT230M so this is the kind of performance to be shooting for. Released content won't be this bad of course, so consider this an absolute upper limit.

The current QC is quite CPU-heavy; anything at all that can be done to optimize that is a good thing.

Full rotating brush model support is required. I don't think the "flicker fix" (look on Inside3D) is needed yet, but it will be in the future.

The map in the next demo will have a lot of dynamic lights and animated lightstyles by Quake standards. These are actually a quite essential part of the atmosphere, but even so, they're nowhere near as many as are present in unreleased maps. Work on the assumption that every surface in a scene is going to be dynamically lit (and there will be a lot of surfaces - the screenshots here give a good idea of the kind of complexity I mean). Fast dynamic lightmap updates are an absolute must.

Static entities, temp entities and beams limits all need to be increased. The RMQ engine effectively supports an "infinite" number of these (as in "until you run out of memory") so I can't give counts right now.

Skyboxes, fog and coloured light should be more or less standard by now. The FitzQuake fog standard is the fog implementation of choice and will give the intended result. Content will run without them, but you won't be seeing it the way the creators intend.

Lava and slime textures are intended to glow through fog.

The maps are designed with fullbright colours and overbright lighting in mind, so certain areas might look wrong if an engine doesn't support these.

The RMQ protocol is basically just the FitzQuake protocol with some minor modifications (angles and coords are transmitted as full floats); this may be changed more further down the line. Implementing the FitzQuake protocol now will be a good idea.

No CSQC requirements yet and the engine doesn't have it yet.

____________________________


That's about it so far.

Wednesday, November 3, 2010

Light tool is Released!

Get it here.

OK, it's successfully compiled the largest RMQ map and so is now publicly released. Have fun.

Tuesday, November 2, 2010

Updates for Tuesday 2nd November 2010

Some bug fixing in RMQ. Once again OpenGL vertex buffers are a total pain; I much prefer the D3D approach where it either works or it doesn't, and if it doesn't work it explodes in your face. At least you know where you stand with that, and don't need to spend time tracking down mysterious nonsense.

For now RMQ will be running without vertex buffers. I'll probably go back and fix it sometime, but the priority is correct operation. Performance-wise there's not much in the difference, but it'll most likely fall a little on particles and scenes where there's heavy use of MDLs.

I'll probably put a pre-release of the engine out sometime within the next week so that people can bash at it and try to uncover more bugs and the like.

For giggles I took some time out to hack coloured lighting (and LIT file support) into Bengt Jardrup's light tool. This took maybe an hour or so to get the basics done, and another hour of testing and bug fixing, so it's quite experimental at the moment.

I also multi-threaded it properly, and did some 8-thread test runs; very fast, even at -extra4.

Right now the code is Windows only; it would be really great if this could be ported and brought up to date with any fixes or changes made by others. I can't really do that myself as I'm Linux-less again for the moment, and also am quite rusty on the tools side of things. Maybe the fact that it exists will be enough to encourage someone else?

I'll likely release this one soon-ish (within a day or so).

Monday, November 1, 2010

Updates for Monday 1st November 2010

It's looking like the required extensions for RMQ (so far at least) are going to be DP_QC_STRFTIME, DP_SV_CLIENTCAMERA and possibly FRIK_FILE. For the most part it should run without crashing if you don't have these available, but having them will give the best experience.

DirectQ just got another 20% speedup; it's now timedemoing at twice the speed that it was 4 or 5 days ago, and has pulled well ahead of all previous releases.

More soon.