Asmusr

That sounds interesting. I'm looking forward to see some visuals.

96 for sprites and 138 for walls.

I'm not sure if you're suggesting anything or just joking. Maybe, but it sounds like a lot of trouble for a rather limited improvement of speed.

Having an animated floor/ceiling would reduce the frame rate almost down to how it is now when you turn and the entire screen is redrawn. But maybe a steady frame rate would be preferable to the speed-ups you experience when running through corridors if you got an animated floor/ceiling as a bonus? Removing some of the optimizations from the code would certainly make it easier to understand and maintain.

Using a symmetric checkered texture you would only need 16 different images. But the floor and ceiling would have to be redrawn every frame, which would affect performance.

Right now there are 8 different images (one for each direction). One option would be to make the floor/ceiling tiles twice as big and increase the number of images to 32 (8 for each of the 4 positions within the bigger tiles).

The check is part of the unrolled code. For the biggest size (192) it looks like this: sprite_c0: equ $ ! movb *r0+,r13 jeq ! szcb r9,*r1 socb r13,*r1+ szcb r9,*r1 socb r13,*r1+ szcb r9,*r1 socb r13,*r1+ jmp !! ! ai r1,3 ! movb *r0+,r13 jeq ! szcb r9,*r1 socb r13,*r1+ szcb r9,*r1 socb r13,*r1+ szcb r9,*r1 socb r13,*r1+ jmp !! ! ai r1,3 At this size it's reading one texture byte for every three screen bytes written, so the overhead of the check is relatively low.

If you made a first try at converting it to T80XB I'm sure someone here would help with the rest.

I have optimized the sprite drawing in the same way as for the walls. The number of instructions per pixel has dropped from 8-9 to 2-5. texcaster.rpk texcaster8.bin

Yes if SAMS is not enabled.

Welcome to the new forum.

This demo requires SAMS. There is a new maze, new wall textures, and lots of new monster textures borrowed from Buzzkill's 32x32 tileset for Angband. I have replaced the gun with a compass, and if you view the map you only see the areas you have visited. The monsters are harmless for now, so the only challenge to complete the 'game' is to find your way to the bottom left corner. P. S. I have not done anything yet to optimize the drawing of 'sprites'. texcaster8.bin

Any news?

Moving off topic, but would a co-processor in a sidecar cartridge be able to push data to the VDP at the same time as the main CPU executed a program on the 16-bit bus in scratchpad?

The problem is that the CPU cannot do anything else while playing digitized sound unless your code is specially designed for it (like Dragon's Lair). And even with the TIPI I don't think you could transfer data fast enough for a smooth experience.

If you're looking for examples, the source code for several of my games is in github. Here is the code for Bouncy's obstacle course, for instance: https://github.com/Rasmus-M/obstacle I have attached the game in case you haven't seen it. obstacle-8.bin

@Omega-TI

Was the request accepted?

Are you talking about digitized sound played back on the TI?

Thanks to @Tursi it's possible to play music on the TI from several other home computers with the same family of sound chips. Many of those chiptunes are, in my opinion, more interesting than music done on the TI back in the days. But whenever this topics comes up it's clear that people have very different opinions about what qualifies as good music. One example I find impressive is Collision Chaos by Chris Kelly because it manages to squeeze so much sound out of the PSG, here in a demo I made for the F18A (the Flappy Bird sprite was broken by the latest F18A firmware update).

That was for the F18A so it cannot should not be compared.

After reading the explanation a couple of times I'm slowly beginning to understand how it works. Am I correct that the lookup tables alone take up 1MB of ROM? https://www.msx.org/forum/msx-talk/development/msx-karts-1st-playable-demo?page=2

I promise to get back with more videos as soon as I have something new and consistent to show. At the moment the code is in flux. I'm afraid it's SAMS only from now on unless someone invents a new cartridge type that can work with 2 separate 4K pages.

Yes the speed is amazing. I did something a little bit like it some years ago:

It wouldn't work with the current code because I'm drawing the sprites one by one after drawing the entire ceiling/walls/floor.