.. | ||
blitter | ||
sprites | ||
static | ||
tiles | ||
_FileInformation.txt | ||
Anim.s | ||
Core.s | ||
CoreImpl.s | ||
Defs.s | ||
Graphics.s | ||
GTE.s | ||
Master.s | ||
Math.s | ||
Memory.s | ||
README.md | ||
Render.s | ||
RotData.s | ||
Script.s | ||
Sprite2.s | ||
Sprite.s | ||
SpriteRender.s | ||
TileMap.s | ||
Tiles.s | ||
Timer.s | ||
Tool.s |
= Rendering Pipeline =
The engine run through the following render loop on every frame
- Lock in any changes to the play field scroll position
- Erase/Redraw dirty sprites into the sprite plane
- If a sprite has moved a different amount than the scroll position, it's marked dirty
- If a sprite was just added on this frame, it's marked dirty
- Any sprite that overlaps a dirty sprite is marked as impacted
- All dirty sprites are erased from the sprite plane
- All dirty and impacted sprites are drawn into the sprite plane
- All of the play field tiles that intersect dirty sprites are marked as dirty with the sprite flag set
- If a scroll map is defined
- Calculate the new regions of the screen that have been scrolled into view
- For each new tile
- Copy the tile descriptor from the tile map into the tile store
- Mark the tile as dirty
- For each dirty tile
- Load the tile descriptor from the tile store
- Dispatch to the appropriate tile renderer
- Clear the tile dirty flag
- If any Masked Overlays are defined
- Turn off shadowing
- Draw the play field on the Overlay rows
- Turn on shadowing
- In top-to-bottom order
- Draw any Maksed Overlays
- Draw any Opaque Overlays
- Draw any play field rows
NOTES
- The dirty tile list has a fast test to see if a tile has already been marked as dirty it is not added twice
- The tile renderer is where data from the sprite plane is combined with tile data to show the sprites on-screen.
- Typically, there will not be Overlays defined and the last step of the renderer is just a single render of all playfield lines at once.
= Sprite Redesign =
In the rendering function, for a given TileStore location, we need to be able to read and array of VBUFF addresses for sprite data. This can be done by processing the SPRITE_BIT array in to a list to get a set of offsets. These VBUFF addresses also need to be set. Currently we are calculating the addresses in the sprite functions, but the issue is that we need to find an addressing scheme that's essentially 2D because we have >TileStore+VARNAME,x and Sprite+VARNAME,y, but we need something like >TileStore+VARNAME[x][y]
In a perfect scenario, we can use the following code sequence to render stacked sprites
lda tiledata,y ; tile addressed (bank register set) ldx activeSprite+4 ; sprite VBUFF address cached on direct page andl >spritemask,x oral >spritedata,x ldx activeSprite+2 andl >spritemask,x oral >spritedata,x ldx activeSprite andl >spritemask,x oral >spritedata,x sta tmp0
; Core phases
; Convert bit field to compact array of sprite indexes lda TileStore+VBUFF_ARR_PTR,x sta cache lda TileStore+SPRITE_BITS,x bit #$0008 bne ...
lda cache ; This is 11 cycles. A PEA + TSB is 13, so a bit faster to do it at once ora #$0006 pha
; When storing for a sprite, the corner VBUFF is calulated and stored at
base = TileStore+VBUFF_ARR_ADDR,x + SPRITE_ID
sta base sta base+32 ; next column (mod columns) sta base+(32width) ; next row sta base+(32width+32) ; next corner
Possibilities
-
Have >TileStore+SPRITE_VBUFF be the address to an array and then manually add the y-register value so we can still use absolute addressing
tya adc >TileStore+SPRITE_VBUFF_ARR_ADDR,x ; Points to addreses 32 bytes apart ad Y-reg is [0, 30] tax lda >TileStore,x ; Load the address tay
lda 0000,y lda 0002,y ...