Thread: [Super-tux-devel] Gameloop Rewrite Status
Brought to you by:
wkendrick
Menu
▾
▴
super-tux-devel
|
From: Tobias <tob...@gm...> - 2004-01-02 17:04:33
|
Hi all, I'm making progress and you'll probably see the next CVS commit tonight. I'm currently thinking about the new collision detection and decided to move them all into one place. (i.e. collision.c/h ?) We need a function, wich can do collision detection, but there are many possibilities on how to do this. One possibility is to check if the "rectangle" of an object hits the "rectangle" of another object, like we currently do, but I don't like this method, because it isn't very precise. On the other hand it's relativly fast. The other way to do collision detection would be a pixel-per-pixel solution, where we test, if two non-alpha pixels hit each other. Maybe someone has already written such a function or a class in C++, which could be ported. My experience in this area is low (tux bless google), but I guess some of you have experience and can give me some hints and tips. :) Greetz... Tobias Gläßer -- |
|
From: Ricardo C. <ri...@ae...> - 2004-01-02 17:58:11
Attachments:
funcs.cpp
|
Hey there! Nice to see that the gameloop is being worked, since here is where the act= ion=20 takes place. I've already done a collision func to test collisions between two surfaces= ,=20 but I am sure this is not the right way to go. What I do is to check if=20 there are pixels from both images that are different from the colorkey and= =20 that are in the same position. (since supertux uses the alpha bit, you would had to replace colorkey by=20 alpha). However, this method is slow and I think that it is unnecessary in this ga= me.=20 a better approach would be the use of a bitmask per surface, as explained a= nd=20 implemented over here: http://www.ifm.liu.se/~ulfek/projects/2d_Collision_Detection.html Ricardo Em Sexta, 2 de Janeiro de 2004 23:04, o Tobias Gl=C3=A4=C3=9Fer escreveu: > Hi all, > > I'm making progress and you'll probably see the next CVS commit > tonight. I'm currently thinking about the new collision detection > and decided to move them all into one place. (i.e. collision.c/h ?) > We need a function, wich can do collision detection, but there are many > possibilities on how to do this. > > One possibility is to check if the "rectangle" of an object hits the > "rectangle" of another object, like we currently do, but I don't like > this method, because it isn't very precise. On the other hand it's > relativly fast. > > The other way to do collision detection would be a pixel-per-pixel > solution, where we test, if two non-alpha pixels hit each other. > Maybe someone has already written such a function or a class in C++, > which could be ported. > > My experience in this area is low (tux bless google), but I guess > some of you have experience and can give me some hints and tips. :) > > Greetz... > > Tobias Gl=C3=A4=C3=9Fer =2D-=20 "Hi. This is Dan Cassidy's answering machine. Please leave your name and= =20 number... and after I've doctored the tape, your message will implicate you in a federal crime and be brought to the attention of the F.B.I... BEEEP" -- Blue Devil comics |
|
From: Tobias <tob...@gm...> - 2004-01-02 19:39:07
|
Am Fr, den 02.01.2004 schrieb Ricardo Cruz um 13:02: > Hey there! > > Nice to see that the gameloop is being worked, since here is where the action > takes place. > I've already done a collision func to test collisions between two surfaces, > but I am sure this is not the right way to go. What I do is to check if > there are pixels from both images that are different from the colorkey and > that are in the same position. > (since supertux uses the alpha bit, you would had to replace colorkey by > alpha). > However, this method is slow and I think that it is unnecessary in this game. > a better approach would be the use of a bitmask per surface, as explained and > implemented over here: > http://www.ifm.liu.se/~ulfek/projects/2d_Collision_Detection.html Hey, I really like the bitmask approach! Thanks! :) Greetz... Tobias Gläßer > Ricardo > > Em Sexta, 2 de Janeiro de 2004 23:04, o Tobias Gläßer escreveu: > > Hi all, > > > > I'm making progress and you'll probably see the next CVS commit > > tonight. I'm currently thinking about the new collision detection > > and decided to move them all into one place. (i.e. collision.c/h ?) > > We need a function, wich can do collision detection, but there are many > > possibilities on how to do this. > > > > One possibility is to check if the "rectangle" of an object hits the > > "rectangle" of another object, like we currently do, but I don't like > > this method, because it isn't very precise. On the other hand it's > > relativly fast. > > > > The other way to do collision detection would be a pixel-per-pixel > > solution, where we test, if two non-alpha pixels hit each other. > > Maybe someone has already written such a function or a class in C++, > > which could be ported. > > > > My experience in this area is low (tux bless google), but I guess > > some of you have experience and can give me some hints and tips. :) > > > > Greetz... > > > > Tobias Gläßer -- |
|
From: Bill K. <nb...@so...> - 2004-01-02 21:04:38
|
On Fri, Jan 02, 2004 at 06:04:51PM -0500, Tobias Gl=E4=DFer wrote:
>=20
> One possibility is to check if the "rectangle" of an object hits the
> "rectangle" of another object, like we currently do, but I don't like
> this method, because it isn't very precise. On the other hand it's
> relativly fast.
I almost always stick to 'bounding box' (what you described above)
because it's fast, simple to program, and for most fast action games
it's "close enough."
The trick is to give the player a slight advantage. (e.g., their
bullet can hit just outside the enemy's x,y/w,h range, but the
enemy's bullet actually has to be a little INSIDE the player's rectangle,
otherwise it's ignored)
Super Tux is a fast action game, but can go slowly (e.g., the player
can walk around a little to try to make a precise hit, or just be
standing there when a bad guy aimlessly bumps into Tux), so it MIGHT
be worth doing more precise collision detection.
I think, though, that so far the bounding box method has done well
in Super Tux, so I would much rather we worry about adding gameplay
elements (more enemies, more kinds of objects to deal with, and
more levels and level art). If we REALLY need to fix the mechanics,
we can do it later. :^)
The biggest complaint in the 3 years since I first released Super Tux
was that there was only one level and few enemies. :^) Not that
Tux didn't collide with laptops 'precisely' ;^)
-bill!
PS - FYI, I recently had to do line-intersection for collision detection =
for
a vector-drawn game I'm prototyping for my new job... :^)
I first do bounding-box to decide whether I need to BOTHER with the
slow line-related math, of course. Keep this trick in mind!!
|
|
From: Tobias <tob...@gm...> - 2004-01-02 21:21:43
|
Am Fr, den 02.01.2004 schrieb Bill Kendrick um 16:04: > On Fri, Jan 02, 2004 at 06:04:51PM -0500, Tobias Gläßer wrote: > > > > One possibility is to check if the "rectangle" of an object hits the > > "rectangle" of another object, like we currently do, but I don't like > > this method, because it isn't very precise. On the other hand it's > > relativly fast. > > I almost always stick to 'bounding box' (what you described above) > because it's fast, simple to program, and for most fast action games > it's "close enough." > > The trick is to give the player a slight advantage. (e.g., their > bullet can hit just outside the enemy's x,y/w,h range, but the > enemy's bullet actually has to be a little INSIDE the player's rectangle, > otherwise it's ignored) > > Super Tux is a fast action game, but can go slowly (e.g., the player > can walk around a little to try to make a precise hit, or just be > standing there when a bad guy aimlessly bumps into Tux), so it MIGHT > be worth doing more precise collision detection. > > I think, though, that so far the bounding box method has done well > in Super Tux, so I would much rather we worry about adding gameplay > elements (more enemies, more kinds of objects to deal with, and > more levels and level art). If we REALLY need to fix the mechanics, > we can do it later. :^) > > The biggest complaint in the 3 years since I first released Super Tux > was that there was only one level and few enemies. :^) Not that > Tux didn't collide with laptops 'precisely' ;^) > > > > -bill! > > PS - FYI, I recently had to do line-intersection for collision detection for > a vector-drawn game I'm prototyping for my new job... :^) > I first do bounding-box to decide whether I need to BOTHER with the > slow line-related math, of course. Keep this trick in mind!! I'm trying my luck with bitmask-collisions, but first doing bounding-box tests is obviously. My aim with this rewrite is to make it very is easy to add funky new enemies and items. I'm sure that's a better way of doing something in the long run, than to add more code to already bloated code. Greetz... Tobias Gläßer |
|
From: Ricardo C. <ri...@ae...> - 2004-01-03 11:03:11
|
Hey, The hardest thing about bitmask is to know what side is colliding... Have = you=20 managed to full fill that? You could also have a look at one of the Ingo's games, like Windestille or= =20 Pingus (they are c++, but may be helpfull). Ricardo Em S=C3=A1bado, 3 de Janeiro de 2004 03:22, o Tobias Gl=C3=A4=C3=9Fer escre= veu: > Am Fr, den 02.01.2004 schrieb Bill Kendrick um 16:04: > > On Fri, Jan 02, 2004 at 06:04:51PM -0500, Tobias Gl=C3=A4=C3=9Fer wrote: > > > One possibility is to check if the "rectangle" of an object hits the > > > "rectangle" of another object, like we currently do, but I don't like > > > this method, because it isn't very precise. On the other hand it's > > > relativly fast. > > > > I almost always stick to 'bounding box' (what you described above) > > because it's fast, simple to program, and for most fast action games > > it's "close enough." > > > > The trick is to give the player a slight advantage. (e.g., their > > bullet can hit just outside the enemy's x,y/w,h range, but the > > enemy's bullet actually has to be a little INSIDE the player's rectangl= e, > > otherwise it's ignored) > > > > Super Tux is a fast action game, but can go slowly (e.g., the player > > can walk around a little to try to make a precise hit, or just be > > standing there when a bad guy aimlessly bumps into Tux), so it MIGHT > > be worth doing more precise collision detection. > > > > I think, though, that so far the bounding box method has done well > > in Super Tux, so I would much rather we worry about adding gameplay > > elements (more enemies, more kinds of objects to deal with, and > > more levels and level art). If we REALLY need to fix the mechanics, > > we can do it later. :^) > > > > The biggest complaint in the 3 years since I first released Super Tux > > was that there was only one level and few enemies. :^) Not that > > Tux didn't collide with laptops 'precisely' ;^) > > > > > > > > -bill! > > > > PS - FYI, I recently had to do line-intersection for collision detection > > for a vector-drawn game I'm prototyping for my new job... :^) > > I first do bounding-box to decide whether I need to BOTHER with the > > slow line-related math, of course. Keep this trick in mind!! > > I'm trying my luck with bitmask-collisions, but first doing bounding-box > tests is obviously. > > My aim with this rewrite is to make it very is easy to add funky new > enemies and items. I'm sure that's a better way of doing something in > the long run, than to add more code to already bloated code. > > Greetz... > > Tobias Gl=C3=A4=C3=9Fer > > > =2D-=20 It's time to boot, do your boot ROMs know where your disk controllers are? |
|
From: Ingo R. <gr...@gm...> - 2004-01-03 12:50:32
|
Ricardo Cruz <ri...@ae...> writes: > You could also have a look at one of the Ingo's games, like > Windestille or Pingus (they are c++, but may be helpfull). Pingus uses just a single pixel (or sometimes two) for collision detection. Windstille, even so it has some bitmask code, doesn't use it at the moment and instead uses some quick collision-rectangle hacks. So both aren't really good examples. Using multiple bitmaskes (one for the top, another one for the sides) might work, calculating the entry-vector into the enemy might also provide some informations, but I havn't really found out myself on how to solve this problem cleanly. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Tobias <tob...@gm...> - 2004-01-03 12:59:50
|
Am Sa, den 03.01.2004 schrieb Ingo Ruhnke um 07:50:
> Ricardo Cruz <ri...@ae...> writes:
>
> > You could also have a look at one of the Ingo's games, like
> > Windestille or Pingus (they are c++, but may be helpfull).
>
> Pingus uses just a single pixel (or sometimes two) for collision
> detection. Windstille, even so it has some bitmask code, doesn't use
> it at the moment and instead uses some quick collision-rectangle
> hacks. So both aren't really good examples.
>
> Using multiple bitmaskes (one for the top, another one for the sides)
> might work, calculating the entry-vector into the enemy might also
> provide some informations, but I havn't really found out myself on how
> to solve this problem cleanly.
My aim is to calculate the angle in which object A got hit by object B,
like described in the tutorial Ricardo showed us.
And I don't want to use bitmap-collisions for all objects, but for Tux
in example. :)
The code handling already calculated collisions will look like this:
void badguy_collision(bad_guy_type* pbad, int c_object, int angle)
{
/* Handle collision with Tux, but don't touch tux's internals, only
touch the badguy's internals */
if(c_object == CO_TUX)
{
if(angle == 0)
pbad->dying = FALLING;
...
}
}
Greetz...
Tobias Gläßer
--
|
|
From: Ricardo C. <ri...@ae...> - 2004-01-03 13:16:50
|
Another way to go for 2d collisions is to make use of geometry shapes...
For instace, those normal enemies in Mario (that had the teeth shown), cou=
ld=20
be assumed as a circle. Tux is like a ellipse. There are some fast algorith=
ms=20
to calculate circles/ellipses curve.
For a game of mine, I was implementing a collision system where we had the=
=20
information about the lines that limitate the surface and then we would jus=
t=20
check them with each other...
But maybe the best approach would be to use the current collision system a=
nd,=20
for special tiles, like terrains with a triangular shape, we would consider=
=20
them to be triangles.
Hope to be helpfull, :)
Ricardo Cruz
Em S=C3=A1bado, 3 de Janeiro de 2004 19:00, o Tobias Gl=C3=A4=C3=9Fer escre=
veu:
> Am Sa, den 03.01.2004 schrieb Ingo Ruhnke um 07:50:
> > Ricardo Cruz <ri...@ae...> writes:
> > > You could also have a look at one of the Ingo's games, like
> > > Windestille or Pingus (they are c++, but may be helpfull).
> >
> > Pingus uses just a single pixel (or sometimes two) for collision
> > detection. Windstille, even so it has some bitmask code, doesn't use
> > it at the moment and instead uses some quick collision-rectangle
> > hacks. So both aren't really good examples.
> >
> > Using multiple bitmaskes (one for the top, another one for the sides)
> > might work, calculating the entry-vector into the enemy might also
> > provide some informations, but I havn't really found out myself on how
> > to solve this problem cleanly.
>
> My aim is to calculate the angle in which object A got hit by object B,
> like described in the tutorial Ricardo showed us.
> And I don't want to use bitmap-collisions for all objects, but for Tux
> in example. :)
> The code handling already calculated collisions will look like this:
>
> void badguy_collision(bad_guy_type* pbad, int c_object, int angle)
> {
> /* Handle collision with Tux, but don't touch tux's internals, only
> touch the badguy's internals */
> if(c_object =3D=3D CO_TUX)
> {
>
> if(angle =3D=3D 0)
> pbad->dying =3D FALLING;
> ...
>
> }
> }
>
>
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer
=2D-=20
I do not know whether I was then a man dreaming I was a butterfly, or
whether I am now a butterfly dreaming I am a man.
-- Chuang-tzu
|
|
From: Ricardo C. <ri...@ae...> - 2004-01-03 14:18:03
|
Ingo, ClanLib has collision support, right? If affirmative, why don't you use it? and do you know what method is used? Em S=E1bado, 3 de Janeiro de 2004 12:50, o Ingo Ruhnke escreveu: > Ricardo Cruz <ri...@ae...> writes: > > You could also have a look at one of the Ingo's games, like > > Windestille or Pingus (they are c++, but may be helpfull). > > Pingus uses just a single pixel (or sometimes two) for collision > detection. Windstille, even so it has some bitmask code, doesn't use > it at the moment and instead uses some quick collision-rectangle > hacks. So both aren't really good examples. > > Using multiple bitmaskes (one for the top, another one for the sides) > might work, calculating the entry-vector into the enemy might also > provide some informations, but I havn't really found out myself on how > to solve this problem cleanly. =2D-=20 The world is full of people who have never, since childhood, met an open doorway with an open mind. -- E.B. White |
|
From: Ingo R. <gr...@gm...> - 2004-01-03 15:11:31
|
Ricardo Cruz <ri...@ae...> writes: > Ingo, ClanLib has collision support, right? Nope, Clanlib doesn't have collision detection support at the moment, its planed that it will get some sooner or later, but so far there is none. > and do you know what method is used? If it ever gets some it will provide both bitmask and geometry based stuff, but nobody so far has started to implement that into clanlib. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X