yeah AABB isn't so accurate for certain situations (mostly glide) and you might not be using it in non-BSP maps, but it's faster.

The problem with ellipsoids is that c_trace and c_move produces a collision Normal that isn't necessarily the surface normal. The normal is taken from the point of the 'ellipsoid' that hits the level geometry, as I can see from the tests. So, when hitting a stair, the edge on the stair step will kick somewhere low in the spheroid, returning a normal that is similar to that of a slope. So, if you code something to stop the entity to go up slopes, it will probably happen the same thing with stairs. And both slopes and stairs are walked up thanks to Glide.

The manual says something about templates using two separate c_move calls, but I couldnt confirm that info. I'm studying the A6 templates right now to see how they do things. But it seems the writers came to the same problems so far

Code:

---

from bipedPhy01.wdl

// use the move_min_z to limit the slope to which the biped can stand on.
// NOTE: REMOVED so we can climb steps
//	if(my._move_min_z__003 >= 0) { move_min_z = min(0.99,(1-my._move_min_z__003)); }    // set the min_z glide value

---

Anyway, I had never thought about using sprite entities as invisible barriers and slopes. And I kinda like the idea now: no portals, no level geometry... no hassles.. oh and I decided to use just a square image and repeat it along the stairs, so I don't need different images with different proportions.

|Emilio|

If you desire a nice 3rd person, satellite camera with perfect, non clipping wall collision and great animation blending(with easier to read/alter code than my version), then go here:

http://www.coniserver.net/ubbthreads/showflat.php/Cat/0/Number/681060/

This is the best 3rd person camera you're going to find for 3DGS. At least, with its default settings it's fantastic. It also features enemy lock-on, as well. If you're familiar with Kingdom Hearts control, you'll appreciate this.

Your blending code works really great. Thank you very much for this contribution.

Perhaps you may find this tip useful if you want to optimize the code further:

You are spending several skills as 'flags', for instance, my.stand_blend and my.run_blend.

You can use bitwise operators to put several 'flags' in a single skill. For instance, if you assign bit values to flags variables or constants. This way you can combine, turn on and off several 'modes' in a single value. Also, this would save several lines of code.


For example:

//define flag constants
define stand_blend,1;
define run_blend,2;
define walk_blend,4;
define idle_blend, 8;
define rturn_blend, 16;
define lturn_blend, 32;
define lstrafe, 64;
define rstrafe, 128;
...

//Only one skill to define if these blends are on or off
define blendmode,skill38;


//Examples of usage:

//To turn ON the run_blend flag use | (bitwise or):
my.blendmode = my.blendmode | run_blend;

//short version
my.blendmode |= run_blend; //equivalent to "my.run_blend = 1";

//To turn OFF the walk_blend flag use ^ (bitwise exclusive or):
my.blendmode ^= walk_blend; //replaces to "my.walk_blend = 0"

//To check if a flag is ON use & (bitwise and)
if (my.blendmode & rturn_blend) //replaces like "if(my.rturn_blend ==1)"
{
//execute this if rturn_blend is included in the flags
}

//Delete all flags:
my.blendmode = 0;

//set several flags on
my.blendmode |= run_blend | walk_blend | idle_blend;

//set several flags off
my.blendmode ^= run_blend | walk_blend | idle_blend;



//Finally, to turn on a single flag and turn off the others:
my.blendmode = run_blend;

//this line replaces:
my.stand_blend = 0;
my.walk_blend = 0;
my.run_blend = 1;
my.idle_blend = 0;
my.rturn_blend = 0;
my.lturn_blend = 0;
my.lstrafe_blend = 0;
my.rstrafe_blend = 0;



The exception is walk_blend that could have a value of 2, but then you could add an extra flag for that.

Bitwise operators are one thing that has always eluded me, however I see the power they possess from your examples.

They are a bit on the 'hardcore' part of coding, but they are very simple if you take a little time to understand them.

Just remembering old concepts:
All values in computers are based on bits (binary), so an 8-bit number is a row of 8 bits. To convert a row of bits to a decimal 'integer', you assign values to each bit. In 8-bit numbers (which can hold an integer from 0 to 256) the values are:

128 64 32 16 8 4 2 1

So there are some numbers (X are 'on' bits, 0 are 'off'):

0 0 0 0 x 0 x 0 = 8+2 = 10

x 0 0 x 0 x 0 x = 128+16+4+1 = 149

0 0 x 0 x 0 0 0 = 32+8 = 40;

So you can see that each number from 0 to 256 is a unique combination of eight ON and OFF bits.


Actually 3DGS makes transparent use of this in its code. For instance if you code:
move_mode = ignore_passable + ignore_me + ignore_sprites;

You are actually adding ON bits to move_mode. If you debug (watch) the values for these flags, you will find that ignore_passable = 4, and others are 1, 2, 8, 16, 32 etc.

Actually it's not 'correct' to use + instead of |.
the | operator is like an add for bitwise values, but it only works once.

For instance:
move_mode = ignore_passable + ignore_me + ignore_passable;

will add '4' twice, actually adding '8', which is another flag. ignore_passable would, in this case, be OFF.

move_mode = ignore_passable | ignore_me | ignore_passable;

this is the same as:
move_mode = ignore_passable | ignore_me;

because a value can't be 'added' twice using |.


The best training for this is to debug or watch certain values in the debugger, or display them on screen. For instance:

x = 128 | 2 ; //x is now '130'

x = 130 | 2 ; //x is still '130'

x = 130 ^ 2; //x is now '128'

x = 128 ^ 2; //x is still '128'.


Last thing: for 16-bit numbers, you just have continue duplicating the values for the bits. So the next 8 'flags' values would be:
256
512
1024
2048
4096
8192
16384
32768
65536

I am not sure how long is a 3dgs value, since it's a generic VAR for holding integers and floats etc. From the values vars can hold, i'd guess they are 32-bits long. But somehow I belive that you should limit to 16-bits (16 'flags' per value).

That's a good explanation. Perhaps, one of these days I'll use it to speed up code that would benefit from the technqiue. Not today, though.

I've updated the "special" version of this contribution. This only includes the camera relative modes. There's a keyboard/mouse combo and a gamepad only mode.

01. Wall collision has been fixed. It's perfect and based off the "Kingdom Hearts" movement thread(see above).

02. There are two different types of camera movements and are also inspired by the Kingdom Hearts thread. The first is just like the one that has always been a part of this package, and the other is a bit smoother and feels looser(the looseness can be adjusted).

03. There are two different types of camera behavior. You can have the Kingdom Heart style where the camera cannot revolve around the player when the player is moving(no matter which direction it is facing), or you can have it like it was before where the camera can revolve around the player while moving. The camera can revolve around the player when it is not moving in both modes. Change the "fControlsLockToggle" VAR to 0 or 1 for the desired behavior. It defaults to 0 which is the KH mode.

04. I've added new VARs and DEFINES to simplify readability.

Code:

---

define typeMouseOrKeyboard,0; //Camera relative mouse/keyboard
define typeGamepad,1; //Camera relative gamepad

var cameraType; //uses the typeNormal and typeSmooth defines
var cameraTypeTemp;
define typeNormal,0; //tight feeling camera
define typeSmooth,1; //looser feeling camera

---

You can manipulate all of this in the loadControlsDefault function in main.wdl

05. The initCameras function and player_action action have been slightly modified to take advantage of the new vars/defines. Within the rest of the functions, all appropriate numbers have been changed to their respective define label for easier readability.


I've started doing the same thing to the larger file with both the character and camera relative modes. However, I'll upload it later and post when it's ready.

http://www.geocities.com/hainesrs/special_blending.zip
http://www.geocities.com/hainesrs/special_blending.rar - same file only half the size of the ZIP