iigs-game-engine/src/README.md
Lucas Scharenbroich 95058fb969 Checkpoint for sprite rewrite
All of the sprite rendering has been deferred down to the level of
the tile drawing. Sprites are no longer drawn/erased, but instead
a sprite sheet is generated in AddSprite and referenced by the
renderer.

Because there is no longer a single off-screen buffer that holds
a copy of all the rendered sprites, the TileStore size must be
expanded to hold a reference to the sprite data address fo each
tile.  This increase in data structure size require the TileStore
to be put into its own bank and appropriate code restructuring.

The benefits to the rewrite are significant:

  1. Sprites are never drawn/erased off-screen.  They are only
     ever drawn directly to the screen or play field.
  2. The concept of "damaged" sprites is gone.  Every dirty tile
     automatically renders just to portion of a sprite that it
     intersects.

These two properties result in a substantial increase in throughput.
2022-02-18 12:12:32 -06:00

3.5 KiB

= Rendering Pipeline =

The engine run through the following render loop on every frame

  1. Lock in any changes to the play field scroll position
  2. 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
  3. 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
  4. For each dirty tile
    • Load the tile descriptor from the tile store
    • Dispatch to the appropriate tile renderer
    • Clear the tile dirty flag
  5. If any Masked Overlays are defined
    • Turn off shadowing
    • Draw the play field on the Overlay rows
    • Turn on shadowing
  6. 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

  1. 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 ...