Hey again. Some new things in this update! * Platforms work! It took a little bit of code to get them to work as expected, but now they function to impede downward motion for entities while encouraging non-opacity for upwards velocity. In short, they do what platforms do. * While there's no enemies or hurtful terrain to worry about, there is a full four-layer stage to explore! Each stage will be somewhere around this size. I'm barely beneath the compression cap (which I didn't know was a thing until tonight) which will cause me to have some serious issues with optimizing short-term. Platforms use sprite flag 6, or [& 64]. The use of sprite flags have made it much easier to handle map collision data by associating the sprite IDs with these attributes. While there's only 8 flags to work with, they can be used as categories for further fine tuning with actual sprite IDs. Sprite flag 0 always serves as solid collision detection on the map. * Stage layers are decompressed (foreground and background) from a cheap and simple compression method which simply states [tile][amt] in hex. For example, the first stage layer starts off with "1204 b108" which means from the topleft of the stage area, it first places four tiles of ID of 18 (blank transparent). It then places adjacent to it eight tiles of 177 (bricks). This compression method, while simple, cuts the level data down to 1/3 of the usual size, mostly. If there's lots of the same tiles banded together horizontally, the compression method works extremely well. Stage 1-4's BG layer uses a gradient which makes it looks like this when compressed: "13388738883889388a388b388c70" This covers the entire 56 by 8 tiles of the background (16 by 8 tiles are not saved because the first and last 16x8 tiles for both the foreground and background are exactly the same to give the illusion of the looping mechanic). * Current cart stats: 8103/8192 tokens 49955/65535 chars 98% compressed size As you can see, I've pretty much hit the limit on both tokens and compressed size. I didn't think that I would need to worry so much about the third one, but it looks like even comments add to this percentage. I could very well be at the limit of the cart's virtual space and will need to look for some compression methods. This is the fun part! There are a lot of things which could be simplified. * One thing I didn't think I would have is extra map space. I'm actually not using much of it at all. A lot of the space was going to be used for world slices and make maps out of those. It may be something to resort to in the future, though. I want to keep all the data on a single cart and not feel like I need to load anything from an external file. However, should I need to utilize multiple carts for this game (kind of like multiple CDs for games back in the day), it may be an option. That's all for now! - Goober |
The sleek graphics and palette are reminiscent of the handheld games of the past.
The visual scenes at the start are very cool, and it seems like they've been given a lot of technical touches.
Looking at this game in the middle of production, I expect it to be a big one to make in PICO8, probably.
The easy solution to capacity is a multi-cart.
But you should be aware that the "reload()" of data between carts will not work in BBS.
I'm looking forward to completing the game!
Hey, thanks! We'll see how this goes. I've got a nasty habit of not completing stuff, so we'll see how progress goes over time. Right now I'm combating pico-8's limitations to make enough token room for enemy AI and interaction.
Thanks for the encouragement!
[Please log in to post a comment]