iigs-game-engine/src
Lucas Scharenbroich 29d70dc567 Break up large source code files to help with dependency ordering 2022-04-25 11:30:24 -05:00
..
blitter Break up large source code files to help with dependency ordering 2022-04-25 11:30:24 -05:00
static Thank to Kelvin Sherlock for pointing out that the source files were not setting the register state directive 2022-04-23 15:41:25 -05:00
Anim.s Initial Tiled tile animation export support 2021-10-06 07:10:09 -05:00
Core.s Refactor to support building a tool and new demo to try and use it [not working] 2022-04-23 00:47:13 -05:00
CoreImpl.s Basic working user tool framework 2022-04-24 14:45:07 -05:00
Defs.s Basic working user tool framework 2022-04-24 14:45:07 -05:00
GTE.s Background rendering again 2022-02-18 20:43:55 -06:00
Graphics.s Refactor to support building a tool and new demo to try and use it [not working] 2022-04-23 00:47:13 -05:00
Master.s Work on fixing linker / OMF errors 2022-04-23 12:48:13 -05:00
Math.s Break up large source code files to help with dependency ordering 2022-04-25 11:30:24 -05:00
Memory.s Basic working user tool framework 2022-04-24 14:45:07 -05:00
README.md Checkpoint for sprite rewrite 2022-02-18 12:12:32 -06:00
Render.s Rough outline of streamlined sprite subsystem 2022-04-20 07:43:16 -05:00
RotData.s Reformat 2021-07-30 08:01:46 -05:00
Script.s Fix bcc/bcs typo when initializing timers 2021-10-07 16:38:20 -05:00
Sprite.s Refactor to support building a tool and new demo to try and use it [not working] 2022-04-23 00:47:13 -05:00
Sprite2.s Refactor to support building a tool and new demo to try and use it [not working] 2022-04-23 00:47:13 -05:00
SpriteRender.s Rough outline of streamlined sprite subsystem 2022-04-20 07:43:16 -05:00
TileMap.s WIP: manual sprite rendering showing on screen 2021-10-28 21:41:01 -05:00
Timer.s Fix bcc/bcs typo when initializing timers 2021-10-07 16:38:20 -05:00
Tool.s Basic working user tool framework 2022-04-24 14:45:07 -05:00
_FileInformation.txt Refactor to support building a tool and new demo to try and use it [not working] 2022-04-23 00:47:13 -05:00

README.md

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