Originally published at: Help someone finish the Commodore 64 RPG they started making when they were a kid 40 years ago | Boing Boing
…
3 Likes
So do we all have to purchase C64’s in order to play it?
Nope.
Emulation is your friend.
6 Likes
I have a couple of them kicking around somewhere and am open to offers.
1 Like
He has already figured out one memory-saving fix, setting a single bit to define each wall space (wall, open door, closed door, secret door) rather than the two-bit system he originally devised.
I had to know how he magically figured out how to represent 4 states with a single bit, and after watching the video, he actually went from 2 bits to 1 byte (8 bits). So he’s actually using more memory now, not less. However, it is allowing him to do more interesting things per space of dungeon than before, at the cost of lowering the max dungeon size.
7 Likes
I’m surprised he didn’t go with a nibble. 15 values with 1 reserved would be plenty and save you the memory. With one reserved, if you decide you need more you can use the reserved one for “check lookup table” for way more possibilities if needed.
2 Likes
Thank you for doing the research on that one, that bugged the hell out of me. 
4 Likes
I would LOVE to know a way to do that. In reality the plan is to use 1 BYTE for each space. 3 bits each for the north and west walls, 1 bit to track if the player has ever seen that space, and one bit to track if there is anything of interest on the space like a monster, item or dungeon feature. Those would then be tracked in lists. If the east or south wall is needed then the adjacent space gets checked.
It was using 2 bits per wall and there was only 1 byte per 2 spaces (in a checkerboard pattern) stored.
Oh and it should run fine on the free VICE emulator which is a piece of cake to set up.
2 Likes
I was thinking a nibble per wall, which comes out to your byte per space (amortized), so no difference.
1 Like
I didn’t read the article, but I’d expect a bit per wall segment, one byte = 8 walls. Then, a separate byte for each feature that could be on the wall, again, with one location per bit. Then you could determine whether a feature was present by ANDing them. Maintains one bit per feature with no waste if the wall positions per map are divisible by 8.
A lot of things are going to be mutually exclusive, you’d save memory with enumerations over flags. ie something is only one of closed door / open door / secret door, no need for 3 bits.
2 Likes
This topic was automatically closed after 5 days. New replies are no longer allowed.
