Clear thanks, the scrol of the first example was quite misleading.
Iām wondering how hard it would be to support multiple tile layers and a single sprite layer like old school systems. Each tile layer was able to scroll independently of each other which allowed for some nice effects.
If it is possible then maybe have a configuration parameter so people can choose to have just one layer, or multiple tile layers. Then the developer can decide on balance between more tile layers vs more sprites on screen.
Its a non-trivial amount of code, but it wouldnāt be very hard to implement. The major concern is I donāt know if itād be fast enough to be useful, or if in the end itād be used at all because of the amount of space taken up by 256-color tiles.
Right now Iād prefer we did a feature freeze. We need to get to know the mode, in practice, before we bloat it accidentally. With TileJam coming up, itād be good to know that whatās already implemented is solid.
Yeah I think the only way to remedy that is to mimic the other limitations they had which was 8x8 tiles, 256 tiles per tileset. With those limitations 4 tilesets would take 65K of space. Still leaves a good amount of space for code and other content, but I think they also had separate memory locations dedicated to just holding tiles. So 3 tilesets would be for a background, main layer, and foreground and the fourth would be for sprites.
If I do more work with a different project Iāve got going on I might try a multi-layer mod for TAS mode and run some stress tests to see what kind of performance drop there is. Would need to test how many sprites can be on screen for each additional tile layer before the performance drops below 30FPS (seems to be a good bare minimum frame rate before the game feels unresponsive).
That would probably be a wise decision. See what we can do with the system as-is then weāll know what areas can be improved upon. Plus we donāt want to risk breaking anything mid-jam.
OldSkool to me are systems that had only a single tile layer and multi-layer effects were achieved by recreating the tiles in real time.
Would be awesome to see how this can be achieved with the current implementation of TAS mode. Will have to see what the TileJam produces since this type of jam usually gets a lot of people focused on what they can push out of a new process.
Wonāt be me since Iām already working on a game idea using TAS mode in a crude way (11x11 tiles making a 20x16 screen size).
Not as easily as on those old systems. They had all of their tile data in RAM so it could easily be manipulated. In theory though, if you donāt have any transparency in your foreground tiles, you could simply make a group of pre-scrolled tiles and swap them out when you update the screenā¦ so maybe just as easy, but different.
You could possibly do a mixed mode where static tiles are stored in flash and dynamic ones in ram. Tilemap seems like it doesnāt care where the data is located. With that you could have X number of regular tiles and Y number of ābackgroundā tiles. Then you just have to manipulate the background tiles between frames to achieve a parallax type feel. Basically say your background is 4x4 tiles then youād manipulate the whole thing as if it were one tile, but then pass pointers to the individual 16 tile locations to Tilemap. It would require a little bit of trickery but 16x8bpp tiles only takes 4K of RAM which is very doable since TAS mode doesnāt use much ram. Iāll leave this idea here for others to experiment with as a possibility.
Thatās because (as far as Iām aware) the Pokittoās CPU has a unified memory bus,
so the same address space accesses both flash and RAM (and presumably hardware IO registers too).
Thatās vastly different to AVR chips (the kind most often used with Arduino code),
which have a separate address space for RAM and flash,
and thus the CPU uses two different kinds of instructions to access each,
which is why you need the pgm_read_
macros - they actually translate to inline assembly.
That is correct, it took me a bit to figure out that to put a static array in flash simply declare it const
but dropping the const
puts it in RAM. Actually makes things like this significantly easier because of being able have some data in RAM and some in FLASH but the same routine to access both. Also doesnāt appear to be any performance change switching from one to the other (most likely because of the shared memory bus).
ARM cortex can also run code from RAM so self-modifying code is also possible !
Does this mean we can have a TAS mode game that slowly changes itself into a MODE15 game, and then MODE2 or some other mode. Then at some point it gets smart when modifying itself and changes from PokittoLand to PokittoNet.
Well, once it reaches Mode15 itād run out of memory and itād be more like watching Finding Dory than Terminator.
Updated the first post with this: Converters.zip (5.8 KB)
It contains a fix to the TMX converter (if two maps use the same tile, it will now be exported only once) and a new converter for animated sprites in JSON Array format.
Both scripts should be compatible with any screen mode, not just TAS.
Is there something wrong with my setup? I just tried the tilemap example and my screen is very dark. Pressing C+L/R will adjust the brightness (isnāt this supposed to change volume?). My other projects donāt do thisā¦
Odd, I donāt see that here. Can you post the bin?
Tried on hardware, looks normal to me.
Oddā¦ (hard to see in the video because of the light,
TAS is now available for testing in MicroPython:
-> https://pokittopython.herokuapp.com <-
In the āFlagsā tab, change the gameās resolution to either TAS Low
or TAS High
.
Enjoy high-resolution graphics without instantly running out of RAM.