Animation frames blending, player input/physics

Posted By: Orange Brat

Animation frames blending, player input/physics - 02/21/06 06:25

This provides a couple different types of player movement...camera relative(keyboard or gamepad modes only...for Splinter Cell style satellite camera movement) and character relative. It also can be used with either a gamepad, keyboard only, or a mouse/keyboard combo. It also smoothly blends the player's bones animation states between one another. In other words, the transition from a standing animation to a run is smooth and not sudden. It's coded to handle idle, stand, walk, run, left turn, and right turn. It also plays a footstep sound for both walking and running.

Note that there is no camera provided, although it does require the default "camera" when using camera relative modes.

The various sensitivities, keyboard assignments, and the movement type(gamepad, keyboard, mouse/keyboard, camera/character relative) should be changed in the the "loadControlsDefault" function and not with the VAR itself. This function is the first thing that gets called, and all of the default values are handled within it. It then calls the "setKeys" function which uses "miscinput.wdl". The "hit.wav" from one of the template folders is also used as a placeholder for the footstep sounds. Make sure it is in your project folder or in your path somewhere.

This is somewhat complicated looking, but it really isn't if you understand your C-script. There's a simple player action at the end to demonstrate how to call these functions. Sorry for the minimal comments, but you shouldn't have too much trouble figuring it out. There's quite a bit of commented out code in a couple of the functions. I'm not using that, for now, but you can do whatever you want with it. I don't know if uncommenting it will break the system, though.

Credit to Pappenheimer/Gnometech for the environment/calculating functions. I've modified/simplified it a bit, but the soul of their work is still there. Credit to whoever helped me on the blending/animation function. Credit to Doug for the misc input file. It's required to set up/assign controls/keys.

Get the code below and read on further into this thread for usage instructions and updates/progress log:

http://www.geocities.com/hainesrs/blending.zip
http://www.geocities.com/hainesrs/blending.rar - same thing, just half the file size.
Posted By: FeiHongJr

Re: Animation frames blending, player input/physics - 02/21/06 09:30

very nice contribution thanks alot Cant wait to give it a try.
Posted By: Lion_Ts

Re: Animation frames blending, player input/physics - 02/21/06 22:39

Thank you, Orange Brat !
For what slope calculations was commented in environmentForces() ?
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 02/22/06 02:35

I think it just controlled the way the player interacted with sloped level surfaces. The original version was much longer than this and included code for jumping, falling, dying, and terrain, too.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 02/22/06 15:46

I'll release a demo showcasing this code a little bit later on. It's 9:45am right now, and it probably won't be until after 7pm before I can start on it. These features have been requested many times, so I hope it helps those who stumble across it.

@Lion_TS: Check your PMs.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 02/23/06 05:43

Here's the DEMO. I integrated a 3rd person camera to showcase the code, since it wouldn't make any sense to use it in first person.

http://www.geocities.com/hainesrs/blending.rar - 380kb

OR

http://www.geocities.com/hainesrs/blending.zip - 718kb

The animation states blending will be obvious, so I don't need to explain it. However, the various movement/control modes need to be addressed, so you'll know how each value influences the camera and controls.

The VAR "movementType" has 5 possible settings: 0, 1, 2, 3, and 4. The default is "0". To change this value, find the function named "loadControlsDefault" located in "main.wdl". Simply change the value to one of the five listed above.

Here's what each one will do for you.

movementType
0 = This is a standard behind the player, 3rd person camera and is controlled with the mouse. The player moves relative to itself using W and S, and strafing is not yet implemented. This is most like the controls and camera used in Max Payne.
1 = This is a standard satellite style, 3rd person camera and is controlled with the mouse. The player moves relative to itself using WASD and would best be compared with the early Resident Evil play mechanics(i.e. tank controls).
2 = This is a standard satellite style, 3rd person camera and is controlled with the mouse. The player moves relative to itself using the gamepad.
3 = This is a standard satellite style, 3rd person camera and is controlled with the mouse. The player moves relative to the camera using WASD. This is most like the controls and camera used in Splinter Cell.
4 = This is a standard satellite style, 3rd person camera and is controlled with the mouse. The player moves relative to the camera using the gamepad. This is most like the controls and camera used in Splinter Cell.

Please note that in gamepad mode the camera should ideally be controlled with the 2nd analog stick or some other button on the input device. However, this feature is not yet implemented, so you'll have to settle for the mouse. It isn't very practical, but I'm not going to fix it anytime soon. This is valid for movementTypes 2 and 4 only.

Finally, when in modes 3 and 4 there is an animation frame problem with the "idle" and "stand" states. The way it is scripted, now, the player's state will change to its idle animation after about 8 seconds of inactivity. This works as it should with modes 0-2, but it does not function in the other two. Also, the stand state does not occur when not moving. This used to work, so I must have broke something when I was actively working on this and forgot to go back and fix it.
Posted By: Lion_Ts

Re: Animation frames blending, player input/physic - 02/24/06 23:57

Thank you for demo, better one time to see than 10 times to hear.
Good code for me.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/01/06 08:32

Just a quick heads up to let everyone who used this or has an interest in it that I'm working on it again. I've ironed out most of the "bugs" or incomplete parts addressed in my last post. I'm just trying to polish it up and trying out a few other ideas. I'll post again when I upload the new version and will post the changes, as well.

So, don't download the files that are there for now.
Posted By: DavidLancaster

Re: Animation frames blending, player input/physic - 07/01/06 12:36

Hey this is a pretty awesome contribution! I'm really surprised that there's only been so few replies though...
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/02/06 05:31

Maybe it's because of my longwinded, convoluted explanations or something. That's the reason for the demo. Full blown, working animation blending is rare in 3DGS projects but common place in realworld, professional games. It's essential if you want to release something commercial that is both polished and professional and if you want to be taken seriously.

Anyway, I'm getting close to the new release.
Posted By: Lion_Ts

Re: Animation frames blending, player input/physic - 07/02/06 16:46

AxysPhenomenon, few replies in this thread because of ... nothing to say
Orange Brat's contribution really good, pro and 'must have' for solid looking game project. I have to say: many thanks again, nice to hear about new release.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/05/06 13:12

No "praise" necessary.

UPDATE: Getting much closer. I have a couple of bugs to deal with on one of the gamepad modes(#2) and some kind of other gamepad bug pertaining to both modes 2 and 4, however that one can be easily dealt with. The former may just need to be left as is and someone can figure out on their own.

Another possible problem is adding a "strafing" mode to the animation.wdl. I've created the appropriate VARs and DEFINEs and placed them where they need to go in the script file, however I haven't added the large chunk of code that will allow the player's strafing animations to cycle and/or blend when the conditions are met(and it's only relevent to mode 0..Max Payne style camera). Again, I might leave it as is for someone else to deal with.

My game uses fixed point and/or cinematic sweeping cameras ala Ankh, Bone, Broken Sword III, Eternal Darkness, Clock Tower 3, and Resident Evil: Code Veronica, so these issue aren't really too much of a bother for me. However all or most of the bugs/omissions I mentioned a couple posts back are squashed or added, so that's some good news. I've also improved/optimised and/or streamlined a few other preexisting components, as well. I'll tinker with this sorry, bloody bastard a bit more over the next day or so and post it when I feel it's ready.

...TTYL...
Posted By: Lion_Ts

Re: Animation frames blending, player input/physic - 07/05/06 22:40

No praise necessary because of it's beyond praise ?
Thank You anyway.
Posted By: PHeMoX

Re: Animation frames blending, player input/physic - 07/05/06 23:03

Thanks for sharing!

Please let us know when the updated version of this demo is finished because the files at geocities are gone already, which is okey, but I would be interested to see how you've coded those different camera types and like to see them in action.

Again, thanks!

Cheers
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/06/06 00:27

I took them down because I didn't want users d/ling the old version. I'll try to get something uploaded later on whether I iron out that one stupid bug or not. I do want to try and stomp one of them that I think I can handle, but the other one is just going to have to wait. It won't matter for The Disenfranchised since my cameras aren't free form look anywhere types, but for general purpose usage, it may be a nuisance for users who like to use a character relative based movement wtih their gamepad.

EDIT: Bah, the hell with it. I'm out of the house most of the night, and I'll deal with it all later, so I've uploaded it. It's defaulted to mode 3 which is camera relative movement with keyboard and mouse. Mouse moves the camera, WASD moves the player relative to the camera angle. I believe the arrow keys can also manipulate the camera. I have imposed no limits so using both the mouse and the keyboard controls at the same time will in essence double the force(s).

http://www.geocities.com/hainesrs/blending.zip
http://www.geocities.com/hainesrs/blending.rar

If you want to change movement modes and default controls then you have to do it in the last function in the "main.wdl"

Code:

function loadControlsDefault()
{
mouseSensitivity = 15;
joySensitivity = 15;
keyCameraSensitivity = 15;
keyPlayerSensitivity = 15;
movementType = 3;
str_cpy(fw_key, "W");
str_cpy(bw_key, "S");
str_cpy(tl_key, "A");
str_cpy(tr_key, "D");
str_cpy(tcl_key, "cul");
str_cpy(tcr_key, "cur");
str_cpy(tcu_key, "cuu");
str_cpy(tcd_key, "cud");
str_cpy(run_key, "shiftl");
str_cpy(action1_key, "mouse_left");
str_cpy(action2_key, "mouse_right");
setKeys();
}



Of course, I have a more complicated INI DLL I/O system in place, so I can change these per end user inputs from an options screen. I use this one for that:

http://www.geocities.com/hainesrs/ini.zip
Posted By: Kotakide

Re: Animation frames blending, player input/physic - 07/07/06 03:16

it's great movement, and blending.
I wonder, what might be happen if this movement code combined with anti-clipping camera (axys style camera code),
it will be absolutely FLAWLESS!

I'll just sit and wait..
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/09/06 07:16

My next step is going to be integrating that Zelda code wall avoidance into my cam.wdl for this system. Wish me luck because the Zelda code is a mess to the naked eye. After that, I'll try and deal with those pesky Gamepad mode quirks and whatever else I feel is necessary. I might look into implementing a limits system to address the issue raised last post.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/09/06 09:10

Another new version uploaded that fixes the easy to fix gamepad camera bug. Fixing this also added in a limits system just by the very nature of how the code is constructed, so that's a nice bonus.

The animation left turn/right turn frames bug for mode 2 is still present, however that is a more complicated matter. I might just ignore it given both mode 2 and mode 1(the keyboard only equivalent to the gamepad only mode 2) are worthless control schemes IMHO. This "bug" isn't really that big of a deal...just a matter of a bit of a lack of polish. I actually fixed it in mode 1 but working with gamepads is a weird little world.

http://www.geocities.com/hainesrs/blending.zip
http://www.geocities.com/hainesrs/blending.rar

I also added a new var called "joyDeadZone." This is the value used to determine your gamepad's dead zone so you don't get undesirable results when not moving your joysticks. It's defaulted to a joy_raw value fo 55 out of 255. All other defaults are the same as mentioned a couple posts back. Oh yes, and I think I neglected to mention that the analog joysticks are touch sensitive. If you barely press them the player walks, if you press them all the way it runs.
Posted By: Wiz

Re: Animation frames blending, player input/physic - 07/10/06 13:49

Looking good. Always nice to see how other people do things, and learn from that. I have already seen a few things in this code I will copy in my future projects. I will try it out when I come home.
Posted By: Kotakide

Re: Animation frames blending, player input/physic - 07/11/06 05:38

Quote:

Wish me luck because the Zelda code is a mess to the naked eye.



you'r absolutely right!!!
I,m kidding, david

well, good luck and I'll wait the result.
Posted By: DavidLancaster

Re: Animation frames blending, player input/physic - 07/11/06 08:10

I even get lost and confused looking at the zelda code

PM me if you need any help integrating that camera orange_brat, fyi it's controlled in the pan_back function.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/11/06 10:39

I recall pinpointing the code a few months/weeks ago, but I'll have to jump back in. If you could possibly PM me the exact lines that handle wall collision/avoidance I'd appreciate it. I'm in no hurry, and you can always decline, too.
Posted By: DavidLancaster

Re: Animation frames blending, player input/physic - 07/12/06 11:03

I'm not sure if this would be useful to you at all, but it's the latest animation technique I've come across. The great thing about it is that I can control any entities animation simply by calling one function each frame for that entity.

This function would be called from a loop each frame:
handle_animation(1);

Now if at any point I want to change an animation I simply set say:
my.animate2 = 0;
my.animblend = blend;
my.blendframe = walk;

Now the entity will blend to the walk animation and then cycle the walk animation.

To get a little more complex, here is how I am using the code in a game we are currently developing:

Code:

IF (my.move_x != 0 || my.move_y != 0) { //if we are moving
IF (my.animblend == stand) { //if our current animation is stand
my.animate2 = 0;
my.animblend = blend; //blend and cycle to the walk or run animation depending on whether we are holding shift or not
IF ((key_pressed(key_for_str(key__shift)) == on || key_pressed(key_for_str(key__shift2)) == on)) { my.blendframe = walk; } ELSE { my.blendframe = run; }
}
IF (my.animblend == run && (key_pressed(key_for_str(key__shift)) == on || key_pressed(key_for_str(key__shift2)) == on)) {
my.animate2 = 0; //if we are cycling the run animation and are not pressing shift blend and cycle to the walk animation
my.animblend = blend;
my.blendframe = walk;
}
IF (my.animblend == walk && (key_pressed(key_for_str(key__shift)) == off && key_pressed(key_for_str(key__shift2)) == off)) {
my.animate2 = 0;
my.animblend = blend;
my.blendframe = run;
}
handle_footsteps();
} ELSE {
IF (my.animblend > stand) { //if we arn't moving and our current animation is walk or run blend and cycle the stand animation
my.animate2 = 0;
my.animblend = blend;
my.blendframe = stand;
}
}



Code:

DEFINE animate,SKILL31;
DEFINE animate2,SKILL32;
DEFINE animblend,SKILL33;
DEFINE currentframe,SKILL34;
DEFINE blendframe,SKILL35;

DEFINE blend,-1;
DEFINE stand,0;
DEFINE run,1;
DEFINE walk,2;

FUNCTION handle_animations(animation_speed) {
IF (animation_speed <= 0) { animation_speed = 1; }
IF (my.animblend == blend) {
IF (my.currentframe == stand) { ent_animate(my,"stand",my.animate,anm_cycle); }
IF (my.currentframe == run) { ent_animate(my,"run",my.animate,anm_cycle); }
IF (my.currentframe == walk) { ent_animate(my,"walk",my.animate,anm_cycle); }
IF (my.blendframe == stand) { ent_blend("stand",0,my.animate2); }
IF (my.blendframe == run) { ent_blend("run",0,my.animate2); }
IF (my.blendframe == walk) { ent_blend("walk",0,my.animate2); }
my.animate2 += 45 * time;
IF (my.animate2 >= 100) {
my.animate = 0;
IF (my.blendframe == stand) { my.animblend = stand; }
IF (my.blendframe == run) { my.animblend = run; }
IF (my.blendframe == walk) { my.animblend = walk; }
}
}
IF (my.animblend == stand) {
ent_animate(my,"stand",my.animate,anm_cycle);
my.animate += 0.8 * animation_speed * time;
my.animate %= 100;
my.currentframe = stand;
}
IF (my.animblend == run) {
ent_animate(my,"run",my.animate,anm_cycle);
my.animate += 6.8 * animation_speed * time;
my.animate %= 100;
my.currentframe = run;
}
IF (my.animblend == walk) {
ent_animate(my,"walk",my.animate,anm_cycle);
my.animate += 8 * animation_speed * time;
my.animate %= 100;
my.currentframe = walk;
}
}


Posted By: Grafton

Re: Animation frames blending, player input/physic - 07/12/06 15:43

Short, sweet and easy to understand snippit there AxysPhenomenon! And it works very well!
Thanks a million!
Posted By: Kotakide

Re: Animation frames blending, player input/physic - 07/13/06 03:39

I'm not a programmer, but judge from the look at the code,
is very clean and sharp. it's getting better and better everyday.
i'll just sit and wait you to release the demo using this code .
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/13/06 22:27

My first attempts at using the Zelda code in mine were comical to say the least. I'll try again later.

I'll also investigate that blending technique. That looks much more elegant and cleaner than what I have now. It also appears that it might be easier to add different animation modes easier(duck, jump, etc). For mine, you have to virtually double the size of the script to add something new.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 07/24/06 01:55

Here's a special version of the this system that doesn't use the c_instructions. It uses good ol' trace and ent_move. Some pre-6.31 users have problems with the official version:

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

I think I may have added gamepad support for movementType 0(behind the back at all times camera), but I'm not sure if it's bugfree yet(edit: it isn't and mode 2 is screwy too). I took a 1 week break from this thing, so I don't know which way is up at the moment. BTW, the defaults on this "special" version are movementType 4, so it's in gamepad only, camera relative mode. The two analog stick control movement and camera and the 4 buttons on top of the controller also control the camera. Button 4(on my pad) is the run key(more like a walk key since it only work when the player is running..the sticks are touch sensitive). Defaults can be changed in "main.wdl."
Posted By: eleroux

Re: Animation frames blending, player input/physic - 08/13/06 01:29

Hey Orange Brat!

I am just studying this code and I found it's great!
I am adapting the camera style to that one in games like 'thief3', which is a combination of MovementType 0 and 3. (The camera orbits with the mouse, but the player model keeps its orientation, like a freelook. But when the player hits a key or a mouse button, the player model makes a turn to get aligned to the camera target direction, as to run/walk/strafe/attack in the direction the camera is looking).

I only found a strange thing at the end of moveCam():

Code:
  
c_trace(cam_centre.x,cam_pos.x, ignore_me + ignore_passable + ignore_models + ignore_sprites);
if(trace_hit == 0) // trace hit something
{
vec_diff(temp.x,cam_pos.x,target.x);
vec_diff(cam_pos.x,cam_pos.x,temp.x);
}

vec_set(camera.x,cam_pos.x);
...





trace_hit should be -1 or 1 when c_trace hits something! Why is it tested against Zero? However, I tried (trace_hit !=0) and it never was TRUE. I made a test, and found out that trace_hit is always zero.

My guess is that someone quick-fixed a non working IF by changing it to (trace_hit == 0) as a test, and since it worked, it was left as it is. But what is inside the brackets is executed all the time anyway! The IF could be completely removed.

So why this is working anyway? I traced the code, and it works because, when c_trace fails the hit, target.x gets the same value of cam_pos. So...

vec_diff(temp.x,cam_pos.x,target.x); //temp.x gets a value of {0,0,0}
vec_diff(cam_pos.x,cam_pos.x,temp.x); //cam_pos is not changed.

When the c_trace HITS something, the same two instructions do change cam_pos value.

What puzzles me is that the trace_hit var is just not working after c_trace. Would this be a bug?

Regards,
Emilio




EDIT EDIT EDIT
I just added the cam code to a new, clean project, and it works as expected. It seems there's something in the test level you sent that prevents trace_hit to work.

For my project to work, I just had to change the line:

if(trace_hit != 0) // trace hit something
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/13/06 03:15

You're right about the trace_hit part. I've known about it for some time, and I have no idea what's going on with it. When you say you added to a clean project, did you use the complete code I provide or just the camera? In the current level if it is set to !=0 the camera will go right into walls but at ==0 it collides which is the exact opposite of what should happen.

There's probably some bugs with mode 0 on the gamepad side of things. I haven't attempted to fix them yet. Same goes for mode 1. Also, I learned that with different kinds of gamepads/sticks there are different rules that must be followed. Not every pad's maximum is -255-255 when the analog stick is depressed. Sometimes, I'm understanding that it's the opposite. One of the recent contest entries has some auto-joystick/pad detection code, and I may study it further for inclusion one day.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/13/06 12:42

One quick info. update. I finally got motivated and am tinkering with the free, open source Intense Pathfinding from Larry Laffer and RAFU. It'll be movementType 5 once I get it in place. I have everything in place(per the supplied documentation), however I'm having trouble getting my graph to build. No crashing or errors..just nothing, yet. Once I get it working in the test level with their supplied movement code, I'll attempt the transition to my own code.

Once completed, I'll try and address any additional bugs or issues that are still outstanding. Of course, I will seek permission to release the Intense integration before uploading. If they say no, then at least there will be the fixes and or new stuff.

@eleroux: Once you get that Thief3 cam working, I'd like to take a look at it if you don't mind. That may become movementType 6 or better yet I'll just make it a feature of type 3 and 4.

As for wall collision, the Zelda movement/cam thread code is the best. Here's the raw code for anyone who wants to take a crack at it. None of this is mine, and I'm wanting to integrate it into my "cam.wdl" at some point, so the system will have perfect wall collision. The current version glides along surfaces but it clips like every other camera out there(except Zelda thus the reason I want to splice it in).

Anyway, it's in two chunks...the first one is REALLY raw and has lines that would need to be eliminated or else they'll conflict with what I've already got in place(like the cam_height stuff in chunk 1...the current cam_pos.z trig lines will work for this...it's just a matter of porting my method into this one and making it all gel). The 2nd part is more refined. Good luck to anyone who wants to try and tame this. We'll all owe you big time(note that it uses old trace/ent_move...my code uses c_trace and c_move, however I have set enable_polycollision to 0.5 so it still behaves like the old instructions). Keep in mind that the goal is simply to get it to where the camera neer clips into the geometry under any circumstances. There may be lines that mimic the Zelda style camera movement(it's wonky compared to my more traditional motion), so if something in this script makes it do the wonky dance, then it should be gutted:

Code:
Below is the code which handles camera collision in the zelda code, it has been a long time since I looked at this and even now I'm not sure why some instructions and calculations are being used. I went through and commented what I thought was going on in certain places, it may not make sense, somethings confuse me alot.

Hope it helps.

David

//where camera.pan is being used in trigonometry calculations, the value used to be cam_xyangle in the zelda code, I'm not exactly sure if changing it to camera.pan will work or not

//

FUNCTION pan_back() 
{
	//cam height is the height the camera is relative to the player's z coordinte
        cam_height -= mouse_force.y * 40 * time; 
        cam_height = clamp(cam_height, -150, 300);

	//dist_total is the radius the camera is from the player
	vec_set(temp.x, vector(player.x - fcos(camera.pan, dist_total - 10), player.y - fsin(camera.pan, dist_total - 10), player.z + cam_height));  //find the camera position 10 quants behind the camera (not sure why I'm tracing 10 quants behind the camera, would be better to use vec_add rather than just the x and y component)		

	vec_diff(temp2.x,player.x,temp.x); //from behind the camera to the player
	vec_normalize(temp2.x,16); //set vector to magnitude of 16
	vec_add(temp.x,temp2.x); //set temp.x 16 quants longer, so we are tracing 16 quants behind the camera

	trace_mode = ignore_me + ignore_passable;
	trace (player.x,temp.x); //trace from the player to the camera position, this trace is used to calculate planar_to and camera_move_to.z

	dist_traced = sqrt((target.x - player.x)*(target.x - player.x)+(target.y - player.y)*(target.y - player.y));

	IF (dist_traced &gt; 0) //if the trace hit a wall
        { 
		vec_set(temp.x,target.x);
		vec_diff(temp2.x,player.x,target.x); //vector from trace hit point to the player
		vec_normalize(temp2.x,16); //normalize vector
		vec_add(temp.x,temp2.x); //move temp.x 16 quants behind target.x
		result = sqrt((temp.x - my.x)*(temp.x - my.x) + (temp.y - my.y)*(temp.y - my.y));
		IF (result &lt; dist_total) 
                { 
                   planar_to = result; //planar_to is the radius at which the camera moves to, if the calculated distance from the camera to the player is less than the maximum distance the camera could possibly be, not exactly sure why this if statement is being used
                } 
	} 
        ELSE 
        {
           planar_to = dist_total;
	}

	   camera_move_to.z = target.z; //camera_move_to vector is the coordinates at which the camera smoothly moves to, z component is calculate instantly whilst x and y are calculated differently
           player.z -= 15; //temporarily changed so that camera focusus slightly above middle
           
           var temp2[3];

	   vec_set(temp2,camera.x);
           vec_set(temp,my.x);
           vec_sub(temp,temp2.x);
           vec_to_angle(temp.pan,temp);
           camera.tilt = temp.tilt + 7;  //this causes the camera to tily towards the player

	//this smoothly moves dist_planar to the planar_to variable (the radius the camera is from the player)

	IF (abs(dist_planar - planar_to) &gt; 2) 
        {
           cradius_speed = (dist_planar - planar_to) / -1;

	} 
        ELSE 
        {
           cradius_speed = 0;
           my.skill15 = 0;
	}
	
        MY.skill15 += (TIME * cradius_speed)  - (min(TIME*0.7,1) * my.skill15);
	dist_planar += MY.skill15  * TIME;
	dist_planar = planar_to;

	//tracing from camera to below the camera to see if the camera is on the ground

	trace_mode = ignore_me + ignore_passable;
	result = trace (vector(camera.x,camera.y,player.z + 15),vector(camera.x,camera.y,camera.z + 5));

	IF (result &gt; 0) &amp;&amp; (cam_height &gt; result - 5) 
        { 
           cam_height = result - 5; 
        }  //if we have traced something place the camera above it

	camera_move_to.x = player.x - dist_planar * cos(camera.pan); //set the value at which the camera needs to smoothly move to
	camera_move_to.y = player.y - dist_planar * sin(camera.pan);

	//this is similar code to the template camera, the camera needs to be at the camera_move_to coordinates, this traces at a position, which smoothly moves towards the camera_move_to, and places the camera at the target.x vector, this works well because instead of placing the camera ta camera_move_to, it traces at a position which smoothly moves to camera_move_to

	// move towards target position

	//camera_smooth_to vector smoothly but quicly moves towards the camera_move_to.x variable (the position the camera should be)

	temp2 = min(1,0.5 * time);    // value of 1 places us at target, this value is what allows the smooth movement
	camera_smooth_to.x += temp2*(camera_move_to.x - camera_smooth_to.x); //the bigger the gap between camera_move_to.x - camera_smooth_to.x, the faster the camera moves
	camera_smooth_to.y += temp2*(camera_move_to.y - camera_smooth_to.y);
	camera_smooth_to.z += temp2*(camera_move_to.z - camera_smooth_to.z);

	// keep camera from penetrating walls

	vec_diff(temp2.x,camera_smooth_to.x,player.x); //find vector from player to the positoin the camera should be
	vec_normalize(temp2.x,16); //move vector 16 quants behind camera
	vec_add(temp2.x,camera_smooth_to.x);	// temp2 = temp_cdist + 16 units away from view target

	me = player;

	trace_mode = ignore_me + ignore_passable + ignore_models + ignore_sprites;
	IF (trace(player.x,temp2.x) &gt; 0)  
        { //trace from the player to the position 16 quants behind the camera
    	  //if the trace hit a wall
           vec_diff(temp2.x,player.x,target.x); //from player to the target position
           vec_normalize(temp2.x,16);
           vec_set(camera.x,target.x); //set camera at the traced position
           vec_add(camera.x,temp2.x);
 	} 
        ELSE 
        {
           //if the trace has not hit something set the camera to camera_smooth_to;
           vec_set(camera.x,camera_smooth_to.x);
	}
}



Code:
Hey OB

Sorry for the late reply.

I hope this works, this is very simple camera movement which should work with any entity, just have the player call handle_camera(); from it's main loop. And it should work. Although simple camera collision may be more effective, so I've added something like that further below.

Let me know how it goes.

David

var camera_move_to[3];
var camera_smooth_to[3];
var camera_distance = 200;
var camera_pan;
var camera_tilt;

FUNCTION handle_camera() 
{

	camera_pan -= mouse_force.x * 12 * time_step;
	camera_tilt += mouse_force.y * 8 * time_step;
	camera_tilt = clamp(camera_tilt,-30,10);
	camera.pan = camera_pan;
	temp = fcos(camera_tilt,-camera_distance);
	vec_set(camera_move_to.x,vector(my.x + fcos(camera.pan,temp),my.y + fsin(camera.pan,temp),my.z + 20 + fsin(camera_tilt,-camera_distance)));

	//this is similar code to the template camera, the camera needs to be at the camera_move_to coordinates, this traces at a position, which smoothly moves towards the camera_move_to, and places the camera at the target.x vector, this works well because instead of placing the camera ta camera_move_to, it traces at a position which smoothly moves to camera_move_to

	// move towards target position
	temp = min(1,0.5 * time);    // value of 1 places us at target, this value is what allows the smooth movement
	camera_smooth_to.x += temp*(camera_move_to.x - camera_smooth_to.x);
	camera_smooth_to.y += temp*(camera_move_to.y - camera_smooth_to.y);
	camera_smooth_to.z += temp*(camera_move_to.z - camera_smooth_to.z);

	// keep camera from penetrating walls
	vec_diff(temp.x,camera_smooth_to.x,my.x);
	vec_normalize(temp.x,16);
	vec_add(temp.x,camera_smooth_to.x);	// temp2 = temp_cdist + 16 units away from view target

	trace_mode = ignore_me + ignore_passable + ignore_models + ignore_sprites;
	IF (trace(my.x,temp.x) &gt; 0) 
        {

		vec_diff(temp.x,my.x,target.x);
		vec_normalize(temp.x,16);
		vec_set(camera.x,target.x);
		vec_add(camera.x,temp.x);

	} 
        ELSE 
        {
		vec_set(camera.x,camera_smooth_to.x);
	}

	vec_diff(temp.x,my.x,camera.x);
	vec_to_angle(temp.pan,temp.x);
	camera.pan = temp.pan;
	camera.tilt = temp.tilt;
}


FUNCTION handle_camera() 
{
	camera.pan -= mouse_force.x * 12 * time_step;
	camera.tilt += mouse_force.y * 8 * time_step;
	camera.tilt = clamp(camera.tilt,-30,10);
	temp = fcos(camera.tilt,-camera_distance);
	vec_set(camera.x,vector(my.x + fcos(camera.pan,temp),my.y + fsin(camera.pan,temp),my.z + 20 + fsin(camera.tilt,-camera_distance)));

	vec_diff(temp.x,camera.x,my.x); //find the vector from the player to the camera
	vec_normalize(temp.x,16); //get the magnitude of it's vector to 16 quants and store it in temp
	vec_add(temp.x,camera.x); //add the vector (from player to camera) of a magnitude of 16 quants and add it to the camera's position.

	trace_mode = ignore_me+ignore_passable;
	result = trace(my.x,temp.x); //trace from the player to 16 quants behind the camera.
	IF (result &gt; 0) 
        {
		vec_diff(temp.x,my.x,target.x); //find the vector from the point the trace hit to the player
		vec_normalize(temp.x,16); //get the magnitude of this vector to 16 quants and store in temp
		vec_set(camera.x,target.x); //place the camera at the trace hit point
		vec_add(camera.x,temp.x); //move the camera away from the wall by the vector temp, 16 quants towards the player

	}

}

Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/14/06 09:24

Quote:

trace_hit should be -1 or 1 when c_trace hits something! Why is it tested against Zero? However, I tried (trace_hit !=0) and it never was TRUE. I made a test, and found out that trace_hit is always zero.




I figured this out. I have "enable_polycollision" set to 0.5. This treats the c_instructions like old style collision and does not disable the physics engine. Setting it to 0 will disable the physics engine. If you set that var to 1 or 2 the trace_hit != 0 will work as expected. I don't know if this is a bug or simply how it is supposed to behave. I think I'll report this one and see what the answer is.

EDIT: It's not a bug, however jcl said he will tweak it if it is easy to do. Otherwise, a clarification will be made in the manual.

As for the Intense Pathfinding integration: I have it in place and working using LL's movement code. It seems that IPF also does not like enable_polycollision set below 1 so I may have to change somethings around unless LL can make it work with <1 settings. Anyway, my next step is to make it work with my own movement code. It's not that complicated, yet it's a bit tricky at the same time. Also, I noticed that my fps drops to 50 when using IPF. I don't know if this is the pathfinding itself or its dependence on a modified set of new template files. I recall a significiant fps drop when using older versions of the new templates, so perhaps I'll get those 10 fps back when I port it over to my setup.
Posted By: eleroux

Re: Animation frames blending, player input/physic - 08/15/06 03:40

Quote:


When you say you added to a clean project, did you use the complete code I provide or just the camera?





Just the camera code. But I see you solved that!

Actually, I typed in my own camera code line by line, based on yours for the most part. I skipped the 'modes', and ended up with an hybrid 0 and 3 modes. The camera never gets aligned to the player. The camera goes first, then the player uses the camera direction as pan force. This way the camera can pan quickly even while the player struggles to keep up. And in my game I am only rotating the player if he moves. In other words, if the user rotates the camera with the mouse but the entity is standing still, it's like a free look. You can see your character's face. But if you press the Forward key, the character quickly turns back and runs away from you. The same happens when strafing - it turns, then strafes.

I didnt use the blending/ animate code yet: I am solving some player Movement issues with slopes first. It seems to be the problem with new ellipsoid collision: if you prevent the entity to climb steep slopes, it will also stop going upstairs, because the ellipsoid c_moving against a stairstep edge can return a very steep surface 'normal' depending on the step height.

I am relatively new to 3dgs (NOT a former A5 user) and I'm reading all I can about the new c_move and c_trace etc. But I think I'm doing well so far.


|Emilio|
Posted By: eleroux

Re: Animation frames blending, player input/physic - 08/15/06 03:51

Only a small contribution... if could be useful.

This is the code I included to convert the difference between camera and player.pan into a rotating force, limited to the character._turnspeed

Code:

//Only pan player when walking/attacking etc.
if ( my._state !=0 )
{

mPlayer_force.pan = (camera.pan - my.pan);

//if difference > 180 degrees, change to turn other side.
mPlayer_force.pan -= (abs(mPlayer_force.pan) > 180)* sign(mPlayer_force.pan)*360;

//Limite to maximum entity _turnspeed
my._panspeed = sign(mPlayer_force.pan)*min(my._turnspeed,abs(mPlayer_force.pan))*time_step;
}
else
{
my._panspeed = 0;
}



this rotating force is later used when moving the player (c_rotate)
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/15/06 04:24

Regarding stairs, I think new collision is a bit wonky with them. This is one reason why I'm using the old AABB style collision with the c_instructions. It just works better with this particular code(no camera jerks/stuttering), plus it's faster. One trick with stairs is to make all of them passable and include an invisible ramp where the stairs are located. It gives the illusion that the player is ascending the staircase but uses the smooth slope instead of the jagged stairs. It's a cheat, but it works for the most part. It can work even better if you make a stair climbing animation for the player, but that would require some more work and timing issues. I suppose you could place a vertex(or two) on each stair and make sure a specially placed vertex on the bottom of the player's feet connects with the stair ones. This would keep the feet on the stairs, but I think this is overkill and really not needed at all if you're doing a fast paced game.

I'm going to investigate the alternate blending code from earlier in this thread. It's much easier to read and appears that it would easier to add new modes to...plus it's just plain shorter. I think I'll do that first thing.

Regarding your snippet...where do you place it in the code?

Oh, and jcl has apparently fixed the enable_polycollision problem. The newest beta feature is allowing AABB to influence the trace_hit. I'm glad I reported it, now. Perhaps, this will also allow Intense Pathfinding to also use this setting, too. Good news if true.
Posted By: eleroux

Re: Animation frames blending, player input/physic - 08/15/06 06:23

Yeah! The famous invisible ramp trick... I have read about it in some threads.

However... Invisible blocks are also passable! And setting the ramp surfaces to None renders holes in the other blocks (floor, stair steps). How is this ramp implemented, please?


The code snippet I posted before is just after defining Player's forces. But it uses skills and variables I defined before. It's just an example of how this rotation force can be defined, and some tricks to keep this rotating force in the right direction.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/15/06 06:57

Don't set anything to none...just invisible. It shouldn't be passable, unless of course the new collision makes it this way. You might have to make it a map entity with c_instructions(which I hate and I don't understand why this restriction popped up with the collision. I liked just setting a level block and going on from there...now there are 3-4 extra steps involved).
Posted By: eleroux

Re: Animation frames blending, player input/physic - 08/15/06 12:47

From the manual (block properties):

INVISIBLE: invisible obstacles. Note that invisible blocks are also not detected by trace() instructions. If a block should be invisible, but detected by trace() , use the None texture flag instead.

I have confirmed that invisible blocks are just trespassed with c_move.
On the other hand, the suggestion of using the None texture is no good.

I am not sure if I want to convert all my ramps into map entities! Isn't that a lot of work? There should be an easier way.
Posted By: JetpackMonkey

Re: Animation frames blending, player input/physic - 08/15/06 13:31

Neat!

I think it would benefit new users and old if there were more comments throughout the code to explain what's going on.

Awesome contribution!
Posted By: eleroux

Re: Animation frames blending, player input/physic - 08/15/06 15:41

This is perhaps a bit 'unortodox' but I found out I can use a SPRITE as an invisible ramp. I only need a sprite in the right proportions of the stair (say, 1x5) and make it invisible and Polygon ON. I can then scale and rotate the sprite to match the stairs.
A bit odd, but far easier than creating map entities, and I bet they build level and also realtime-render faster.

Invisible entities are not ignored by c_move/c_trace. Invisible blocks are.
I'd really like it wasn't that way. What are the possible uses of an invisible block, other than blocking movement? What is the difference between an invisible block and a deleted block?
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/15/06 19:36

It used to be different. You could make a ramp block, set it to invisible, and it could be used with stairs. This was with trace, and I remember my invisible collision geometry not working when I used early versions of c_trace; thus I kept on using trace. However, trace and ent_move are deprecated, so I've switched to c_trace/c_move but keeping enable_polycollision at 0.5. Now, that jcl is going to allow trace_hit to be changed by AABB, I can keep old, faster collision.

I've never used a sprite for collision, and I was told to simply make a map entity out of my ramps or any other invisible collision geometry for c_instruction use. It creates unnecessary extra steps and take more time. I use quite a bit of invisible collision hulls(in my full levels) because of some of my oddball geometry, so it's going to take forever and a day for me to convert everything over. Lots of extra files to deal with...I can't wait.
Posted By: eleroux

Re: Animation frames blending, player input/physic - 08/16/06 05:05

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|
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/16/06 08:34

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.
Posted By: eleroux

Re: Animation frames blending, player input/physic - 08/16/06 15:36

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.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/16/06 21:01

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

Re: Animation frames blending, player input/physic - 08/17/06 03:15

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).
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/17/06 03:24

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.
Posted By: Orange Brat

Re: Animation frames blending, player input/physic - 08/18/06 14:14

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
© 2024 lite-C Forums