Helo
Is there any place where i could read information about makeing
maps with SDL? I want to know how does this work… my idea is to create a
map, with tiles, in 2D. With perspective. Like the look of Ultima Online, or
Hellbreath.
I have an idea of how to make a map with tiles, but with no perspective, but
i want to learn a bit more about this… and i cant imagine a way of
makeing an isomeric look to a game…
Thanks you all in advantage.
Helo
Is there any place where i could read information aboutmakeing maps with SDL?
Making maps, or just rendering them?
smoothscroll does both, BTW. Very basic integrated map editor.
I want to know how does this work… my idea
is to create a map, with tiles, in 2D. With perspective. Like the
look of Ultima Online, or Hellbreath.
Maybe that’s an idea for another scrolling example…?
Anyway, the biggest difference between plain 2D and isometric views is
that the latter has non-rectangular tiles. The most common solution
is to make them diamond shaped instead; something like this:On Wednesday 21 May 2003 05.27, eDU! wrote:
‘#’ are opaque pixels, while ‘-’ are transparent. You’ll have to use
colorkeying or alpha channels for this.
Yep, this is one case where you should use RLE acceleration and one
surface per tile. RLE acceleration makes blitting with colorkey and
alpha channels pretty much as fast as plain rectangular blitting. In
the case of alpha, only the pixels that are actually blended (ie not
transparent or opaque) are expensive. Opaque pixels are rendered just
as fast as in plain rectangular blits.
However, clipping RLE encoded is (relatively) expensive, and you’ll be
doing a lot of it if you blit from a single tileset image, so use one
per tile. (Chop them up at load time or something.) Pass SDL_RLEACCEL
to SDL_SetColorKey() or SDL_SetAlpha() to enable RLE acceleration.
Next, you’ll have to render every other row of tiles offset by half
the width of a tile. The height of one row is half the height of a
tile.
Well, that’s about it, I think…
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —
In the game I’m working on, all of my sprite images were RLE
encoded. Then I implemented pixel-precision collision
detection and the performance dropped significantly. It took me
a week to find out that RLE was causing it… :)On Wed, May 21, 2003 at 10:24:34AM +0200, David Olofson wrote:
However, clipping RLE encoded is (relatively) expensive, and you’ll be
doing a lot of it if you blit from a single tileset image, so use one
per tile. (Chop them up at load time or something.) Pass SDL_RLEACCEL
to SDL_SetColorKey() or SDL_SetAlpha() to enable RLE acceleration.
–
Ivan Stankovic, @Ivan_Stankovic
Lots of decoding and recoding going on there… hehe
Either way, I think it’s a better idea to do the actual collision
detection on bit masks (1 bpp) that you generate while loading the
game. That gives you more freedom to filter colors and stuff, or even
draw some of the bit masks by hand, if the graphics doesn’t match the
desired collision zones.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 21 May 2003 14.10, Ivan Stankovic wrote:
On Wed, May 21, 2003 at 10:24:34AM +0200, David Olofson wrote:
However, clipping RLE encoded is (relatively) expensive, and
you’ll be doing a lot of it if you blit from a single tileset
image, so use one per tile. (Chop them up at load time or
something.) Pass SDL_RLEACCEL to SDL_SetColorKey() or
SDL_SetAlpha() to enable RLE acceleration.In the game I’m working on, all of my sprite images were RLE
encoded. Then I implemented pixel-precision collision
detection and the performance dropped significantly. It took me
a week to find out that RLE was causing it…
Yeah, I thought of that, but I think it’s somewhat a waste of space,
when you already have what you need in the surface itself…On Wed, May 21, 2003 at 02:48:05PM +0200, David Olofson wrote:
Either way, I think it’s a better idea to do the actual collision
detection on bit masks (1 bpp) that you generate while loading the
game. That gives you more freedom to filter colors and stuff, or even
draw some of the bit masks by hand, if the graphics doesn’t match the
desired collision zones.
–
Ivan Stankovic, @Ivan_Stankovic
Either way, I think it’s a better idea to do the actual collision
detection on bit masks (1 bpp) that you generate while loading the
game. That gives you more freedom to filter colors and stuff, or even
draw some of the bit masks by hand, if the graphics doesn’t match the
desired collision zones.Yeah, I thought of that, but I think it’s somewhat a waste of space,
when you already have what you need in the surface itself…
That’s good enough for prototypes or very simple games. But if you want
to support real graphics (as opposed to programmer-, 8bit-,
eighties-style, a-couple-of-pixels-for-a-ship graphics), I’m afraid that
you’ll inevitably run into cases where nontransparent and collision (or
input sensitive) zones won’t be the same. If you’re at all interested
in reuse you should give collision bitmaps a try, simply because often
you will not have what you need in the surface itself.
From a more philosophical POV, when you think about it, collision areas,
input sensitive areas and non-transparent areas are not necessarily
related in any way. If inherently independent things are put into
inappropriate dependency relationship, their ways will probably part in
some time in the future and then the dependencies start to prevent you
from doing things that should be simple (as OOP teaches us). Your RLE
problem is an instance of such a situation.
latimeriusOn Wed, May 21, 2003 at 04:42:23PM +0200, Ivan Stankovic wrote:
On Wed, May 21, 2003 at 02:48:05PM +0200, David Olofson wrote:
Except that…
* it’s insanely expensive to read the surface
if it’s in VRAM or RLE encoded.
* you’ll have to implement the detection code
for multiple pixel formats.
* the collision detection becomes highly dependent
on whatever rendering API you use.
* the collision detection will have to support
all rendering backends you want in the game.
* you can’t run the game logic without loading
the graphics. (Dedicated game servers.)
* you’ll have to consider colorkey, alpha and
whatnot to find out which pixels to test.
* if you can do with 1 bpp, working with gfx
data means you’re shuffling between 8 and 32
times as much data as you need to.
* if you support scaling to other resolutions,
you’re in real trouble…
* …and you might be processing up to hundreds
of times more data than you really have to.
I did work with the graphics data directly in Project Spitfire, but
that was a 256 color Mode-X game. I’d never do it in a environment
that I don’t fully control, and in fact, I wouldn’t have done it in
Project Spitfire either if I had more time. I think it’s a Really Bad
Idea™, except possibly if it’s done in the hardware, as it was on
some old home computers and consoles.
There. Do I have to think of some more reasons not to mess with
graphics data in the game logic code? 
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 21 May 2003 16.42, Ivan Stankovic wrote:
On Wed, May 21, 2003 at 02:48:05PM +0200, David Olofson wrote:
Either way, I think it’s a better idea to do the actual collision
detection on bit masks (1 bpp) that you generate while loading
the game. That gives you more freedom to filter colors and stuff,
or even draw some of the bit masks by hand, if the graphics
doesn’t match the desired collision zones.Yeah, I thought of that, but I think it’s somewhat a waste of
space, when you already have what you need in the surface itself…
Either way, I think it’s a better idea to do the actual collision
detection on bit masks (1 bpp) that you generate while loading the
game. That gives you more freedom to filter colors and stuff, or even
draw some of the bit masks by hand, if the graphics doesn’t match the
desired collision zones.Yeah, I thought of that, but I think it’s somewhat a waste of space,
when you already have what you need in the surface itself…That’s good enough for prototypes or very simple games. But if you want
to support real graphics (as opposed to programmer-, 8bit-,
eighties-style, a-couple-of-pixels-for-a-ship graphics), I’m afraid that
you’ll inevitably run into cases where nontransparent and collision (or
input sensitive) zones won’t be the same.
Good point, but since my game is very simple, I don’t have to worry about
that.On Wed, May 21, 2003 at 05:18:26PM +0200, Latimerius wrote:
On Wed, May 21, 2003 at 04:42:23PM +0200, Ivan Stankovic wrote:
On Wed, May 21, 2003 at 02:48:05PM +0200, David Olofson wrote:
–
Ivan Stankovic, @Ivan_Stankovic
[snip]
There. Do I have to think of some more reasons not to mess with
graphics data in the game logic code?
No, I think these should suffice… :)On Wed, May 21, 2003 at 05:29:36PM +0200, David Olofson wrote:
–
Ivan Stankovic, @Ivan_Stankovic
David,
first of all, thanks for your reply.
I was just talking about the theory, as i didnt start yet with SDL. My idea
was to create a matrix with X*X number of tiles (sqare tiles). Then, after
sending the email i start thinking on how to make a “3D” or Isomeric look
with square tiles… and i thought… with triangles. Now that u tell me
that it is made with Triangle Tiles it looks easyer 
I will start looking around for tutorials, etc… but as i said, im new to
working with graphics… so i dont know yet what does those words Rendering,
alpha, etc… means.
And my idea is to MAKE my self the map, not to use any external thing.
I will look around and well if i have problems i will mail to the list if i
cant find any solution.
Thanks again for your reply, it was really helpful ! =))
Eduardo Garcia Rajo (h)------------------------------------------------------------------
Visite: http://www.solucion-digital.com.ar
SOLUCION DIGITAL
Redes - Software - Servicios
----- Original Message -----
From: david@olofson.net (David Olofson)
To:
Sent: Wednesday, May 21, 2003 5:24 AM
Subject: Re: [SDL] Creeating MAPS with SDL
Ivan, can i ask you if u are creating an RPG style game?
may be u can help me a little when in the time i start with mapping 
if it doesnt bother u
Eduardo Garcia Rajo (h)------------------------------------------------------------------
Visite: http://www.solucion-digital.com.ar
SOLUCION DIGITAL
Redes - Software - Servicios
----- Original Message -----
From: pokemon@fly.srk.fer.hr (Ivan Stankovic)
To:
Sent: Wednesday, May 21, 2003 9:10 AM
Subject: Re: [SDL] Creeating MAPS with SDLOn Wed, May 21, 2003 at 10:24:34AM +0200, David Olofson wrote:
However, clipping RLE encoded is (relatively) expensive, and you’ll be
doing a lot of it if you blit from a single tileset image, so use one
per tile. (Chop them up at load time or something.) Pass SDL_RLEACCEL
to SDL_SetColorKey() or SDL_SetAlpha() to enable RLE acceleration.In the game I’m working on, all of my sprite images were RLE
encoded. Then I implemented pixel-precision collision
detection and the performance dropped significantly. It took me
a week to find out that RLE was causing it…–
Ivan Stankovic, pokemon at fly.srk.fer.hr
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
some of u guys know too much…
he…
i think i will be all day reading today before starting my game 
thanks for replying my message… im gathering all the information i can
Eduardo Garcia Rajo (h)------------------------------------------------------------------
Visite: http://www.solucion-digital.com.ar
SOLUCION DIGITAL
Redes - Software - Servicios
----- Original Message -----
From: pvl@uh.cz (Latimerius)
To:
Sent: Wednesday, May 21, 2003 12:18 PM
Subject: Re: [SDL] Creeating MAPS with SDLOn Wed, May 21, 2003 at 04:42:23PM +0200, Ivan Stankovic wrote:
On Wed, May 21, 2003 at 02:48:05PM +0200, David Olofson wrote:
Either way, I think it’s a better idea to do the actual collision
detection on bit masks (1 bpp) that you generate while loading the
game. That gives you more freedom to filter colors and stuff, or even
draw some of the bit masks by hand, if the graphics doesn’t match the
desired collision zones.Yeah, I thought of that, but I think it’s somewhat a waste of space,
when you already have what you need in the surface itself…That’s good enough for prototypes or very simple games. But if you want
to support real graphics (as opposed to programmer-, 8bit-,
eighties-style, a-couple-of-pixels-for-a-ship graphics), I’m afraid that
you’ll inevitably run into cases where nontransparent and collision (or
input sensitive) zones won’t be the same. If you’re at all interested
in reuse you should give collision bitmaps a try, simply because often
you will not have what you need in the surface itself.From a more philosophical POV, when you think about it, collision areas,
input sensitive areas and non-transparent areas are not necessarily
related in any way. If inherently independent things are put into
inappropriate dependency relationship, their ways will probably part in
some time in the future and then the dependencies start to prevent you
from doing things that should be simple (as OOP teaches us). Your RLE
problem is an instance of such a situation.latimerius
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl