# Tile engine code

**URL:** <https://discourse.libsdl.org/t/tile-engine-code/5928>\
**Category:** SDL Development\
**Created:** [January 28, 2002, 4:42pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928 "2002-01-28T16:42:00Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Cameron\_Matheson](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/c/9fc348/32.png) [@Cameron\_Matheson](https://discourse.libsdl.org/u/Cameron_Matheson)\
**Post date:** [January 28, 2002, 4:42pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/1 "2002-01-28T16:42:00Z")

</div>

Hey,

I’m trying to write a tile engine… but i’m having lots of trouble (it works  
fine when I do sequential reads of my map, but random-access reads (which are  
the thing that matter it seems like?) don’t seem to work at all… If someone  
could point me towards some source code i could look at… that would help a  
lot. (I would have posted my code to see if someone could help me, but it  
doesn’t have any SDL yet (it’s all ASCII so far), and i was trying to keep  
this semi-on-topic.)

Thank you very much  
Cameron Matheson\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
Do You Yahoo!?  
Get your free @yahoo.com address at [http://mail.yahoo.com](http://mail.yahoo.com)

---

<div class="post-metadata">

**Author:** ![Bryan\_Arant](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/cab0a1/32.png) [@Bryan\_Arant](https://discourse.libsdl.org/u/Bryan_Arant)\
**Post date:** [January 28, 2002, 5:43pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/2 "2002-01-28T17:43:01Z")

</div>

I’m going to be working on a tile engine soon (2D) and am just currently  
working on the parser. Got that working well last night. Next step is to get  
it tiling (Using SDL of course).

Here are my plans with tons of holes in it, because I have never done this  
before, and don’t have anything set in stone yet.

I just plan on creating a class called TILE, and while I’m reading the file,  
I will just call a constructor which defines the tile. Then I will add it to  
my linked list.

First line in my file format is the name of the tileset file I’m using.

tileset.bmp

And the rest of the file is where I load tiles, events, etc…  
So inside my file I define a tile like so:  
tile:  
0  
0  
32  
32

Format is not set in stone, but the 1st and 2nd numbers are the x,y  
locations on the screen 3rd and 4th are the x,y locations in the tileset.bmp  
file.

So I read through the file, find “tile:” and then call a constructor.  
Something like

tile = new TILE(Uint16 x, Uint16 y, Uint16 t\_x, Uint16 t\_y); (Hopefully you  
know what to do with this information.)

or incase of above:

tile = new TILE(0, 0, 32, 32);

This should all be taking place inside the WORLD class which has functions  
like LoadMap();  
And I will have a linked list containing all the tiles so I can do various  
stuff to it, like remove it, check values, or something of the such.

Then I can have a draw function inside the tile class, things are endless  
after that. Of course I have never done this before, but this is my idea as  
of late. And I hope to have it working sometime this week (Yeah right, to  
much school) or during next weekend.

By the way, feel free to criticize my ideas, build upon them, etc, so I can  
improve upon my project as well 🙂

-Bryan Arant\> ----- Original Message -----

> From: [sdl-admin@libsdl.org](mailto:sdl-admin@libsdl.org) [mailto:sdl-admin at [libsdl.org](http://libsdl.org)]On Behalf Of  
> Cameron Matheson  
> Sent: Monday, January 28, 2002 4:43 PM  
> To: sdl at [libsdl.org](http://libsdl.org)  
> Subject: [SDL] Tile engine code
> 
> Hey,
> 
> I’m trying to write a tile engine… but i’m having lots of trouble (it  
> works  
> fine when I do sequential reads of my map, but random-access reads (which  
> are  
> the thing that matter it seems like?) don’t seem to work at all… If  
> someone  
> could point me towards some source code i could look at… that would help a  
> lot. (I would have posted my code to see if someone could help me, but it  
> doesn’t have any SDL yet (it’s all ASCII so far), and i was trying to keep  
> this semi-on-topic.)
> 
> Thank you very much  
> Cameron Matheson
> 
> * * *
> 
> Do You Yahoo!?  
> Get your free @yahoo.com address at [http://mail.yahoo.com](http://mail.yahoo.com)
> 
> * * *
> 
> SDL mailing list  
> SDL at [libsdl.org](http://libsdl.org)  
> [http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [January 30, 2002, 1:21pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/3 "2002-01-30T13:21:00Z")

</div>

> I’m going to be working on a tile engine soon (2D) and am just  
> currently working on the parser. Got that working well last night. Next  
> step is to get it tiling (Using SDL of course).
> 
> Here are my plans with tons of holes in it, because I have never done  
> this before, and don’t have anything set in stone yet.
> 
> I just plan on creating a class called TILE,

Problem 1: Be careful not to put frequently used virtual members it that  
class. Too much of that on the once-per-tile level can quickly impact  
total performance.

(BTW, you should probably name it tile\_t, CTile or something as “TILE”  
looks like a #define rather than a type… Either way, be concistent  
throughout your code! It helps. 🙂

> and while I’m reading the  
> file, I will just call a constructor which defines the tile. Then I  
> will add it to my linked list.

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.)

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.

> First line in my file format is the name of the tileset file I’m using.
> 
> tileset.bmp
> 
> And the rest of the file is where I load tiles, events, etc…

So it’s actually not just a plain map file, but a complete “level  
definition”…?

> So inside my file I define a tile like so:  
> tile:  
> 0  
> 0  
> 32  
> 32
> 
> Format is not set in stone, but the 1st and 2nd numbers are the x,y  
> locations on the screen 3rd and 4th are the x,y locations in the  
> tileset.bmp file.

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.)

As to the “screen coordinates” (I’d rather think about them as “map  
coordinates”), are they in pixels or tiles? (If they’re in pixels, I can  
see the point in your format. If not, I think a simple, traditional array  
of tile indices would be sufficient.)

[…]

> This should all be taking place inside the WORLD class which has  
> functions like LoadMap();  
> And I will have a linked list containing all the tiles so I can do  
> various stuff to it, like remove it, check values, or something of the  
> such.
> 
> Then I can have a draw function inside the tile class, things are  
> endless after that. Of course I have never done this before, but this  
> is my idea as of late.

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.)

//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](http://olofson.net) -'On Tuesday 29 January 2002 02:42, Bryan Arant wrote:

---

<div class="post-metadata">

**Author:** ![Bryan\_Arant](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/cab0a1/32.png) [@Bryan\_Arant](https://discourse.libsdl.org/u/Bryan_Arant)\
**Post date:** [January 30, 2002, 9:00pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/4 "2002-01-30T21:00:01Z")

</div>

> David Olofson
> 
> > Problem 1: Be careful not to put frequently used virtual members it that  
> > class. Too much of that on the once-per-tile level can quickly impact  
> > total performance.
> 
> I won’t have to use any virtual members in my tile class.
> 
> > (BTW, you should probably name it tile\_t, CTile or something as “TILE”  
> > looks like a #define rather than a type… Either way, be concistent  
> > throughout your code! It helps. 🙂
> 
> Noted!
> 
> > 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?
> 
> > 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?
> 
> > 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  
> 🙂
> 
> > 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.
> 
> > As to the “screen coordinates” (I’d rather think about them as “map  
> > coordinates”), are they in pixels or tiles? (If they’re in pixels, I can  
> > see the point in your format. If not, I think a simple, traditional array  
> > of tile indices would be sufficient.)
> 
> “Screen coordinates” was just a small typo. I did mean “map coordinates”  
> Sorry about that.
> 
> > 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.
> 
> //David Olofson — Programmer, Reologica Instruments AB
> 
> -Bryan Arant
> 
> * * *
> 
> SDL mailing list  
> SDL at [libsdl.org](http://libsdl.org)  
> [http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)
> 
> > ----- Original Message -----  
> > From: [sdl-admin@libsdl.org](mailto:sdl-admin@libsdl.org) [mailto:sdl-admin at [libsdl.org](http://libsdl.org)]On Behalf Of  
> > Sent: Wednesday, January 30, 2002 1:21 PM  
> > To: sdl at [libsdl.org](http://libsdl.org)  
> > Subject: Re: [SDL] Tile engine code

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [January 30, 2002, 10:22pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/5 "2002-01-30T22:22:01Z")

</div>

[…]

> > 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](http://olofson.net) -'On Thursday 31 January 2002 05:59, Bryan Arant wrote:

---

<div class="post-metadata">

**Author:** ![Gerry\_Jo\_Jellestad](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/919ad9/32.png) [@Gerry\_Jo\_Jellestad](https://discourse.libsdl.org/u/Gerry_Jo_Jellestad)\
**Post date:** [January 31, 2002, 10:49am UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/6 "2002-01-31T10:49:01Z")

</div>

> I won’t have to use any virtual members in my tile class.

That’s good, but be careful if the tile class gets little ones - non-virtual  
destructors may behave badly if they’re doing something important, in some  
cases.

[…]

> 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?

Depends =) See D.O.'s answer =)

[…]

> > 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
> 
> 🙂

I know the feeling - when i first started doing that little interface library  
of mine, SIF, i wanted it to be able to do _everything_. After a couple of  
rewrites and some good advice from (and rambling to =) David Olofson, i  
realized that designing something to fit everything is generally a bad idea,  
unless you’re very, very careful. It’s like designing an engine to fit cars,  
boats, airplanes, space shuttles, time machines, and multidimensional  
improbability/bistro-drive spaceships equally well =)

You’ll probably get the best results for designing your tile engine for what  
you need it for _right\_now_ (grass mower), and leave room for enhancements  
(interdimensional space-time controllers). After i started thinking this way,  
i’ve done much more progress on SIF (it’s still far from done, of course, but  
i’m feeling that i’m getting somewhere). Whenever i get an idea that could be  
implemented into SIF (which i do all the time), i don’t actually implement it  
right there and then. In stead, i put it into the back of my head, and keep  
it in mind while writing the API.

For example, in SIF, i need to calculate a “hitmap” of sorts of a surface.  
The hitmap is used for detecting collisions, etc. Right now, i’m planning on  
using it with SDL surfaces (whoa, we’re getting on topic!), but later on i  
might want to use it with other things, like fx. OpenGL textures. That will  
be no problem at all, because the only time i need to access the SDL surface  
is when actually calculating the hitmap - the hitmap calculator isn’t a true  
part of SIF, it’s just a tool to calculate the hitmap, which _is_ a true part  
of SIF. The hitmap can be calculated in other ways, SIF doesn’t care, as long  
as the hitmap is there. I’m not that good explaining, but hopefully you get  
the idea =)

[…]

> 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.

Different sized tiles in the same tilemap ? Be sure that you actually need  
that before you go on implementing it - there’s more than one way to do  
whatever it is you want to do, and the most advanced way is almost never the  
best. Really =)–  
Trick

* * *

Linux User #229006 \* [http://counter.li.org](http://counter.li.org)

“There is no magic” - Nakor, magic user

---

<div class="post-metadata">

**Author:** ![Bryan\_Arant](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/cab0a1/32.png) [@Bryan\_Arant](https://discourse.libsdl.org/u/Bryan_Arant)\
**Post date:** [January 31, 2002, 5:51pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/7 "2002-01-31T17:51:01Z")

</div>

> 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:
> 
> [Mixed Downloads](http://olofson.net/mixed.html)

Neato! \>:)

> Multimap? (I’m tired - long night of DOS-\>Linux porting…)

A multimap is a STL thingamajig. (Warning: Techy Term)

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

Nope. I thought of this already and thought, “No need”.

> No problem! (Can’t stay away from this kind of stuff. That’s how the  
> Scrolling Examples got written… 🙂

Hah.

-Bryan Arant

[I don’t have anything to brag about 😕]-----------------------------------------  
[Wait. “I have a kitty”]  
Mreow.

//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](http://olofson.net) -’

* * *

SDL mailing list  
SDL at [libsdl.org](http://libsdl.org)  
[http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [January 31, 2002, 6:56pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/8 "2002-01-31T18:56:01Z")

</div>

[…]

> > Multimap? (I’m tired - long night of DOS-\>Linux porting…)
> 
> A multimap is a STL thingamajig. (Warning: Techy Term)

Oh, sorry! 🙂

Well, I think you’ll need something with at least 2D “indexing” to be  
efficient.

For example, if we look at the implementation on a binary tree, it’s  
quite obvious how you’d go about looking up a specific node: Just start  
at the root node and chose the higher or lower branch depending on your  
value vs the node value, looping until you find your key. (Or the closest  
match, if applicable.)

Now, try looking for a node with _two_ values in a binary tree… In some  
cases you _can_ map a 2D space to 1D, but I don’t think it’ll work out  
well in the case of looking up tiles in a rectangular world with an even  
distribution of tiles.

However, it’s easy to combine the two node/target value comparisons so  
that you get 5 alternatives, including the “both equal” stop condition.  
Build a quadtree, and pick one of the four branches, or stop, depending  
on the outcome of the two tests.

Anyway, map[y] is pretty much as fast as it gets! 😉

//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](http://olofson.net) -'On Friday 01 February 2002 02:50, Bryan Arant wrote:

---

<div class="post-metadata">

**Author:** ![Rainer\_Deyke](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/r/a9a28c/32.png) [@Rainer\_Deyke](https://discourse.libsdl.org/u/Rainer_Deyke)\
**Post date:** [January 31, 2002, 7:56pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/9 "2002-01-31T19:56:00Z")

</div>

“David Olofson” \<david.olofson at reologica.se\> wrote in message  
news:mailman.1012532170.10837.sdl at [libsdl.org](http://libsdl.org)…

> Anyway, map[y] is pretty much as fast as it gets! 😉

Assuming that map is a plain array and not an object with an  
overloaded ‘operator’ (such as ‘std::map’).–  
Rainer Deyke | root at [rainerdeyke.com](http://rainerdeyke.com) | [http://rainerdeyke.com](http://rainerdeyke.com)

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [January 31, 2002, 8:17pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/10 "2002-01-31T20:17:00Z")

</div>

Yes, of course - I thought that was obvious, considering the context. 🙂  
(Operator overloading is just a “syntax trick”, and I was talking about  
algorithms.)

//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](http://olofson.net) -'On Friday 01 February 2002 04:52, Rainer Deyke wrote:

> “David Olofson” \<david.olofson at reologica.se\> wrote in message  
> news:mailman.1012532170.10837.sdl at [libsdl.org](http://libsdl.org)…
> 
> > Anyway, map[y] is pretty much as fast as it gets! 😉
> 
> Assuming that map is a plain array and not an object with an  
> overloaded ‘operator’ (such as ‘std::map’).

---

<div class="post-metadata">

**Author:** ![Bryan\_Arant](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/cab0a1/32.png) [@Bryan\_Arant](https://discourse.libsdl.org/u/Bryan_Arant)\
**Post date:** [February 1, 2002, 8:40pm UTC](https://discourse.libsdl.org/t/tile-engine-code/5928/11 "2002-02-01T20:40:01Z")

</div>

> Anyway, map[y] is pretty much as fast as it gets! 😉

You just have no idea what kind of knowledge you just sparked inside me  
head.  
Hah. I mean it to. I finally get why people chose an array like:

map[400][400]

over

map[800]

Duh 🙂

-Bryan Arant

//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](http://olofson.net) -'\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
SDL mailing list  
SDL at [libsdl.org](http://libsdl.org)  
[http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)