# On Tiles and Why We Don't Have Them (But we're progressing. Thanks utunnels)

**URL:** <https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197>\
**Category:** The Lab\
**Created:** [February 8, 2013, 6:02pm UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197 "2013-02-08T18:02:45Z")\
**Posts on this page:** 20\
**Page:** 5

<div class="post-metadata">

**Author:** ![LazyCat](https://avatars.discourse-cdn.com/v4/letter/l/ecc23a/32.png) [@LazyCat](https://discourse.cataclysmdda.org/u/LazyCat)\
**Post date:** [May 31, 2013, 1:16pm UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/81 "2013-05-31T13:16:09Z")

</div>

[quote=“utunnels, post:80, topic:197”]Nah, I just used SDL\_UpdateRect instead of SDL\_Flip for DrawWindow.  
As for performance, I’m not having slowdown issue, except when I was using visual studio’s debug mod (ultra slow).

I changed ttf code a bit though, caching glyph data at the beginning instead of creating a new surface for ever character draw.[/quote]

Even you are not aware what you actually did is what I said it should be done, which is not to refresh the whole screen when updating each of the game’s sub-windows. The fact it works without flipping the screen is because you don’t really have actual double buffer without hardware surface and full screen, so you can update arbitrary areas asynchronously as you do, and in that case SDL\_Flip is identical to SDL\_UpdateRect(screen, 0,0,0,0).

So you are really calling the same function as before, only this time you specify particular area of a game sub-window being currently refreshed and only transfer its content to video memory, which is exactly how it is supposed to be and as I said it’s saving quite a bit of CPU time, so if you measure the performances you will notice it’s at least 30% faster.

Now, if you get rid of the rubbish in getch() function you will again boost performance for almost as much. It’s not about whether the game runs fast enough for your taste on your computer, it’s about right and wrong. That the correct code comes with performance boost is just a natural bonus, but the real reason why the code you have there from vanilla build should be fixed is because it’s wrong.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 1, 2013, 2:00am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/82 "2013-06-01T02:00:54Z")

</div>

Alright, I’ve got the tiles stuff merged into that branch on my Github repo as well. It works, hurray :)! It’s also very janky, but I think that’s known and acknowledged.

The SDL pseudo-curses stuff, on the other hand, seems like it might be acceptable for mainline in its current state. So, I’ve gotten that submitted as a pull request, and we’ll see how it fares during code review.

---

<div class="post-metadata">

**Author:** ![utunnels](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/utunnels/32/81_2.png) [@utunnels](https://discourse.cataclysmdda.org/u/utunnels)\
**Post date:** [June 1, 2013, 3:12am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/83 "2013-06-01T03:12:19Z")

</div>

Maybe you can create another folder to hold the sdl project like that msvc10, so users have a option to build gdi version or sdl version.

I don’t what do you mean by janky. 🙂

Maybe item type can have an integer id like monsters so I don’t have to do a string search for every tile. It can be easily done in itype constructors by increasing a global type id value.

For example, according to mapdata.h, “t\_null” can be mapped to 0, “t\_mutpoppy” is (num\_terrain\_types-1), “fd\_null” is num\_terrain\_types, “fd\_acid\_vent” is (num\_terrain\_types+num\_fields-1) and so on.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 1, 2013, 3:59am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/84 "2013-06-01T03:59:21Z")

</div>

Creating a separate project file for the SDL version is entirely possible, but also not really my field of expertise. It’d probably be pretty simple, though.

> [@utunnels](#):
>
> I don’t what do you mean by janky. 🙂

Ugly stuff which may or may not be a hack, in this case.

Which is not necessarily YOUR fault, of course ;). It would, as you say, be really nice if there were a better way to handle associating tiles with entities.

---

<div class="post-metadata">

**Author:** ![utunnels](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/utunnels/32/81_2.png) [@utunnels](https://discourse.cataclysmdda.org/u/utunnels)\
**Post date:** [June 1, 2013, 4:54pm UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/85 "2013-06-01T16:54:53Z")

</div>

> **[Cataclysm-DDA-sdltile.7z](https://www.dropbox.com/s/r35pnekirwxy9m9/Cataclysm-DDA-sdltile.7z)**
>
> Shared with Dropbox

I updated with my previous idea. Now every itype has an unique iid that can be used to map tile. Gfxwindow.cpp now uses a vector instead of map to store tileset infomation so it should be faster on rendering.

There isn’t much to do now I guess. Maybe a pixel artist will be wanted if this goes offical someday, because most of the pictures I’m using to test the code are taken from nethack and dwarf fortress.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 2, 2013, 2:03am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/86 "2013-06-02T02:03:18Z")

</div>

What exactly did you change this time around? You’re using a different base version than I am, which makes it hard to see exactly what’s going on. Was it just gfxwindow.cpp and the iid field in itypes.h that changed?

Now, as for using those iids… hmm, it looks like those IDs are being assigned entirely at run-time, which is good. I was worried that you were doing something silly like using implementation details in the tileset data file :P. I’m glad to see that you’re not.

I’d much prefer to avoid the current random-arcane-index method of assigning tiles, though. Rather than giving itypes (etc.) an arbitrary iid field, I think it would be good to let them store a direct reference to the tile they’re using. That would make things a lot more readable and maintainable, I think.

There’s also some more clean-up that would be good before considering this for mainline, but it is nice to have what you’ve currently got as a starting point.

---

<div class="post-metadata">

**Author:** ![utunnels](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/utunnels/32/81_2.png) [@utunnels](https://discourse.cataclysmdda.org/u/utunnels)\
**Post date:** [June 2, 2013, 2:38am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/87 "2013-06-02T02:38:57Z")

</div>

Changes? Yeah, it is based on the version I was using last time. I added iid property and a static counter itype\_index in itype.h

[quote=“itype.h”]struct itype  
{  
static int itype\_index;  
int iid;  
…  
itype() {  
iid = itype\_index++;  
…  
itype(std::string pid, unsigned char prarity, unsigned int pprice,  
std::string pname, std::string pdes,  
char psym, nc\_color pcolor, material pm1, material pm2, phase\_id pphase,  
unsigned short pvolume, unsigned short pweight,  
signed char pmelee\_dam, signed char pmelee\_cut, signed char pm\_to\_hit,  
unsigned ptechniques = 0) {  
iid = itype\_index++;[/quote]

> [@itypedef.cpp](#):
>
> int itype::itype\_index = 0;

[hr][hr]

> [@Soron](#):
>
> I’d much prefer to avoid the current random-arcane-index method of assigning tiles, though. Rather than giving itypes (etc.) an arbitrary iid field, I think it would be good to let them store a direct reference to the tile they’re using. That would make things a lot more readable and maintainable, I think.

I know, but there are many types other than items. It will be a war on many fronts if those unreleated types all use tile references.  
I see even monsters have their unique integer id for the reason it will be easier to write AI code, items, on the other hands use string id which make them easier to mod I guess.

If all of them (terrain, field, traps, monsters, items, etc) are defined in json files and open to modders, it will be more reliable to add a tile entry to the json files. For now I just feel it is more practicable if tiles use a more independent module.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 2, 2013, 2:48am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/88 "2013-06-02T02:48:08Z")

</div>

Oh, I’m fine with keeping the tileset information in a separate data file, I was referring more to the internals. I’d much prefer doing something like item\_ref.type-\>tile, or terrain\_ref.tile, rather than tilemap.find(foo) or the new vector-based approach.

Basically, it seems suboptimal to have constant look-ups in a vector or map. The vector-based approach used a chain of calculations that will probably slow things down, and means we’ve got more magic numbers; and the map-based approach relies on string lookups. And both of them involve a bit of indirection which doesn’t necessarily make sense.

Now, what IS beneficial is the fact that it lets us keep the tiles code a bit more localized, but I think it would be better to have, say, a visual\_representation struct that’s set as either a character-fgcolor-bgcolor triplet, or a fgtile-bgtile pair, depending on an “#if (defined TILES)” check.

---

<div class="post-metadata">

**Author:** ![utunnels](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/utunnels/32/81_2.png) [@utunnels](https://discourse.cataclysmdda.org/u/utunnels)\
**Post date:** [June 2, 2013, 3:28am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/89 "2013-06-02T03:28:45Z")

</div>

Yeah, I see.  
Almost all renderable(or printable) elements have a sym property, some others are hard-coded for animation or multi-states(like car door).  
Maybe that sym can be expanded to a struct like you said (bg, fg, animation, etc).

But I don’t know if I still have the desire to code, as you see, I’m more of a player than a coder so my original purpose was to create a tile window that can help me on gameplay. I really hope you guys can make an official tile feature. 🙂 I’ll sit back to play I guess, but I’m always glad to help if you need a hand and there’s still something I can do.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 2, 2013, 4:18am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/90 "2013-06-02T04:18:36Z")

</div>

Alright, fair enough. You’ve still given us a useful starting point, and I think the ASCII-based SDL version might be merge-worthy, even if the tiles support needs a bit of work still. Thanks for what you’ve done :).

---

<div class="post-metadata">

**Author:** ![utunnels](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/utunnels/32/81_2.png) [@utunnels](https://discourse.cataclysmdda.org/u/utunnels)\
**Post date:** [June 2, 2013, 11:09am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/91 "2013-06-02T11:09:25Z")

</div>

Ah ha, I think I solved the font size problem. I thought the size was in points, but it’s actually in pixels.

Old code:

```
font = TTF_OpenFont(typeface.c_str(), fontheight*72/96+1);

```

Correct code:

```
font = TTF_OpenFont(typeface.c_str(), fontheight-1);

```

For some reason, -1 is requierd for the default 1 pixel extra space.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 2, 2013, 11:28am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/92 "2013-06-02T11:28:27Z")

</div>

Ah, cool :). It looked like the font’s weirdness was due to being sized incorrectly, or perhaps being sized smaller than the font is designed for.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 3, 2013, 3:03am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/93 "2013-06-03T03:03:12Z")

</div>

Wow, that makes things so much better. THanks for spotting that!

---

<div class="post-metadata">

**Author:** ![utunnels](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/utunnels/32/81_2.png) [@utunnels](https://discourse.cataclysmdda.org/u/utunnels)\
**Post date:** [June 3, 2013, 4:27am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/94 "2013-06-03T04:27:10Z")

</div>

Another thing that makes sdlcurse different to catacurse is keycode logic.

Old  
else if ( (ev.key.keysym.unicode & 0xFF80) == 0 ) {  
lastchar = ev.key.keysym.unicode & 0x7F;

Should be

```
		else if (ev.key.keysym.unicode != 0 ) {
			lastchar = ev.key.keysym.unicode;

```

There is no need to filter non-English characters.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 3, 2013, 4:42am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/95 "2013-06-03T04:42:56Z")

</div>

Ah, that makes more sense… I had previously tinkered with that line, because we were having issues with shift events being passed on to getch() (even though getch() is supposed to ignore stuff like shift). But your version is more sensible, AND means that non-ASCII characters should work, if/when we get around to making the code unicode-compatible.

---

<div class="post-metadata">

**Author:** ![utunnels](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/utunnels/32/81_2.png) [@utunnels](https://discourse.cataclysmdda.org/u/utunnels)\
**Post date:** [June 3, 2013, 5:00am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/96 "2013-06-03T05:00:16Z")

</div>

Hmm, if you downloaded the latest file, shift / control should be parsed. My old demo used to have that issue but I fixed it quickly.  
I also double checked your github code and yes it is already fixed.

I haven’t checked alt keys, but maybe I should.

```
		else if(ev.key.keysym.sym==SDLK_RSHIFT || ev.key.keysym.sym==SDLK_LSHIFT || ev.key.keysym.sym==SDLK_RCTRL || ev.key.keysym.sym==SDLK_LCTRL)
		{
			break; // temporary fix for unwanted keys
		}

```

The reason to remove 0~127 check is I saw that kickstarter topic, perhaps some non-English keyboard will have problem if only 0~127 are accepted.

---

<div class="post-metadata">

**Author:** ![utunnels](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/utunnels/32/81_2.png) [@utunnels](https://discourse.cataclysmdda.org/u/utunnels)\
**Post date:** [June 4, 2013, 9:03am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/97 "2013-06-04T09:03:11Z")

</div>

Hi Soron, you said you make the makefile compatible with linux. But I have a question.  
Doesn’t linux environment needs freetype lib? [http://packages.debian.org/search?keywords=libfreetype6](http://packages.debian.org/search?keywords=libfreetype6)

I don’t see -lfreetype or something like that in your makefile.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 4, 2013, 9:15am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/98 "2013-06-04T09:15:06Z")

</div>

Well, it compiles and links and all on my system, for some reason. Not sure why I didn’t need to explicitly link against Freetype; maybe SDL\_ttf takes care of that or something? Or maybe Freetype is standard for native Linux compilation, but not WinGW-based stuff?

However, someone else needed -lfreetype to cross-compile it for Windows. I’ve got a separate branch with a bit more clean-up that’s been submitted as a pull request to the main repository - THAT branch has the -lfreetype bit in there, and all.

---

<div class="post-metadata">

**Author:** ![rokomata](https://avatars.discourse-cdn.com/v4/letter/r/35a633/32.png) [@rokomata](https://discourse.cataclysmdda.org/u/rokomata)\
**Post date:** [June 5, 2013, 4:56pm UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/99 "2013-06-05T16:56:00Z")

</div>

Hey there fellows…

How are things coming along? I’ve been keeping track and so far I’ve liked the good news that has come down from relevant folks like utunnels and the rest of the gang on whether tile support is still being worked on. Here’s hoping that the next entry in Cataclysm’s version history will contain some.

---

<div class="post-metadata">

**Author:** ![Soron](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.cataclysmdda.org/soron/32/885_2.png) [@Soron](https://discourse.cataclysmdda.org/u/Soron)\
**Post date:** [June 6, 2013, 1:42am UTC](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197/100 "2013-06-06T01:42:23Z")

</div>

Well, the SDL text version got merged into mainline, and I’d like to provide both the classic Windows version and the SDL Windows version when we release 0.6 (so that people can try them out, and we can get feedback on any differences).

We don’t currently have any tiles support that’s suitable for general use, and that’s unlikely to change before 0.6 is ready. I don’t know when we’ll have that, but having SDL support at all certainly helps us along that path.

[Previous page](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197.md?page=4)

[Next page](https://discourse.cataclysmdda.org/t/on-tiles-and-why-we-dont-have-them-but-were-progressing-thanks-utunnels/197.md?page=6)