Wednesday, May 19, 2010

Skin Bugs

I've been having a quick look at some skin bugs and running some comparitive tests with other engines to see if I can get some better understanding myself of what's happening.

First up is Warpspasm. Without external textures we get something like this:



Now, I've also tested this one under both DarkPlaces and FitzQuake (latest versions in both cases) and the same happens with them (the above shot is actually Fitz). This one I'm afraid is a content bug rather than an engine bug.

The Quoth pack provides external textures for a certain amount of it's content, which I haven't yet tested (I'm not even certain if this particular model has a texture provided). More news on that one maybe tomorrow.

Second one is the old long-standing bug of player skin colours reverting to default after death. My current theory on this is that it's actually after respawn that it happens, and that the reason why is because the entity number is no longer in the range for clients (and therefore doesn't get a translated skin). If this is correct it should also happen with GLQuake, in which case it's a 50/50 toss-up between whether it's intended behaviour or whether it's a bug in GLQuake that it's desirable to fix. A cross-check with software Quake should confirm, but in any event I'm leaning towards it being desirable (for me, at least) to fix.

One difficulty I can see is that if the entity number does change, some method of saying "hey! new entity here! inherit some properties from an old one (which no longer exists) please!" will need to be devised.

Once again, software Quake may very well have an easy solution to this, otherwise there might be something I can adapt from one of the major multiplayer engines. If neither of those are the case it could well get ugly.

That will probably also get some investigation tomorrow.

====== UPDATE 1 ======

I've now tested the Warpspasm bug in Fitz, DarkPlaces and Aguirre's engine and in all of them we get the same problem. This one is definitely a content bug.

The skin change bug doesn't happen in Software Quake (I've also confirmed that it's an inherited GLQuake bug). This is good news as it means that there is a fix somewhere to be had, and also that it's intended original Quake behaviour that the skin colour stay after respawn. I hate inherited GLQuake bugs where you can never be certain if the "bug" is an intended code change or just an omission in GLQuake. Thankfully there is Software Quake to fall back on as the final arbiter of the way things should be.

Of course, those who subscribe to The Great Gods Of GLQuake will always insist that any different GLQuake behaviour is somehow "more correct", but it's a big world and there's room for all kinds of people in it.

====== UPDATE 2 ======

Player skins are now properly fixed. As a bonus I was also able to clean out a lot of legacy skin translation code (there's more to go, but not too much) and make a more robust and general version of the skin translation code. God, GLQuake really did suck badly...

5 comments:

=peg= said...

"Second one is the old long-standing bug of player skin colours reverting to default after death. My current theory on this is that it's actually after respawn that it happens.."

I can pretty much confirm this. In fact, when playing online, the change in skin colour on a dead body is a clear indication that the player has respawned. This can actually be very vital information in teamgames or for avoiding getting spawn-fragged by the phoenix rune in RuneQuake :D

"It's not a bug, it's a feature!"

Pottenham said...

mhquake said:"God, GLQuake really did suck badly..."


Thank God we have the planets most brillant Quake-Engine-Programmer on our side to clean this mess up.

Man,what you´re doing here is not only good or nice,it´s fantastic.
Thanx

Nyarlathotep said...

I can't certify who the best programmer in the Quake community is, but I'll assert that I wish FitzQuake were updated with your tenacity and discipline. Well done!

And yes, it's a miracle that GLQuake works as well as it does...

mhquake said...

For what it's worth I don't believe I'm anywhere near the best, but I appreciate the compliment. :)

There are some very valid reasons for doing a slower update cycle, especially as a project matures, and even more especially as more features are required to justify a new release. I have enormous respect for FitzQuake, possibly moreso than any other engine, and while sometimes I might compare it unfavourably to DirectQ that's just because I see it as the standard I have to work towards (and sometimes maybe even beat!)

At the same time I don't see this as being any kind of competition; I've certainly borrowed code from Fitz, and I know I'm credited in the Fitz readme, so the mixing of ideas from different people is definitely working to the advantage of everyone in the community.

Long may it continue!

Pottenham said...

Well,i´m just an experienced Quake-Player and the only thing that i can judge is "how the engine feels while playing".

The most important things that i need in a Quake-Engine are Compatibility,texture & mdl-Support,music from HD and above all smooth Gameplay/Performance.

Concerning these points DirectQ is clearly THE BEST or will be when the next Release is out (mdl textures).