How i define transitable zones for games?

I am programming a game similar to Mario Bros… and i dont now how to define the transitables zones… i think in a boolean array… such big as the background image… defining with 1 the zones where the main character can walk, jump etc.
So… how can a made this boolean array using the surfaces and putting 0 where the surface has a transparency…
Thanks…
Fede!

If your game is tile-based, you can just define collision maps for each tile,
and then not check the resulting image, but the level-map.

hth,
FlorianOn Monday 20 May 2002 03:50, Federico Berardi wrote:

I am programming a game similar to Mario Bros… and i dont now how to
define the transitables zones… i think in a boolean array… such big as

what is the meaning of tile-based… i am programing the game with sprie…
i am detectig colision with the rectagle of both of the sprite … but i
want it to be better… and i dont know how…> ----- Original Message -----

From: ma1flfs@bath.ac.uk (Florian Schanda)
To:
Sent: Monday, May 20, 2002 10:03 AM
Subject: Re: [SDL] How i define transitable zones for games?

On Monday 20 May 2002 03:50, Federico Berardi wrote:

I am programming a game similar to Mario Bros… and i dont now how
to

define the transitables zones… i think in a boolean array… such big
as

If your game is tile-based, you can just define collision maps for each
tile,
and then not check the resulting image, but the level-map.

hth,
Florian


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

what is the meaning of tile-based…

“Tile based” refers to the way a game manages background graphics, and
often also some of the game logic. “Tiles” are basically sprites,
although they generally have no transparency, and they’re usually all of
the same size. “Maps” are used to construct backgrounds from tiles. A map
is usually a two dimensional array with one integer for each “tile
square”, determining which tile image to use for that square when
rendering the level.

Have a look at the parallax scrolling demos (parallax-2/3/4):

http://olofson.net/mixed.html

You may also check out my smoothscroll demo, which, although it’s really
meant as a demo of ultra smooth scrolling with OpenGL, contains a map
editor that demonstrates the basics of tiled backgrounds visually, kind
of. (smoothscroll-1.1.tar.gz, found on the same page.)

i am programing the game with
sprie…

Does that mean you’re constructing the whole display with freely
positioned sprites, or do you have a large background image?

i am detectig colision with the rectagle of both of the sprite
… but i want it to be better… and i dont know how…

Better; why, and in what way?

There are lots of games that use bounding rects and similar "math based"
collision detection systems, and it works very well if done right.

However, if you really need pixel accurate sprite/sprite collision
detection, the most popular solution seems to be some form of
bitmap/bitmap testing.

First, do the bounding rect test you’re doing already, and if it says
"overlap", test on the pixel level to find out if you actually have a
collision.

You’ll find working implementations of this in a few places, although I
can only remember SGE right now.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 21 May 2002 04:12, Federico Berardi wrote:

what is the meaning of tile-based…

“Tile based” refers to the way a game manages background graphics, and
often also some of the game logic. “Tiles” are basically sprites,
although they generally have no transparency, and they’re usually all of
the same size. “Maps” are used to construct backgrounds from tiles. A map
is usually a two dimensional array with one integer for each “tile
square”, determining which tile image to use for that square when
rendering the level.

Have a look at the parallax scrolling demos (parallax-2/3/4):

http://olofson.net/mixed.html

You may also check out my smoothscroll demo, which, although it’s really
meant as a demo of ultra smooth scrolling with OpenGL, contains a map
editor that demonstrates the basics of tiled backgrounds visually, kind
of. (smoothscroll-1.1.tar.gz, found on the same page.)

Thanks, now, i undestand!

i am programing the game with
sprie…

Does that mean you’re constructing the whole display with freely
positioned sprites, or do you have a large background image?

I have a large bakground image that i scroll in the way that the main
character walk… to the right or to the left… but i didnt know what you
show me…

i am detectig colision with the rectagle of both of the sprite
… but i want it to be better… and i dont know how…

Better; why, and in what way?

There are lots of games that use bounding rects and similar "math based"
collision detection systems, and it works very well if done right.

However, if you really need pixel accurate sprite/sprite collision
detection, the most popular solution seems to be some form of
bitmap/bitmap testing.

???that is what i want!!!

First, do the bounding rect test you’re doing already, and if it says
"overlap", test on the pixel level to find out if you actually have a
collision.
yes! i get the first collision with the rectagles of the sprite… but
then… i dont know how to test bitmap/bitmap

You’ll find working implementations of this in a few places, although I
can only remember SGE right now.

thanks…
Fede!> On Tuesday 21 May 2002 04:12, Federico Berardi wrote:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[…]

First, do the bounding rect test you’re doing already, and if it says
"overlap", test on the pixel level to find out if you actually have a
collision.

yes! i get the first collision with the rectagles of the sprite… but
then… i dont know how to test bitmap/bitmap

Well, that’s also the trickiest part of it… :slight_smile:

You could use the actual graphics data (like I did for the
bullet/sprite tests in Project Spitfire/DOS), but this gets kind of messy
(or slow) these days, when we can’t assume much about the pixel format.
(For speed, you’ll want to make sure that all graphics is converted to
the screen format.) Besides, this gets increasingly expensive if you want
other colors than the colorkey to be “open”.

A better and faster way is to generate bitmaps (one bit per pixel instead
of the normal 8, 16, 24 or 32) after loading the images, and then use
those for collision detection.

Unfortunately, SDL can’t help you much with that, since it doesn’t
supports only “N whole bytes per pixel”; not “N pixels per byte”.
However, it can convert surfaces into some nice and known format, like
24 bit RGB, so that you can get away with very simple code for the
surface->bitmap conversion.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 22 May 2002 04:47, Federico Berardi wrote:

http://olofson.net/mixed.html

offttopic: The difference in speed is big !
-sdl is more than twice slower then opengl version + it’s not so smooth !!!

Grzegiorz Jaskiewicz.

This is to be expected :slight_smile:

-EvilTypeGUyOn Wed, May 22, 2002 at 01:10:16PM +0200, Grzegorz Jaskiewicz wrote:

http://olofson.net/mixed.html

offttopic: The difference in speed is big !
-sdl is more than twice slower then opengl version + it’s not so smooth !!!

In fact, it’s the very point of having the -sdl option at all. :slight_smile:

The idea is that you can directly compare the SDL and OpenGL versions of
the same application, with the same graphics and map. -sdl is slower
since it’s not accelerated, and less smooth since it doesn’t implement
subpixel accurate scrolling.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 22 May 2002 16:00, EvilTypeGuy wrote:

On Wed, May 22, 2002 at 01:10:16PM +0200, Grzegorz Jaskiewicz wrote:

http://olofson.net/mixed.html

offttopic: The difference in speed is big !
-sdl is more than twice slower then opengl version + it’s not so
smooth !!!

This is to be expected :slight_smile:

And the OpenGL version renders in default 4 times the area that SDL
version. I got very amusing frame rates from the OGL version without VB
synchronization with scale set to same as in SDL mode (-s1). Framerate
was over 5000 fps. Even in default smoothscroll settings with heviest
FSAA settings (4*4 Gaussian) it produced about 380 fps. The odd thing
was that if I used the hevy FSAA setting then the synchronization made
the scrolling very jerky, because refresh rate droped to 70 instead of
the 85 which is my 640x480 refresh rate.On 2002.05.22 14:10 Grzegorz Jaskiewicz wrote:

http://olofson.net/mixed.html

offttopic: The difference in speed is big !
-sdl is more than twice slower then opengl version + it’s not so
smooth !!!

[…]

The odd thing
was that if I used the hevy FSAA setting then the synchronization made
the scrolling very jerky, because refresh rate droped to 70 instead of
the 85 which is my 640x480 refresh rate.

That’s probably the dreaded “alternating frame skip” problem that plague
all systems that don’t provide frame counters or similar in the API.
(That would be all current systems, AFAIK.)

What happens is that the frame rate alternates between 85 and 42.5 fps.
The fundamentally broken “flip” API, which requires that timing is
derived on the application side, results in this causing bogus
timestamps, which in turn causes unsmooth animation.

You could try disabling the “motion filter” (provided you’re using the
version that has it), but that will only avoid amplifying the timestamp
errors. (Timestamps affect the next frame; not the one the timestamp
was taken on.)

The only way to avoid this problem without restricting the frame rate, is
a driver extension (or possibly an ugly and not particularly reliable
dual thread hack), and some clever “rendering time estimation” code.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 22 May 2002 17:22, Sami N??t?nen wrote:

[…]

You could try disabling the “motion filter” (provided you’re using the
version that has it), but that will only avoid amplifying the timestamp
errors. (Timestamps affect the next frame; not the one the timestamp
was taken on.)

Meep!

What I meant to say was that disabling the “motion filter” will double
the timing errors (since timing fluctuations are fed forward to later
frames).

IIRC, the filter is enabled by default, and should reduce this feed
forward problem significantly. It will also reduce thu impact of timing
fluctiations caused by some driver architectures and/or drivers.

Sorry for confusing matters. (This stuff is messy enough as it is! :slight_smile:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 22 May 2002 19:34, David Olofson wrote:

However, if you really need pixel accurate sprite/sprite collision
detection, the most popular solution seems to be some form of
bitmap/bitmap testing.

An easy, mem-saving way to do a bitmap-bitmap test is to sacrifice the rightmost bit of one
of the colours (R, G or B) of the main bitmap and put the “transitable” flag in its place.
The difference won’t be noticed by human eye. This way, you can save your map in a generic
24-bit bitmap and load the whole stuff in a single SDL_image.
You may also do this trick with the rightmost bit of the other two colors, allowing to
define, for example, “instant-death” areas, areas where you get damaged or similars.

When it comes to testing wether the surface is “transitable” or not, you may test a pixel
every 4 or every 9 to gain speed.

You may want to check out

http://www.ifm.liu.se/~ulfek/projects/bitmask-1.0b.tar.gz

It’s a very small library to create bitmasks and check them for
overlap vs each other. You can also get point of collision and
the number of pixels that overlapped. You just have to create a
function to set the transparent parts of the mask to 0 and the solid
parts to 1 for each sprite image. You can easily do hundreds of
sprites
on a modern computer.

–ulf