In generality, in older system languages like C, debug builds often zero-initialize variables, sanitizing them. Release builds usually leave them uninitialized. They are just how they are, whatever was in the memory. If something is depending on an initialized value then and it works in debug but not release, that is a possible cause. Not saying it is but have seen it plenty of times over the years.
Mmm, this issue isn’t the C compiler vs. debugger though, it’s the Dialog compiler vs. debugger… looks like Daniel did find back in mid-June that they’re generating slightly different IR for some reason…
Appears to be a scope problem as deallocation is happening in two different places.They are very far apart in debug v release. The thing being invoked looks like it is being done differently as well. invoke once v invoke tail once
A standard technique in C64 programming is to define multiple user-defined character sets, and swap them in and out. It’s not just a text game technique – it’s a standard way to do graphics for heavily graphical games, constructing the playfield out of 8x8 pixel tiles.
Having this available in the C64 Å-machine runtime would be very powerful. It would also take a significant amount of work, and would chew up memory that not every game would want to use, which would point in the direction of having two runtimes, and only use the multiple charset one where the game actually needs it.
It would be a really cool “nice to have” feature, though, enabling the use of whatever characters the author might wish to include, including potentially graphics for maps or signs or illustrations, and an entire italics font. (And perhaps bold and bold italics, though I’m less convinced that bold will work in an 8x8 bitmap.) A well-thought-out implementation could map some of the resulting characters back to graphics assets that the web interpreter could use when playing on the web.
It’s definitely not a “hack it in within the next month or so” thing, though.
Something I’d be curious about is to see if Dialog could be refactored as a C library that could be used from another engine such as Godot.
Theoretically possible, because of eval.c (the implementation behind the debugger). But I’m not sure I see the use case; a large part of Dialog’s elegance comes from how closely the language is tied to its I/O system.