Friday, May 11, 2012

Things That Didn't Work

As well as the awesome stuff that does work, I thought it might be interesting to talk a little about areas where I've screwed up.  As well as giving the "tried that, it didn't work" perspective on some things that might become feature requests, as well as offering an explanation for why some things might be the way they are, it's also fun to look at some of the things I've tried that were - in retrospect - plain stupid, trying too hard to be clever or cute, or quite obviously heading for a trainwreck.

It also illustrates some things that might be bad but the alternative is worse.  You'll see....

One past example of this was my early attempts at trying to detect if a player could see through water and allowing r_wateralpha to be set depending on the result.  Edge cases and special cases just kept on mounting up, the whole thing was becoming far too complex, and despite everything it was still fragile and throwing up unwanted failure cases.  There was some wisdom in knowing when to just walk away from something that wasn't working, and it took me a long time to realise it.

Here's another one (the one I promised you'd see) that just came up.

Interpolating Particle Ramp Colours

These are used for some particle effects, and give the result of the particle colour shifting over time with rocket trails and explosions.  In vanilla Quake it's an abrupt shift from one colour to another after a certain amount of time (half a second or so) has passed.

So in a fit of "wouldn't it be cool if..." I decided to try interpolating between the colours.  On paper this looks awesome - it's easy to set up, can be quickly done on the GPU, has no measurable performance overhead, and seems like a subtle but worthwhile visual quality improvement.

In reality however the common case is rocket trails, and rocket trails contain a sudden shift from orange to grey.  When you interpolate those the end result is that these particles spend a small but significant portion of their lifetimes as a rather nasty shade of green.

Yes, GREEN.

There's probably a workable solution in there - something like only interpolating between two colours if they lie on the same row of the Quake palette, otherwise do a sudden shift - but with discretion being the better part of valour, this feature was grabbed by the ears and unceremoniously ripped out.

For now a clear case of accepting second best because a technically better and quite elegant alternative turned out to have completely unwanted consequences.  It's not been the first and I'm sure that it won't be the last.

9 comments:

Spike said...

it must be nice to not be limited to quake's palette.
The rest of us are stuck with brown for everything. :(

ignorant said...

I wonder if colour interpolation would work better if done in a non-RBG colour space? Just a random thought.

ignorant said...

-RGB- meh...

Nick said...

didnt lights have a greenish tone in some older releases. is this related!?

Marty said...

With more thorough testing of DirectQ 1.9.0, I have, with utmost certainty, determined that something in the QRP packs, whether the old ones or the new one, is what was totally crashing Windows XP. I started first with a fresh install by starting only with the vanilla Quake PAK files, tested, then added MP3 music files, then added conback and conchars, Plagues-Weapons.pk3 and QRP_item_textures_v.0.73_dp.pk3. I played all the way through to the end of Grisly Grotto without any crashes.

Marty said...

I tested QRP again both decompressing the textures and also as .PK3's with 1.9.0 and this time it did not crash. Therefore I went back to my original configuration and sure enough, it did crash and rebooted Windows XP again. In other Quake engines I have been able to disable addons by renaming them and not deleting them. for example; renaming the folder textures to textures.bak and qrp-maptextures-2007-10-06r2.pk3.bak. Does DirectQ try to load them both if I just rename them without deleting one or the other? Could this be the cause of the crashes?
Thanks

mhquake said...

You should be able to rename them OK. I'd love to find out what that something was though...

Green light was mainly caused by colours clamping to 255 but HDR lightmaps completely resolve that. They can still clamp in the light tool, but they'll look bad in every engine if so.

Marty said...

I notice that in: QRP_item_textures_v.0.73_dp.pk3, that there are luma textures and .lnk files. Does DirectQ have a problem with luma textures and what are .lnk files? I also notice a Windows thumbs.db in that .pk3 file. In one case I had decompressed the QRP_item_textures_v.0.73_dp.pk3 into a textures folder, in the second case I had just the QRP_item_textures_v.0.73_dp.pk3 in the ID1 folder. DirectQ crashed when I had renamed one of them and left it in the ID1 folder with the extension .bak

negke said...

Odd feature request/suggestion: A cvar that keeps items and monsters at their original coordinates, even if they spawn in bad places (inside solids). This may be helpful in some cases where important items fall out of the map and make it impossible to finish it by regular means.