Beleriand VS libtcod

This week I had what I hope was a moment of clarity about the Beleriand map. Previously it was pretty big; 12x15 map grids, each map grid 49x49 miles, each square mile 10x10 chunks, each chunk 22x22 game grids, which made a grid notionally 8 yards on a side. But I've been feeling for a while that that is too big for adjacent things to be in contact. So I considered what would happen if I cut that size down to 2 yards on a side. I was happier with that size in terms of realism, but it does multiply the number of total grids in the map by 16, and there were already 20 billion. What to do?

I have done some "wilderness generation" in FAangband by having a base type of terrain for each biome type, and then adding "formations" (random groups of selected other terrain types) and then maybe some other areas (grassed clearings in forest, for example). FAangband has discrete wilderness levels, so the scaling/zooming doesn't apply. I am, though, coming up against similar problems to yours in Beleriand, which has a fixed world map with set biomes at the top level, but has to fill in all the terrain in a natural way. Note that Beleriand is still in its very early stages.

libtcod | GitHub | Issues | Forum | Changelog | Documentation | Template

Libtcod itself uses SDL2. It maps tile glyphs to a texture atlas and maps Unicode codepoints to tile positions. Then it has another data structure called a console which has the background color, foreground color, and codepoint for each tile on that console. It then uses SDL_RenderGeometry to quickly render the background and colored glyphs to an SDL texture, skipping unchanged tiles as an optimization, then renders that texture to the window. The C99 source is here: renderer_sdl2.h renderer_sdl2.c, a C++ version would surely look better.

libtcod has always been a favorite of mine. Does a lot of things to zero fanfare outside the indie roguelike scene.

I've ended up recovering the old 1.3.2 to 1.5.0 builds of libtcod. You can find them on the GitHub releases page. Most of, maybe all of the other places which had these builds are down, but thankfully Jice still had copies of these builds.

FoV is a port from C -> Java of the algorithm found here

libtcod | GitHub | Issues | Forum | Changelog | Documentation | Template

Hey man, I don't wanna piss in your cherrios if you're intentionally doing it all the hard way, but you know about tcod right? https://github.com/libtcod/libtcod/

Browsing the repo, looks like it has a full C only API, https://github.com/libtcod/libtcod/blob/master/src/libtcod/libtcod.h

libtcod support for terminals is in progress at least for ANSI true colour, and I have a minimal compatibility layer for UNIX only.