This approach saves a ton of memory. and works on the Gamebuino Consoles too (which don't actually have a built-in tileset feature at all, it's all sprites anyway). Should be able to copy my Sim-City style roads then. excellent.
This is awesome code, but I want to see a more advanced version of this code, where it is a function that defines regions of a map (as opposed to hard-coded), so it can be reused for other materials (like rock, wood, or brick). and maybe random variants as well
I did use a more advanced version of this for another project that included multiple materials as well as slopes. Maybe I could do a tutorial for a more generalized method. Thanks for the idea!
Should make it possible to adopt a meta level design as well. Like, save some tiles for defining the actual level layout in 8x8 chunks. Then use a big map area that you re-use for each level, design the levels with the 8x8 blocks somewhere else on the map. Effectively the map limit in Pico is 128x32 if you need all tiles... if you use pixel colours on blocks to define the sprites, then use the auto-siding technique, you could have very complex, large maps. So the pico screen limit is 16 - with this, you could design a map that is 4 screens long, but have them represented as 8x2 regions, giving 64 levels of that size... but it doesn't stop there... that is assuming that you need to use all 256 sprites, if you only need 128 then you could have 192. That's a sizable game, and designing levels that way... 64 of them at least - would be so much quicker. There's even the option to use just 32 screens, and have a separate map for enemy and pickup locations. I'm using this in my first Pico-8 game, it has 16 levels at 512x512. Imagine the variations, tile transitions, with a full 256 tile set, only needing 5 per texture... possibly even mix textures and blend between them. Could lead to a very vibrant and thicc Pico-8 project. I'd hate to see a good game binned because it could only fit 1 level or 2 levels.
That's such a clever idea, I love it. I'm working on a metroidvania right now and feeling pressed for map space, now i'm tempted to redo the whole map using a variation on this concept. If you were creating an open world instead of finite levels, you could just use the map to lay out your sprites which represent 8x8 chunks of level. Now your game world is 8x the size of the map, you just have to reuse chunks in creative ways to fill it out. You could even define different zones to use different sets of textures, adding variety. Maybe one half of the map stores level data and the other is zone data, and different zones use different textures and spawning rules. Half of the map at 8x scale is still a lot of room. So many possibilities!
I like this approach. It's similar to how Second Life crammed a whole 3D object into a JPG (Sculpties). I assume there's a function for getting a pixel color at a particular screen x/y
@@DFX2KX Yeah, but you wouldn't need that - you can just get the map block, then use the sprite memory (SGET) to read the pixel colour. I think that's a neater way to do it than drawing the map to the screen, and it gives more control to know each sprite number. I ended up using parts of the visible tiles as map tiles... it all got a bit meta - but I did manage to get good sized maps in the end. I used this technique in my game Savior, you should check it out :D - someone has to! - it's available from the splore cartridge. I actually left space for double the amount of levels... it is a very handy technique to get into early in development.
You should look into the video of how they made Micro-Mages, there's a whole section on how they cramed all the level data into the game using tilesets, Meta-tile-sets and Giant Meta tilesets, they then only needed like, a few numbers to define whole chunks of levels, they saved soo much space it allowed them to add new game + mode with more difficult levels, it's super interesting! (Link to relevant bit in clip I was talking about -> th-cam.com/video/ZWQ0591PAxM/w-d-xo.html )
@@martinbecker2164 Yeah, that is a great video. One option would be to use layers of maps - black is transparent, so it is possible to have a backdrop, then platforms, then details, but of course the map doesn't allow flipping. The map area in Pico-8 is odd, and it might be best to split the map into 2. One trick that I've only just discovered is to use floor map, and a wall map - then the wall map uses transparent tiles, so its easy to check the map tile at a sprite position and sprite it on top, gives a nice 3D effect. Also... in my current rogue-lite project, I have 2 18x18 map areas for fogging, works pretty nicely for that as well... my levels end up as 42x32 tiles, which is ok for what I'm going for.
I bet you could make it even smaller by somehow flipping even smaller regions, Like I noticed the inside corners could only take up half a tile and flip it. That way you could fit another half tile, split it, and flip it. If you don't mind some tiles being symmetrical I guess.
@@devquest9126 Thanks for responding! Off-topic, but, I had the idea to try porting a visual-novel style game to pico-8 (Once I get a computer near the beginning of december). Do you think it's possible, with the small screen size and 16-colors-at-a-time limitations?
@@stephaniemcfarland1825 That sounds like a cool project. I definitely think it's possible, but I don't think the screen size and limited palette are your main problems. Those are just a matter of making stylized pixel art. I've never played a visual novel, but I understand that there may be a lot of large character sprites and backgrounds, and I worry that you'll quickly run out of room on the spritesheet. I can recommend reusing as much art as possible - for example, having one sprite for the body and smaller interchangeable facial expressions. Also, In another video I show a method to store music data in the spritesheet memory, but you might want to use the same method to store sprites in the music section. There's also a method that I really want to make a video on where you can store sprites as code and paste them into the spritesheet at runtime. In short, there are plenty of ways to work with and around the technical limitations if you really want to make something.
That's a good point. At this screen size the difference is negligible, but it makes it an especially good idea to only draw tiles that are visible on screen for performance.
And now we have automatic procedural tiles in PICO-8
Awesome!
This is extremely useful, and not complicated either. Thank you for this tutorial!
_what_
edit: this is gonna be so useful
Thanks to this Video, I was able to add automatic Tilesets to my Game. Thank you for that, it really helped a lot!^^
You're welcome, that's so great to hear!
This approach saves a ton of memory. and works on the Gamebuino Consoles too (which don't actually have a built-in tileset feature at all, it's all sprites anyway). Should be able to copy my Sim-City style roads then. excellent.
This is such a neat concept, well done.
Really cool and novel approach, I will definitely try it out! Thanks for sharing!
This is awesome code, but I want to see a more advanced version of this code, where it is a function that defines regions of a map (as opposed to hard-coded), so it can be reused for other materials (like rock, wood, or brick). and maybe random variants as well
I did use a more advanced version of this for another project that included multiple materials as well as slopes. Maybe I could do a tutorial for a more generalized method. Thanks for the idea!
@@devquest9126 No problem!, looking forward to that video!
@@devquest9126 I would love to see that, especially if you included the slopes which have been giving me no end of trouble. 😅
Should make it possible to adopt a meta level design as well. Like, save some tiles for defining the actual level layout in 8x8 chunks. Then use a big map area that you re-use for each level, design the levels with the 8x8 blocks somewhere else on the map. Effectively the map limit in Pico is 128x32 if you need all tiles... if you use pixel colours on blocks to define the sprites, then use the auto-siding technique, you could have very complex, large maps. So the pico screen limit is 16 - with this, you could design a map that is 4 screens long, but have them represented as 8x2 regions, giving 64 levels of that size... but it doesn't stop there... that is assuming that you need to use all 256 sprites, if you only need 128 then you could have 192. That's a sizable game, and designing levels that way... 64 of them at least - would be so much quicker. There's even the option to use just 32 screens, and have a separate map for enemy and pickup locations. I'm using this in my first Pico-8 game, it has 16 levels at 512x512. Imagine the variations, tile transitions, with a full 256 tile set, only needing 5 per texture... possibly even mix textures and blend between them. Could lead to a very vibrant and thicc Pico-8 project. I'd hate to see a good game binned because it could only fit 1 level or 2 levels.
That's such a clever idea, I love it. I'm working on a metroidvania right now and feeling pressed for map space, now i'm tempted to redo the whole map using a variation on this concept.
If you were creating an open world instead of finite levels, you could just use the map to lay out your sprites which represent 8x8 chunks of level. Now your game world is 8x the size of the map, you just have to reuse chunks in creative ways to fill it out.
You could even define different zones to use different sets of textures, adding variety. Maybe one half of the map stores level data and the other is zone data, and different zones use different textures and spawning rules. Half of the map at 8x scale is still a lot of room. So many possibilities!
I like this approach. It's similar to how Second Life crammed a whole 3D object into a JPG (Sculpties). I assume there's a function for getting a pixel color at a particular screen x/y
@@DFX2KX Yeah, but you wouldn't need that - you can just get the map block, then use the sprite memory (SGET) to read the pixel colour. I think that's a neater way to do it than drawing the map to the screen, and it gives more control to know each sprite number. I ended up using parts of the visible tiles as map tiles... it all got a bit meta - but I did manage to get good sized maps in the end. I used this technique in my game Savior, you should check it out :D - someone has to! - it's available from the splore cartridge. I actually left space for double the amount of levels... it is a very handy technique to get into early in development.
You should look into the video of how they made Micro-Mages, there's a whole section on how they cramed all the level data into the game using tilesets, Meta-tile-sets and Giant Meta tilesets, they then only needed like, a few numbers to define whole chunks of levels, they saved soo much space it allowed them to add new game + mode with more difficult levels, it's super interesting! (Link to relevant bit in clip I was talking about -> th-cam.com/video/ZWQ0591PAxM/w-d-xo.html )
@@martinbecker2164 Yeah, that is a great video. One option would be to use layers of maps - black is transparent, so it is possible to have a backdrop, then platforms, then details, but of course the map doesn't allow flipping. The map area in Pico-8 is odd, and it might be best to split the map into 2. One trick that I've only just discovered is to use floor map, and a wall map - then the wall map uses transparent tiles, so its easy to check the map tile at a sprite position and sprite it on top, gives a nice 3D effect. Also... in my current rogue-lite project, I have 2 18x18 map areas for fogging, works pretty nicely for that as well... my levels end up as 42x32 tiles, which is ok for what I'm going for.
I hope you continue with Pico-8 tutorials!
Thanks, I plan to!
Thank you for this cool dev tip. I never had this idea.
This is awesome!
So it auto tiles the blueprint? That is great.
Thanks so much for the tutorial!
This is neat! Thanks for sharing
Clever stuff!
Great content
this is really interesting!
Good idea!
I bet you could make it even smaller by somehow flipping even smaller regions, Like I noticed the inside corners could only take up half a tile and flip it. That way you could fit another half tile, split it, and flip it.
If you don't mind some tiles being symmetrical I guess.
Hey, good idea. I think the symmetry would usually be hard to notice for little details like that, so even better.
@@devquest9126 Thanks for responding! Off-topic, but, I had the idea to try porting a visual-novel style game to pico-8 (Once I get a computer near the beginning of december). Do you think it's possible, with the small screen size and 16-colors-at-a-time limitations?
@@stephaniemcfarland1825 That sounds like a cool project. I definitely think it's possible, but I don't think the screen size and limited palette are your main problems. Those are just a matter of making stylized pixel art. I've never played a visual novel, but I understand that there may be a lot of large character sprites and backgrounds, and I worry that you'll quickly run out of room on the spritesheet. I can recommend reusing as much art as possible - for example, having one sprite for the body and smaller interchangeable facial expressions. Also, In another video I show a method to store music data in the spritesheet memory, but you might want to use the same method to store sprites in the music section. There's also a method that I really want to make a video on where you can store sprites as code and paste them into the spritesheet at runtime. In short, there are plenty of ways to work with and around the technical limitations if you really want to make something.
Nice have'nt seen this one!
This is so helpful! 🙆🎉❤️
Wtf thats like ultra optimized tiling, I wonder if thats a bit consuming to draw each frame as you are basically tiling extra times.
That's a good point. At this screen size the difference is negligible, but it makes it an especially good idea to only draw tiles that are visible on screen for performance.