was8bit 2019-06-23 08:35 (Edited)
Testing saving a full background, it seems to work :)
anyone with TESTFLIGHT please verify, thanks :)
NOTE: the PEN and ERASURE quietly swaps each time you lift your finger from the screen, so you cannot tap, you must drag draw, or drag erase... if nothing is showing up you are in erase mode... just a quick test so simple tools....
was8bit 2019-06-23 08:38
I like the new community button, very nice :)
.. am sad to see the PERSIST memory limited to 256K.. tried storing a whole background :( also, didn’t see a PERSIST command in the help section? Abit confused,....
Timo 2019-06-23 08:43
ROL and ROR are quite funny, aren’t they? ;)
Timo 2019-06-23 08:49
Persistent RAM is a low-level feature only, still. There won’t be a way to set own variables to PERSIST, but I will probably add a special array mapped to persistent memory.
Hm, I’ll think about increasing the size. But I’m not sure if storing a BG is a real use case. Tools should still use files for this.
Timo 2019-06-23 08:50 (Edited)
It’s 256 bytes, not kilobytes.
was8bit 2019-06-23 11:05 (Edited)
Urp.... sleepy mistake... 245 bytes .... would need $800 to capture whole screen...
I rather like ROL ROR :) ... think of the possibilities :)
... hmmm... maybe something similar to characters... what i mean is if it was arranged like the character set, then a BASIC command for storing a value into an “array” with 256 entries, each entry capable of storing a number 0-255..
So, PUT a,n meaning put number n into array slot a
GET a meaning retrieve the stored number from array slot a
So i could write PUT 0,SCORE to save my game SCORE into memory slot #0
SCORE = GET 0 to reload my score from PERSIST memory
Any attmpted value above 255 would be set at 255, and any value below 0 would be set at 0...
The total amount of needed memory for this scheme would be 4KB just like character memory... coincidentally it would also be enough space to store BOTH backgrounds into PERSIST, which would be GREAT for making games that used the backgrounds as storage for the game... say, like a sim city styled game where you would want to store the city’s developement so player could add to the city over the course of several days of play...
was8bit 2019-06-23 11:10
Possibly for a simcity styles game, a command like PUT BG 0 to save the whole BG 0 to the first half of PERSIST and GET BG 0 to reload from PERSIST the whole BG 0... same for BG 1...
was8bit 2019-06-23 11:13 (Edited)
I would TOTALLY be interested in developement games similar to simcity !!!! ;) I know most people seem to prefer shoot ‘me up type games....
Remember from original lowres, my game OUTPOST: MULE (space colony simulation) got 25 downloads and 3 likes..
Whereas, my Tank Patrol - Den kō sekka got 94 downloads and 10 likes..
Shootemups are more popular to strategybuilds 3:1 !
Timo 2019-06-23 11:14
No need for special commands (GET/PUT) to access the memory, it would just work like an array with a special name, e.g.:
But I would make them like number (float) variables, each number would occupy 4 bytes. For low-level byte access you could still use PEEK and POKE.
I'll still think about the size.
was8bit 2019-06-23 11:17
I like your PERSIST approach better :)
... yesh... yesh! More memory ! ;) 2k or 4K would be totally awesome!
was8bit 2019-06-23 11:29
... here is a question, how to store something to PERSIST like a player’s name??
Timo 2019-06-23 13:40
Of course you could store a string byte by byte manually. I’m thinking about a simpler way, not sure about the approach yet.
was8bit 2019-06-23 14:02
How about this...
“IF” PERSIST memory was 4K, then on one hand one could manually use to save BG 0 and BG 1
But for normal use, the 1st 2k could be reserved for number storage with PERSIST(n) = v while th 2nd 2k could be reserved for string storage with PERSIST$(n) = “name”
Additionally, i would limit all strings to 8 characters... or maybe 16 .... either way a set length will allow for an easy array system...
Mrlegoboy 2019-06-24 17:26
Only 256 bytes? You’re gonna make me do a no-no and use Disk as persistent memory. Also, can i try the testflight?
Timo 2019-06-24 17:35 (Edited)
Ok, actually 4 KB is exactly what still fits into the memory map. Maaaaybe I'll use it.
I was thinking about the array stuff. Storing numbers and strings and other data is not only interesting for persistent RAM, but also for working RAM (e.g. for files) and to read from ROM entries. It would be stupid to make a custom system for only one of them (or one for each).
In the end it's all binary data accessible with PEEK/POKE. So I think I'll just add some more commands to access memory. Not only for bytes, but also for 16- and 32-bit values. And maybe one for accessing strings with a fix length directly in memory.
This way I will keep it low-level and you'll have to understand the system a bit, but actually that's the point of NX. I don't want to hide all the technical details.
Timo 2019-06-24 17:40
Mrlegoboy: I can add you to TestFlight. Should I use the e-mail address you used for the registration here?
Mrlegoboy 2019-06-24 19:32
Yes please and thank you
was8bit 2019-06-24 20:46 (Edited)
@TIMO that sounds cool.. I’d be totally stoked if it can be 4kb
Mrlegoboy 2019-06-25 19:41
Lowres galaxy 2 is pretty kick-ass
Timo 2019-06-25 20:06 (Edited)
Thanks :) Actually I play it quite often. I think my high score is around 17000.