|
|
Re: Good movement code in c-lite
[Re: Slin]
#175626
01/11/08 07:42
01/11/08 07:42
|
Joined: Mar 2002
Posts: 580
San Francisco
clone45
OP
User
|
OP
User
Joined: Mar 2002
Posts: 580
San Francisco
|
@slin: Thanks for showing me those nice shortcuts. I'll merge those changes into my movement code and hopefully re-post it soon. Actually, I take it back. After thinking it over, I'll probably keep these lines the same: accelerate(move_to_vector.y, (key_d * strafe_speed * time_step * -1), 0.8); accelerate(move_to_vector.y, (key_a * strafe_speed * time_step), 0.8); accelerate(move_to_vector.x, (key_w * run_speed * time_step), 0.8); accelerate(move_to_vector.x, (key_s * run_speed * time_step * -1), 0.8); You are absolutely correct that they can be merged into 2 lines, but for me it's more readable as 4 lines. In this case, I'll choose readability over saving the CPU cycles.  To answer your question: Quote:
Why do you use c_setminmax and then reset the boundingbox to an own size (vec_set(my.min_x,vector(-7,-7,-20));vec_set(my.max_x,vector(7,7,20));)?
I noticed that if I tried to set the bounding box without first calling c_setminmax(), my bounding box settings were ignored! Maybe I was hallucinating - but that's why the c_setminmax is in there. Weird.
Last edited by clone45; 01/11/08 07:46.
|
|
|
Re: Good movement code in c-lite
[Re: Slin]
#175628
01/11/08 16:12
01/11/08 16:12
|
Joined: Sep 2003
Posts: 9,859
FBL
Senior Expert
|
Senior Expert
Joined: Sep 2003
Posts: 9,859
|
Why not use vec_accelerate? Code:
vec_accelerate(vecDist, my->speedX, my->forceX, Afriction);
vec_accelerate(vecAdist, my->aspeedX, my->aforceX, Afriction);
c_move(me, vecDist, vecAdist, IGNORE_ME|IGNORE_YOU|IGNORE_PASSABLE|USE_AABB|GLIDE);
IMHO the upper solution simply is wrong, as you're accelerating the same variable TWICE per frame. Did you check consistency with different framerates? The manual lsits the following implementation for accelerate: Code:
Algorithm:
if (friction == 0)
distance = speed*time + 0.5*accel*time*time
speed = speed + accel*time
else
distance = accel*time/friction + (speed-accel/friction)*(1-exp(-friction*time))/friction
speed = accel/friction + (speed-accel/friction)*exp(-friction*time)
By doing this twice per frame on the same variable, you mess up time correction.
|
|
|
Re: Good movement code in c-lite
[Re: clone45]
#175629
01/11/08 16:43
01/11/08 16:43
|
Joined: Aug 2002
Posts: 673
Las Cruces, NM
JimFox
User
|
User
Joined: Aug 2002
Posts: 673
Las Cruces, NM
|
I definitely plan to take a close look at this. Porting my game to Lite-C is going to require that I work up a clean First-Person movement code.
How hard would it be to convert this to First Person?
Thanks for all your hard work.
Regards,
Jim
|
|
|
Re: Good movement code in c-lite
[Re: FBL]
#175631
01/12/08 20:24
01/12/08 20:24
|
Joined: Mar 2002
Posts: 580
San Francisco
clone45
OP
User
|
OP
User
Joined: Mar 2002
Posts: 580
San Francisco
|
@Firoball - I'm not sure if the double accelerate will mess up the movement, but just in case, I took everyone's advice and collapsed the accelerate statements to 2 lines. I really appreciate everyone's feedback. As a reminder, a lot of the movement code was adapted from David Lancaster. Thanks David! I moved the code to the wiki. I encourage people to make bug fixes and enhancements to the code on the wiki. The URL is: Movement Code on the Wiki: http://www.coniserver.net/wiki/index.php/Modified_Kingdom_Hearts_MovementCheers! - Bret
|
|
|
Re: Good movement code in c-lite
[Re: Pappenheimer]
#175632
01/13/08 10:55
01/13/08 10:55
|
Joined: Jul 2004
Posts: 4,206
Innsbruck, Austria
sPlKe
Expert
|
Expert
Joined: Jul 2004
Posts: 4,206
Innsbruck, Austria
|
Quote:
Agree with Nems, I'm one of the ancient relics that still didn't write a single line in Lite-C! 
me too. it took me years to figure out c-script (and i still dont know how to code) and now learning ltie c woudl kill me...
|
|
|
|
