[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Change gravity [Was: Movers and Colliders for Fallers]
From: |
Gervase Lam |
Subject: |
Change gravity [Was: Movers and Colliders for Fallers] |
Date: |
Wed, 12 Mar 2003 01:34:12 +0000 |
> Date: 11 Mar 2003 02:54:25 +0100
> From: Ingo Ruhnke <address@hidden>
> Subject: Re: Movers and Colliders for Fallers
> Btw. Could you look into getting the fallers a bit slowed down, so
> that they are easy clickable in normal game-speed and so that one
> doesn't have to constantly press pause to hit one of them in the air.
> The tumble-phase is currently also hardly visible at all due to there
> current speed. Slowing them down to half of there current speed or
> even more should probally help.
I was going to look into this after sorting out a segmentation fault I
found when using the "blockers-timpany-tutorial.xml" level. This happens
whenever a rain splash is displayed by the Rain particle code. I was
going to find out how to get gdb to print out a full frame info (i.e.
backtrace) because I've forgotten how to do it.
So that the levels don't get broken by the change in the gravity, the
falling distance will need to remain the same as it is now. To do this, I
was thinking of making deadly velocity related to gravity [deadly_velocity
= 20 * sqrt(gravity)]. At the moment, both are independent of each other.
I'll just put a gravity constant in "pingu_enums.cxx". However, instead
of putting the mathematical formula into the code, I'll just put a comment
saying that the formula should be used to calculate the constant.
Apparently, comments in this situation are very powerful!
Btw, is faller.cxx the only place where a gravity value is used? Strictly
speaking, it could be said that floaters are influenced by gravity.
However, I'll let them remain at moving +1.0 pixel at a time. Any slower
would be too slow.
Thanks,
Gervase.
- Change gravity [Was: Movers and Colliders for Fallers],
Gervase Lam <=