@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?
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 @klardotsh has been quite delightful learning that you learned about garbage collection today :) a constant reminder of how unpredictably varied folks exposure is to... everything.
as far as i can tell the go-to uxn approach is to statically allocate however much memory you think you'll need?
you could write a heap allocator or GC for uxn, and it may be useful if you wanted to do something with dynamic needs; variable size level + variable number of enemies in a game for eg
@neauoire @akkartik @klardotsh for the most part in 64k there's just not _that_ much room for heavily dynamic requirements, so you just don't do it. might farm it out to the disk instead and use files as dynamically sized records.
slightly funny; if you went down the lisp route rather than the forth one you'd almost certainly had to write a GC right at the start, as it's pretty fundamental. but you wouldn't have written an assembler, probably. different challenges in different spaces.
The difficulty with automatic garbage collection in uxn is that it is not clear when something can be collected, because there is no lexical scope. For my cons lists, right now I don't delete them at all, but if I did it would be via a "delete" or "free" call; and in a similar way I would coalesce with an explicit command as well, as it is a very expensive operation.
Once I have cracked the problem of cons lists in my lamdbas, maybe I could use the lambdas as lexical scope and have proper garbage collection. Sounds interesting.