@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'm not sure what dynamic memory means, for example, drawing a line segment is a 40 some bytes routine, and I use 5 shorts of memory to keep stuff in memory while the routine happens:
https://git.sr.ht/~rabbits/catclock/tree/main/item/src/catclock.tal#L155
@akkartik Oh, yes we use calloc to create the memory for the screen pixels!
@akkartik And the 64kb+3 pages of ram: https://git.sr.ht/~rabbits/uxn11/tree/main/item/src/uxn11.c#L235
@neauoire It's the equivalent of malloc in C or ALLOCATE in Forth. It's different from the stack in that you don't have rigid constraints on the order in which things are reclaimed.
I'm going over the Uxn opcodes now. I'm pretty sure you must have it for at least some esoteric purposes..