|
Top-level
 @ritualdust there is not "spritesheet" for this, instead what I'm doing is leaving a bunch of space in memory to put sprites temporarily. When I enter a room, I go read a length of data from the oquonie rom that is beyond the size that is addressable(like, beyond the maximum 64kb of a rom) and put the assets in addressable memory while I'm in the room. I'm not sure if that means anything to you, but imagine that I build new spritesheets for each room that I enter :) 9 comments
@autumnull @ritualdust the file device can stream for a length of X, if I keep that value on the stack I can know how far I've seeked. If I seek 100 times for a length of 0100, then I've gone beyond the limits of the memory  @neauoire Wow, sounds like the File device we discussed back at https://lists.sr.ht/~rabbits/uxn/%3C20220604142148.1299.43328%40mail.envs.net%3E#%3C20220620212427.dshot2ydu6tgxxpd@mutt%3E would be very helpful here, to improve random access performance an awful lot! I've always been curious with Oquonie whether the same partial loading approach needs to be done with code, too. I've been working on loadable module support recently, so that could help too 😊 @alderwick I'm trying to build oquonie with what we already got, and when I reached a point when I need to optimize maybe we can see which approach is the most painless :) @neauoire Just to be clear, since I mentioned both at the same time: the loadable module support is already using just what we have already. The J?I instructions have been instrumental in making it happen, so this is exciting new work! @alderwick Oh! yes, sorry I meant the seeking. I don't think I'll have to stream actual code for this. So far the oquonie core is only 2000 bytes long, but the world object will be pretty big so we'll see! js: https://github.com/hundredrabbits/Oquonie/blob/master/desktop/sources/scripts/core/world.js#L22  |
Gregory's Server
@neauoire @ritualdust :0 how do you read beyond the addressable size?