https://www.youtube.com/watch?v=AV3ElKsyTro
This looks incredibly smooth. The programming techniques used here - is it the same execution used for coding racing games?
I wonder if Martech racing games (SuperCycle/Nigel Mansell) used the same method.
The game is very nice! I guess that the lack of sprite scaling, curves and rival cars are responsible for the smoothness that we don´t see in many other titles :) There seem to be some other tricks, too. I would say that the grid is static and the program "just" changes the color of the tiles, counting the black ones as regions where there is nothing. On the other hand, the only sprite you see when playing is the little ball, I reckon that it helps as well and saves a lot of memory. In any case, great and clever game :D
I don't think it's palette swapping - too many tiles for that.
I guess it's drawing on the differences, frame to frame.
Just like in Logon's Run, you can change the palette multiple times *during* a scanline, you're not restricted to doing it just in the horizontal blanking period.
...wait, the top section's mode 0. One palette change per scanline should be plenty.
Quote from: pelrun on 14:30, 28 April 17
Just like in Logon's Run, you can change the palette multiple times *during* a scanline, you're not restricted to doing it just in the horizontal blanking period.
...wait, the top section's mode 0. One palette change per scanline should be plenty.
I would think it consists of 5 different colour static 'bars' then 5 raster changes per scanline (in the limited board area) to make the scrolling map?
Quote from: Duke on 14:51, 28 April 17
I would think it consists of 5 different colour static 'bars' then 5 raster changes per scanline (in the limited board area) to make the scrolling map?
Yes, that's exactly it. You can see by looking at the screen ram in an emulator debugger:
[attach=2]
and you can see some of the code that would be doing the job as well, 5 colour changes:
[attach=3]
So it's perfect for what it is trying to do, but it wouldnt be so ideal for a game were you wanted to turn the track. Although maybe you could fudge it to do that, it would probably be very crude with a limited number of steps in the turns, and likely reduce your available colours substantially.
The other thing to consider is that maintaining the colour changes for the track tiles requires about a 3rd of the screen frame, or a 1/3 of your cpu time, each and every screen refresh, so would be quite an overhead for a game with a lot of track side objects and/or cars.
Ah yeah, that's way better, using the rasters. Sometimes I forget the old games used these effectively!
Quote from: Duke on 14:51, 28 April 17
I would think it consists of 5 different colour static 'bars' then 5 raster changes per scanline (in the limited board area) to make the scrolling map?
Actually I was thinking that it was mode 1 and the bars were coloured 12321, and you just needed to change inks 1 and 2 at the midway point. But then you'd have no more inks for the ball.
I confirm, fully raster based game.
Nice to calibrate rasters against falling down ball ;)
Quote from: pelrun on 16:04, 28 April 17
Actually I was thinking that it was mode 1 and the bars were coloured 12321, and you just needed to change inks 1 and 2 at the midway point. But then you'd have no more inks for the ball.
Time for a Plus conversion then :-)