libtcod VS flatpak

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.

Hopping from one distro to another with a different package manager might require some time to adapt. Using a package manager that can be installed on most distro is one way to help you get to work faster. Flatpak is one of them; other alternative are Snap, Nix or Homebrew. Flatpak is a good starter, and if you have a bunch of free time, I suggest trying Nix.

No, it looks like you have to do it on an application basis.

https://github.com/flatpak/flatpak/issues/2913

Flatpak

> CLI tools do not implement auto-complete themselves. What you are seeing are auto-complete scripts for your shell that make network connections.

nit: This is incorrect. Robust auto-complete scripts call the actual program to provide completions.

That is what Flatpak does. It is Flatpak itself that makes the network connections.

https://github.com/flatpak/flatpak/blob/main/completion/flat...

Not that it would make any differencen if it was implemented in Bash seeing as the Bash script is also provided by Flatpak.

The only performance impact I know of is with the seccomp filter in CPU-bound tasks: https://github.com/flatpak/flatpak/issues/4187

Skimming through the recent comments, there might be a way to optimize some of it.