[Wiki]Everything there is to know about TAS Mode

Clear thanks, the scrol of the first example was quite misleading.

2 Likes

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.

2 Likes

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.

2 Likes

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.

2 Likes

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.

3 Likes

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.

1 Like

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).

1 Like

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.

3 Likes

Well, once it reaches Mode15 itā€™d run out of memory and itā€™d be more like watching Finding Dory than Terminator.

1 Like

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.

2 Likes

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?

TilemapProject.bin (46.5 KB)

Tried on hardware, looks normal to me. :eyeglasses:

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.

6 Likes