SDL VS libtcod

Best comment:

> SDL is not your tool for "signaling to stakeholders" about what is important.

Zing. https://github.com/libsdl-org/SDL/pull/9345#issuecomment-201...

Correct. It's explained here:

https://github.com/libsdl-org/SDL/pull/9345#issuecomment-201...

XWayland has special hooks into the compositors that normal wayland clients don't get.

https://github.com/libsdl-org/SDL/blob/main/include/SDL3/SDL_events.h

If that app ran in a 640x480 mode, memory accesses would be just as fast as the VGA applications 25 years ago, correct?

I think there's a lot more going on than that. Here's SDL's current pixel access code:

https://github.com/libsdl-org/SDL/blob/main/src/video/SDL_su...

It's not that difficult, I recently started learning to use graphics APIs myself. OpenGL is for linux, etc., directx for windows and vulkan for all platforms. I read through a bunch of forums yesterday and decided to go for vulkan (here is a link to the sdk) for my next small projects because it can run on all platforms. I would recommend to watch a basic tutorial series (like this one) for the graphics api itself to get an understanding of whats going on. And on top of that I use SDL2 for eventhandling and ImGui for the graphical user interface. Here is a link to a guide for setting up vulkan on your platform in case you would go for it.

SDL (which will be bumped to SDL3), straight from the authoritative https://github.com/libsdl-org/sdl

If I have the the skills and expertise: I could theoretically build a simple input remapper none using SDL (Steam Input relies on it) or JoyShockLibrary as a way to handle much wider Controller Support (otherwise: it would've been far more difficult to get Input API working across major Controller Types without documentation or reverse engineering).

2)Get SDL into ~/Library/Frameworks/

That is a weird one... I guess there could be an option to ignore the numpad - but I doubt anyone would find it. I raised an issue anyway https://github.com/libsdl-org/SDL/issues/7805

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

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

The github repo says it is half C, half C++. The important thing to realize is that C++ was written on top of C, with the main new feature being classes/OOP. There is a ton of overlap between the two languages, and it is easy to mix them within the same program. If you want to stick to writing pure C yourself, you could follow a C++ tutorial and port the OOP concepts to procedural ones.

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