English Amiga Board - View Single Post

arcanist · 23 August 2018, 19:03

This is a prototype of the "track" on which the player moves. I've added keyboard (A/D left/right, release to center) and mouse control. This method trivially supports track bends left and right, by shifting scanlines, and can also show hills.

On each scanline the copper programs a 3x1 pixel sprite to appear at the left and right stripes, loading data manually to avoid DMA. The positions are calculated using an integer Bresenham algorithm with perspective-correct lines.

I did some limited optimization to get it running on an A500 at 50Hz but haven't rewritten the code in assembly yet. I ran into an issue with ptplayer's timer interrupt on the emulated A500 causing an odd delay when it coincides with the vblank (I have VERTB interrupt disabled). For now I recorded on an emulated A1200.

The next step is to decide between this approach and Lotus's method, which blits from a precalculated image on each scanline. I'd guess the copper method is faster (six CPU word writes per scanline) for a bare track.

However, next I want to introduce the "blocks" the player will try to hit. There may be quite a few on screen; certainly more than the sprite channels I have. Reusing channels down the screen is one option but difficult to pull off when the blocks overlap. Displaying them as bobs would be asking a lot out from the blitter. The upside is the blocks could be displayed as vertical objects.

I'm considering a different idea: making the blocks flat on the track. It's less visually impactful than hitting a vertical object but I could spruce it up with sprites when the player hits one. The advantage of this is I could merge it with the Lotus approach; on each scanline there would be 1 of 8 configurations (0-3 blocks across the lanes) and the program would pick a line from eight pre-calculated images to blit. The blocks would also have perspective depth with this method.

[ Show youtube player ]

23 August 2018, 19:03	#4
arcanist Registered User Join Date: Dec 2017 Location: Austin, TX Age: 41 Posts: 405	This is a prototype of the "track" on which the player moves. I've added keyboard (A/D left/right, release to center) and mouse control. This method trivially supports track bends left and right, by shifting scanlines, and can also show hills. On each scanline the copper programs a 3x1 pixel sprite to appear at the left and right stripes, loading data manually to avoid DMA. The positions are calculated using an integer Bresenham algorithm with perspective-correct lines. I did some limited optimization to get it running on an A500 at 50Hz but haven't rewritten the code in assembly yet. I ran into an issue with ptplayer's timer interrupt on the emulated A500 causing an odd delay when it coincides with the vblank (I have VERTB interrupt disabled). For now I recorded on an emulated A1200. The next step is to decide between this approach and Lotus's method, which blits from a precalculated image on each scanline. I'd guess the copper method is faster (six CPU word writes per scanline) for a bare track. However, next I want to introduce the "blocks" the player will try to hit. There may be quite a few on screen; certainly more than the sprite channels I have. Reusing channels down the screen is one option but difficult to pull off when the blocks overlap. Displaying them as bobs would be asking a lot out from the blitter. The upside is the blocks could be displayed as vertical objects. I'm considering a different idea: making the blocks flat on the track. It's less visually impactful than hitting a vertical object but I could spruce it up with sprites when the player hits one. The advantage of this is I could merge it with the Lotus approach; on each scanline there would be 1 of 8 configurations (0-3 blocks across the lanes) and the program would pick a line from eight pre-calculated images to blit. The blocks would also have perspective depth with this method. [ Show youtube player ]