[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Some Platforms



El Domingo, 20 de Febrero de 2005 18:07, Matt Bailey escribió:
> On Sunday 20 February 2005 03:12, Manuel wrote:
> > Hello Matt
> >
> > Of course, ANY help is welcome, i've recently changed my code from:
> > 	sprite always asking; I'm on the platform??
> > for:
> > 	platfom sayig, you are not on me, so start falling
> >
> > This adds more complexity, but could be used for some games.
> > For example, if you want a sprite to always be on the platform, the
> > simpler version is well, but what happens if a platform just disappear or
> > rapidly change it's position?? the sprites on it have to start falling.
> > Of course this is ugly for elevators, like in Abuse, when it does not
> > matter how the elevator falls, the player should always be on it.
>
> 	Hmmmm, I take the original approach, actually. In my case,  it's a lot
> simpler to just have one object quickly running through a list of rects,
> rather than have a whole bunch of objects each doing full collision
> detection for the player, any bullets, and whatever other solid objects are
> around. In fact, my solid objects (floors, platforms, walls, etc) don't
> even have an "update" function. Stuff that's logically static, I try to
> keep progmatically static as well. I haven't tried elevators, but the way
> my collision code is set up, I *think* they would integrate well (so long
> as the elevator gets updated before the player). As long as you kept the
> movement of the elevator per frame less than the distance the player
> free-falls per frame, the player would stay on the elevator. If the
> elevator went down too fast, you'd see the player come off of it.....but
> this is physically accurate. :)

I was in fault with the change, platforms and such are statics as you said, so 
I re-changed to the previous state. I tryed the two elevator approaches 
(uncomment the IF statement at line 60)


> 	Basically, I have the player move, then run through a list of solid
> objects. Collisions are detected by comparing the player's position in the
> last frame to its position in this frame after moving, against the position
> of each solid object. If, for instance, the top edge of the player is above
> the bottom of a solid object *and* the bottom edge of the player is below
> the top of an object (this makes it work for objects taller than the player
> as well as those shorter, such as thin platforms), I check for stuff like
> whether or not the right edge of the player rect was less than the left
> edge of the object before, and is greater than the left edge of the object
> now. This way I catch collisions even when the player never actually
> "touches" the object in-game, but passes through it (for narrow objects).
> After this is done and I've moved (or "stopped") the player as appropriate,
> I update my scroll code and check for collisions again.

I followed your advice about platform collision. You opened my eyes with this. 
My goal now is to generalize my code to allow not just platforms, but any 
kind of 'non-passable object'. And also make it scroll.

I've translated the vars in code to eanglish also.

Attachment: rects.py
Description: application/python