glsp VS libtcod

3. Typed Racket

I almost used https://gamelisp.rs/ for a project but the nightly feature it needs broke and it's no longer maintained, glad to see something similar arise! You might want to consider adopting their choice of VecDeque as a list replacement, I think it makes a lot more sense than naive linked lists on modern machines.

Varied employment history has left me with great soft skills and a broad grab-bag of technical skills, mostly leaning towards high-performance systems programming. Major solo projects have included the scripting language GameLisp, a 2D game engine, and a novel computer vision library.

"Gamelisp is a scripting language for Rust game development." Feature list from the page: No garbage collection pauses (runs gc once per frame), Seamless Rust API, Memory-safe, Feature-rich ("Pattern‑matching, iterators, coroutines, macros..."), Easy entity scripting.

I'm using Rust to build a host program, and the actual game logic written in GameLisp on top of the bracket-lib. I only have superficial knowledge of Rust, 0 lisp experience, and never embedded a language before, so that's a lot to learn and implement at the same time.

I'm not sure I'll go to the end of the 8 weeks, but I'll make that as fun/interesting as possible and (try to) use GameLisp!

I feel qualified to answer this! GameLisp was once implemented with highly unsafe code, but later on I reimplemented it using only safe code, with a very small amount of optional unsafety behind a feature flag. GameLisp's performance is currently somewhere between Lua and Python when unsafe code is switched on, or a bit slower than Python when unsafe code is switched off.

It took a lot of wrestling with the type system, but I've managed to wring out several API improvements for version 0.2. I already considered GameLisp's Rust API to be best-in-class, and this release polishes it even further:

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.