[SDL] Tile engine code

[David Olofson]

On Thursday 31 January 2002 05:59, Bryan Arant wrote:
[...]
> >Problem 2: A linked list is probably fine for a lot of tasks, but for
> >real time rendering, you'll probably need some secondary structure to
> >look tiles up. (Unless you're using a small map and/or huge tiles,
> > you'll have to extract and render only the tiles currently visible -
> > just plowing throught the whole map won't work.)
>
> Hm, I was going to go through the list and check to see which ones are
> currently
> visible on the screen, and only draw those. That does sound a little
> inefficient
> though. What would be the best way to do this?

Simple: The way that gives the correct result with the smallest amount of 
work. ;-)

It depends on your game, but in general, 2D array maps with fixed tiles, 
"snapped" to the grip is the fastest and easiest way to go, by far. Just 
loop over the rectangular area of the map where the screen is, and you're 
done. No active searching, filtering or anything.

You can have a look at the Scrolling Examples for a basic idea of how to 
do it:

	http://olofson.net/mixed.html


> >For simple, single layer maps, a 2D array is usually the easiest and
> > best way to go. For maps with multiple layers, mixed size tiles,
> > detail sprites etc, you can either extend the basic 2D array approach
> > into a zone based map (hook a linked list of tiles and sprites to
> > each "tile" location on the map), or you can switch to some
> > multidimensional tree structure.
>
> Would a Multimap be efficient?

	Multimap? (I'm tired - long night of DOS->Linux porting...)


> >So it's actually not just a plain map file, but a complete "level
> >definition"...?
>
> Why yes... yes it is. I want to use my tiling engine for more then one
> thing
>
> :)

Well, just keep in mind that flexibility often comes at the expense of 
performance. However, proper design is ofter enough to get a good 
trade-off, especially with the control/data ratio we have these days. 
(Tons of graphics and audio being pumped around, while even quite complex 
higher level code ends up consuming a neglibigle share of the CPU time.)


> >IMHO - as there doesn't seem to be a way of specifying tile *size* -
> > it's much more convenient to address tiles using tile indices rather
> > than explicit tile coordinates. (I usually hack up some code that
> >automatically chops up an input image into a linear array of tiles.
> > See Kobo Deluxe for an example.)
>
> The tile size would be defined in one of the first few lines at the top
> of the file. I thought of this shortly after writing this letter.

Are you going to support multiple tile sizes in a single map?


[...]
> >Sounds like a reasonable design idea. The only parts I'm in doubt
> > about are the internal structure of the loaded map data, and the map
> > file format. Your design would *work*, but you'll have to add some
> > info to avoid performance issues with large maps. I don't quite get
> > why you want "tile palette" coordinates in the map data - but it
> > would *work* all right. (In fact, XKobo/Kobo Deluxe used to address
> > tiles and sprites like that, until I integrated it with the
> > tile/sprite loader from Project Spitfire.)
>
> Thank you. After I finish the whole tile thing, I would be more then
> happy to
> announce it to this group.
>
> Thanks a BUNCH David for reading through all my jarble, and responding.

No problem! (Can't stay away from this kind of stuff. That's how the 
Scrolling Examples got written... :-)


//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 -'