I 'll definitely help you out.
I’m pretty sure its not the library. If you’d like to somehow share the code with me (absolutely confidentially if you want) I’ll check out the problem and remove it for you.
4 Likes
I’m sure that this won’t come as much of a surprise, but hardware limitations have made me realize that I need to cancel this project. If I want a good gameplay experience, I don’t have enough room for the game in the Pokitto’s RAM. Don’t worry – I’ve got some other projects planned for when I’m not so busy with school, including a platformer 
Sorry, everyone. I might come back to this eventually if I come up with a way to reduce the size of the game, but at least for now, I can’t.
I think this project is far too interesting to just drop.
You’d be surprised what a person who knows how to optimize can do to that problem. For example, are all of your arrays byte arrays (instead of arrays of bits)? In my experience, people who have never programmed on limited hardware don’t really understand how to work around the issue.
How about instead of abandoning the project, give me access to the code, let me see what can be done? If you’re afraid to show it for stylistic reasons, you should not be. I make horrible (but fast) code.
4 Likes
Are you currently ‘chunking’ the world?
(Splitting the world into chunks.)
As @Jonne says, there’s most likely places where you can save RAM using techniques you haven’t discovered yet.
3 Likes
There is a lot of techniques for saving RAM indeed.
- Storing your tiles in less bits (as suggested by jonne).
- If you have 16 differents tiles, you only need 4 bits.
- This requires working with MASKs thought and might be reserved to the technique below.
- Close/Far Chunks:
Define a Chunk by a map area slightly greater than what you can see on a screen at the same time. (Caution, if you can put 8 whole tiles, that means you can see at most 9!).
The 4 closest Chunks are always ACTIVE. They use BYTE for each tile. You use them for drawing, interacting, etc. Find the 4 closest Chunks is simply done with a MOD operation.
When a Chunk is outside of the 4 closest ones, it goes into INACTIVE mode. There you can compress them using variety of techniques:- Less bits per tiles.
- RLE compression (you know when you have to say AAAAA, you just say 5 A? that’s the same principle).
- Store updated tiles only.
- This requires a procedural generation in place which can work for a lone Chunk.
- When making a Chunk INACTIVE, you call your Procedural Generation to generate a temporary Chunk, and you store only the tiles that changed. If none changed, you’ve got nothing to store!
- When making a Chunk ACTIVE, you call your Procedural Generation to generate the tiles, then you patch it with the additional updated tiles. If the Chunk doesn’t exist, it’s OK!
- If done well, untouchable area like seas will never be saved!
Additionally, for the Close/Far Chunks technique, you could also write them in your file when they become INACTIVE. If done well, you could have an almost infinite world to play with in your pokito, all stored into file!
3 Likes
Interesting to read !
Btw. There is already a support for reading, storing and drawing RLE-bitmaps in limited use cases. That needs to be extended thought.
1 Like
Btw, Pixonia can handle 50x50 maps with deformable terrain height & type, entirely in RAM.
Nobody has managed to play up to those levels though
2 Likes
This was one of the games I was itching to play too.
1 Like
is there a demo of the game?
1 Like
Unfortunately no. I couldn’t get the game to run on hardware due to how bad at programming I was back then so I decided not to release it. I haven’t started developing the remake yet (too busy with college) but hopefully I will soon and will be able to release the first alpha fairly quickly!
2 Likes