@akkartik mhmm, it depends, I'd say time? But uxn just waits if a frame takes longer than expect so it's not really noticeable.
This week, people revealed in the mailing list that they were using fancy stashing techniques to spread logic over multiple frames, I realized that I was using the update vector for almost everything, and maybe I shouldn't do.. that-
I haven't written an application that was larger than 20kb yet, so not space.
@neauoire Do you use any dynamic memory? Like, lines.love is 40KB, but it usually allocates a few tens of MB.
With LÖVE I've been finding that CPU is plentiful -- as long as I don't use too much memory, overloading the GC.
@akkartik I've been seeing the words garbage collection flying around all day on here, and I went to look it up and I don't understand what they mean.
Is uxn garbage collected?
@neauoire @akkartik AFAIK uxn is fully non-GC, but that's also because it is fully programmer-managed memory anyway out of that static 64KB block.
the rough tl;dr is: in a language like C you call malloc() to get a block of heap ram at some given size, and have to remember to free() that ram later or it'll leak. in a language like, say, Lua, strings just "come into existence" as far as the developer is concerned, and the VM tracks its lifecycle (and calls free() for you when the string "dies")
@neauoire @akkartik the rabbit hole goes WAY deeper than that and there's countless strategies for doing it (refcounting, generational stuff, ORC/ARC in Nim these days, whatever), and there's also non-GC ways to do "pretty transparent" memory management that doesn't require manual malloc/free (RAII in C++ and Rust), but... Lua/Python/Ruby/JS/etc. all do GC and at the end of the day it's "basically" "somewhat" like what I described.
uxn has none of that, but you could in theory build a GC in uxn
