What video game do you want to see ported over?

[Tursi]

Never going to tire of seeing smooth scrolling.

[+InsaneMultitasker]

Maybe we could re-port some of the ugly scrollers like MunchMobile into a new, smooth scrolling environment? Oh wait... would anyone really want to play MunchMobile? heheheh

 

That Marble Madness scrolling demo had me humming the level 2 tune again...

[+OLD CS1]

Phucken fenomenal.

[Kurt_Woloch]

Call me crazy, but I think I have some suggestions how to improve the scroller in order to eat up less RAM...

 

What if, instead of including all the pre-scrolled characters for 8 possible frames (which would be 64 bytes per transition and table), you only include a 16-byte strip per transition? Since in the vertical bitmap scroller, you're copying over the whole character set each time anyway, the sscroller could start anywhere between the 1st and the 9th byte of the strip, so for frame 1, you're copying over bytes 1-8, for frame 2, you're copying over bytes 2-9 etc., of course for the pattern and the color table respectively. That way, for 128 characters, you only need to store 4K of graphics data instead of 16K. Of course, the current version of Magellan doesn't provide for this kind of saving the map...

 

Even more space could be saved by creating the shifted characters on the fly from the sections "Original Character data", "Colorset definitions" and "Transition Character pairs" by copying part of the first, and then part of the second character. This means that there probably would have to be 8 versions of the copying routine, depending on the frame, where each routine would switch to a different character at another time. But on the other hand, you only would need one copy of the character and the color set.

 

I know, of course, that my suggestions would come with speed penalties. A small one at the first suggestion... you would just have to increase the counter by 8 bytes after each character copied because the transition data is now 16 bytes per character. A bigger one, however, at the second, because for each transition to be written, you would have to calculate the starting address of the first and second part of the transition on the fly... but maybe this could be stored in a table to speed it up a bit.

 

Only suggestions...

[Asmusr]

What if, instead of including all the pre-scrolled characters for 8 possible frames (which would be 64 bytes per transition and table), you only include a 16-byte strip per transition? Since in the vertical bitmap scroller, you're copying over the whole character set each time anyway, the scroller could start anywhere between the 1st and the 9th byte of the strip, so for frame 1, you're copying over bytes 1-8, for frame 2, you're copying over bytes 2-9 etc., of course for the pattern and the color table respectively. That way, for 128 characters, you only need to store 4K of graphics data instead of 16K. Of course, the current of Magellan doesn't provide for this kind of saving the map...

 

Excellent suggestion, now why didn't I think of that? I will make sure the next update of Magellan can export in this format.

[Kurt_Woloch]

Well, come to think of it... Magellan wouldn't have to output in this format. I think it would save more space (in this case, disk space for the program) if only the sections "Original character patterns", "Colorset Definitions", "Transition Character Pairs" and "Transition Map Data" would be loaded in from disk before each level starts (or even kept in RAM if some of the tables are the same for each level). Then the "Scrolled Character Patterns" (reduced to the 16 color strips mentioned above) could be generated by the TI-99 program. This would require a bit more code and, again, more RAM since some additional tables also reside there, but much less disk space and also less loading time from disk, since now, for instance, my Level 1 would only occupy about 3.3 K of data on disk. When you load in the pre-calculated 16-byte strips from disk, you still need about 5.2 K of data on disk. For a game with multiple levels this might be the way to go... in fact, from what I read in the source code, I think you're doing it a bit like this already in "Titanium" (only that you're generating the 8 distinct patterns now instead of the 16-byte strips per transition).

Edited October 31, 2013 by Kurt_Woloch

[Asmusr]

Well, come to think of it... Magellan wouldn't have to output in this format. I think it would save more space (in this case, disk space for the program) if only the sections "Original character patterns", "Colorset Definitions", "Transition Character Pairs" and "Transition Map Data" would be loaded in from disk before each level starts (or even kept in RAM if some of the tables are the same for each level). Then the "Scrolled Character Patterns" (reduced to the 16 color strips mentioned above) could be generated by the TI-99 program. This would require a bit more code and, again, more RAM since some additional tables also reside there, but much less disk space and also less loading time from disk, since now, for instance, my Level 1 would only occupy about 3.3 K of data on disk. When you load in the pre-calculated 16-byte strips from disk, you still need about 5.2 K of data on disk. For a game with multiple levels this might be the way to go... in fact, from what I read in the source code, I think you're doing it a bit like this already in "Titanium" (only that you're generating the 8 distinct patterns now instead of the 16-byte strips per transition).

 

In Titanium I started with the raw patterns and maps and generated everything, even the transition map, on the TI on the fly. This has advantages for loading speed, but it also made it very difficult to understand what was going on. I had to look in RAM while the game was running to see which character numbers represented which transitions. This is just to explain that for 'educational purposes' I think it's an advantage to have the full data file available to look at instead of having it generated. So for my sample code I will still make an option in Magellan to export the 'strips', but once you understand the basics of how it works you can replace it with your own routine.

 

It depends on the individual game how much RAM you're willing to sacrifice for speed. As you suggested it's also possible to generate and upload the scrolled patterns on the fly without any buffers. When I wrote Titanium I did everything the fastest way I could think of. For Marble Madness 15-20 FPS is perhaps acceptable for the scrolling. My Marble demo is running at 30 FPS and has around 10000 clock cycles left of the second frame. Another decision is whether you want to store 2 copies of the map for updating the name table - the second with the most significant bit set. Having to set the bit while copying is a significant factor for performance. I store two copies in Titanium, but in Scramble I didn't have enough RAM, but it turned out it didn't matter because it's still running at 60 FPS. In the sample code I'm also using one map only, and the VM8BHW routine is setting the MSb the fastest way I could think of.

[Asmusr]

I now have a version of the sample code with 16 byte strips up and running, and the performance loss appears to be insignificant. The reduced memory use makes the algorithm much more versatile, so thanks again Kurt for this suggestion. I will post the updated sample code tomorrow in the Smooth scrolling thread.