Wall-walking code improvement...

[WolfWings]

Using a combination of re-working the code Madness released for 'wall-walking' that was from the Tremulous mod according to their website, and other resources I've gathered from around the `Net, I modified the 'wall-walking' component to only use a single 16-bit value, which it currently stores in the 'stats' array of the player structure.

I'd post the code here to the forum, but I'm unsure of the best format to post it in, since it touches the width and depth of the original 'wall-walking' code Madness posted. Basically, it 'compresses' the gravity vector to a single 16-bit integer, and stores that each frame. The compression is the neat trick, and one I improved on slightly from another source on-line that I don't recall, possibly MathWorld or GamaSutra. So, should I just post URL's to the .c replacements, or is there a preffered format for this sort of information?

[Timbo]

Well it's interesting to see another mod using bits of my code. Another instance of my not actually being aware of it's usage until having it specifically pointed out :smile:

Anyway, I'm not exactly clear what you've done. Am I right in saying you've effectively bitpacked the surface normal and maybe WW flags into a STAT_ index?

In any case, tma@op.ath.cx me the code and i'll look into importing it into CVS if it makes sense to do so...

Thanks.

[WolfWings]

Yes, that's correct. It's hard to explain without just posting scads of code, but yes, I have a version of the wallwalking code that moves all the 'wallwalking' information into a single 16-bit STAT_ROTATION entry. It still works well, just the gravity vector only has about 5 degrees of precision, instead of near-infinite with the grapplePoint method. (Rough calculation, it's actually a little better.)

I'd actually been working on wallwalking code of my own for a while, and getting some of the final view-rotation problems was my sticking point which you folks solved well, though staircases still cause the movement code fits I noticed, since you're not doing the 'stairstep' movement check, at least the code from Madness doesn't include a wallwalking + stairstep combined movement function. I'll e-mail off the code this afternoon, is just a full archive acceptable, only the modified files, or only a linux-style 'diff' between the Madness code?

[Timbo]

On 2002-01-01 16:52, WolfWings wrote:
Yes, that's correct. It's hard to explain without just posting scads of code, but yes, I have a version of the wallwalking code that moves all the 'wallwalking' information into a single 16-bit STAT_ROTATION entry. It still works well, just the gravity vector only has about 5 degrees of precision, instead of near-infinite with the grapplePoint method. (Rough calculation, it's actually a little better.)

Ah ok, that's what I figured. I'm really pretty ambivalent to each method of packing the data - the reason I chose the way I did was because I foresaw STAT_ indices being at a premium and since I wasn't planning on using grapplePoint for anything else it seemed a good option.

I'd actually been working on wallwalking code of my own for a while, and getting some of the final view-rotation problems was my sticking point which you folks solved well,

Yeah this is what took most time :smile:

though staircases still cause the movement code fits I noticed, since you're not doing the 'stairstep' movement check,

If you have any bright ideas regarding this, don't hesitate to tell me :wink:

at least the code from Madness doesn't include a wallwalking + stairstep combined movement function.

I'm a little confused about the whole madness situation. They are providing for download what is more or less a verbatim copy of the mini mod I released on the Tremulous page a few weeks back minus the licensing information and curiously the source code - but you seem to have got it from someone other than I. I also noticed in their forum some "interesting" accusations from the Q3F team. Who knows - in any case I've mailed them asking where the source is... If you want a copy of my source repository you can checkout the "wallwalk" module from anonymous CVS. Access details are on the project page (http://sourceforge.net/projects/tremulous).

I'll e-mail off the code this afternoon, is just a full archive acceptable, only the modified files, or only a linux-style 'diff' between the Madness code?

Just a full archive will do. I'm interested to see what you've done with it.

[WolfWings]

Actually, I haven't done much work with the actual 'stair-stepping' problem myself either yet. The severe lack of a 'rotated box check' functions in the server-side function-list is the main obstacle, as I'm sure you know. Surprisingly, there's readily-available rotated-box AND rotated-squashed-sphere collision check code in the CGAME functions, but they're not exposed to the GAME side of things. Erf. Might end up implementing my own version for the server-side that works similair to the approach Unlagged takes, rotating the entire world to fit the fixed-axis box, check, then rotate back.

And I may have found some link on the Madness site that pointed into the Sourceforge CVS listing and downloaded the directory from there, I'm not sure.

In either case, I'll e-mail you the URL to the codebase I have, which might look a little different than the 'stock' Quake3 codebase.

I use a slightly modified directory structure that allows for using the TA UI script, and removes the 'forced' seperation between the GAME and CGAME directories, so it's easier to search the 'main' codebase faster with command-line tools, as I don't have a copy of Visual C or anything similair to use.

[WolfWings]

Oh, BTW, there's nothing stopping you from moving the STAT_ROTATION to a PW_ROTATION or even an AMMO_ROTATION entry. :smile:

Actually, those four arrays are actually all 16-bit integers, and all quite capable of being packed together into one single 128-byte area to use as you want. I've got some code for treating them as such, and it works fine, though some care in selecting packing of, say, bytes or bits, can help with network traffic issues, since the 16-bit 'words' are what are transmitted, with a 16-bit 'mask' of each group of four to indicate each 'word' to be transmitted. Hard to explain, easy to show on paper. :smile:

[Timbo]

On 2002-01-01 18:40, WolfWings wrote:
And I may have found some link on the Madness site that pointed into the Sourceforge CVS listing and downloaded the directory from there, I'm not sure.

I mailed the guy about providing the source - he now provided the source albeit minus all the licensing information and who wrote it in the first place. They seem to like taking credit for other people's work - checkout their stealage of the Q3F flamethrower in the forums. I don't really care all that much, just seems a little dishonourable of them...

In either case, I'll e-mail you the URL to the codebase I have, which might look a little different than the 'stock' Quake3
codebase.

Yeah got it - I'll check it out later today.

faster with command-line tools, as I don't have a copy of Visual C or anything similair to use.

vim+ctags+grep :wink: - all you'll ever need.

Actually, those four arrays are actually all 16-bit integers, and all quite capable of being packed together into one single 128-byte area to use as you want.

Yes the STAT_ indices are a common solution to many problems brought up on the Quake3World Programming forum, which I moderate.

[Timbo]

I took a look at the changes you've made. I can see the thinking behind using a STAT_ indice if you need grapplePoint for something else, but it doesn't make sense for Tremulous.

Tremulous doesn't use grapplePoint for anything else so by using a STAT_ all you're doing is losing precision, although admittedly you're saving a little net bandwidth. The stats array in Tremulous is almost full. Vanilla Q3A doesn't actually use grapplePoint either. The only reason I can see for packing into stats is if you need the extra precision from grapplePoint for something else.

With regards to the comment I made about having extra variables. What I really meant here was it would be nice if there was another vec3_t in the ps struct to store the rotation axis (yes i could use a STAT_ :wink:). At present the rotation axis is not stored at all since it is implied from the ground normal and surface normal for all surfaces except the ceiling where the ceiling and ground normals are colinear so the rotation axis is undefined. In this case grapplePoint stores the rotation axis, not the surface normal. This is a bit clumsy and could be avoided by storing the two values separately. In hindsight however, this method is more net efficient despite being harder to work with.

In UpdateViewAngles when I say the rotations could be performed more efficiently I don't mean through the use of a more efficient rotation function (which incidentally I am using in the main Tremulous code base, but forgot to copy into wallwalk). Rather I meant a single rotation can be performed on one vector and the other vectors of the axis can be calculated using x product. This would be considerably more efficient than rotating each vector of the axis individually no matter how optimal the rotation function. I'll improve that eventually...

So anyway, thanks for your contribution - while it's not really applicable to Tremulous, it makes a lot of sense if you need grapplePoint for other purposes.

[WolfWings]

That's fine with me. :smile:

At my end, I'm part of the MadLogic team, and we were initially trying to build a wall-walking codebase that could be easilly integrated as an SDK into multiple other mods, which was the basis for trying to avoid using any 'one of a kind' value areas such as the grapplePoint entry.

And actually, I never got around to finishing the 'optimized' Rotation code. *laughs* The code in there I meant to cut-and-delete, but just left commented out by mistake. :smile: It doesn't work right yet, even. :razz:

Still, good luck with Tremulous. I'll definately be one of the first ones downloading it when it's out!

And I still don't get your 'gripe' of not having enough STAT indices? STAT, PW, AMMO, even PERS are all interchangable, though admitedly in the 'base' Q3A codebase PERS isn't cleared on respawn, and the others are. They're all 16-bit integers that are passed back and forth to/from the client. :smile:

Sorry, I'm rambling, I guess I just don't see how you can be running out of space to store stuff if there's 96 bytes of general-purpose storage between client/server and another 32 bytes that aren't cleared on respawn. :smile:

[Timbo]

On 2002-01-05 16:36, WolfWings wrote:
At my end, I'm part of the MadLogic team, and we were initially trying to build a wall-walking codebase that could be easilly integrated as an SDK into multiple other mods, which was the basis for trying to avoid using any 'one of a kind' value areas such as the grapplePoint entry.

I hope you realise that the wall walking code is licensed under the OSML - a GPL alike license for game modifications. Essentially meaning any modification that uses this code must also be open source under the OSML.

And I still don't get your 'gripe' of not having enough STAT indices? STAT, PW, AMMO, even PERS are all interchangable, though admitedly in the 'base' Q3A codebase PERS isn't cleared on respawn, and the others are. They're all 16-bit integers that are passed back and forth to/from the client. :smile:

I don't really have any major gripe to be honest. I don't have any issues with the amount of usable space, rather the form it is in. I would much prefer a set of generic variables in the ps struct for use by mod makers since they are a lot easier to work with. Since net data is delta compressed I would have thought this was the best plan of action. I realise you could easily build a wrapper around the existing ps arrays to provide essentially the same thing - but it isn't as neat or convinient as simply having the variables in the struct.

[BLOODRAIN]

shit.

[Timbo]

On 2002-01-24 09:16, BLOODRAIN wrote:
shit.

huh?

[Saig]

Hes just saying that because he doesnt have a clue what you and Wolf are talking about Timbo. Fried his brain!@! Oh and I dont understand either. Continue on...