Apple-2gs-SW/iigs-game-engine
1
0
Fork 0
mirror of https://github.com/lscharen/iigs-game-engine.git synced 2024-06-06 19:29:48 +00:00
Code Issues Projects Releases Wiki Activity
4d6f11a9ba
iigs-game-engine/src/Render.s

998 lines
33 KiB
ArmAsm
Raw Normal View History

Split up source code a bit more; work toward completing render pipeline
2021-07-08 12:46:35 +00:00
; Renders a frame of animation
;
Working through integration bugs * Gave active list dedicated direct page space * Change active list bit test from ror to asl to avoid barrel shift * Various address fixes
2022-02-21 16:31:35 +00:00
; The render function is the point of committment -- most of the APIs that set sprites and
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; update coordinates are lazy; they simply save their values and set a dirty flag in the
More parts of the render pipeline in place
2021-07-09 19:18:49 +00:00
; DirtyBits word.
;
; This function examines the dirty bits and actually performs the work to update the code field
; and internal data structure to properly render the play field. Then the update pipeline is
; executed.
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
;
; Everything is composited into the tiles in the playfield and then the screen is rendered in
; a single pass.
Refactor GTE Core to be included as an independent Segment in other projects
2021-08-25 14:38:02 +00:00
Render ENT
phb
phk
plb
jsr _Render
plb
rtl
Add all minimal function in place; not onto debugging
2021-07-09 20:38:32 +00:00
; TODO -- actually check the dirty bits and be selective on what gets updated. For example, if
; only the Y position changes, then we should only need to set new values on the
; virtual lines that were brought on screen. If the X position only changes by one
; byte, then we may have to change the CODE_ENTRY values or restore/set new OPCODE
; values, but not both.
Add proper handling of wraparound in vertical positioning
2021-07-18 02:00:46 +00:00
; It's important to do _ApplyBG0YPos first because it calculates the value of StartY % 208 which is
; used in all of the other loops
Refactor GTE Core to be included as an independent Segment in other projects
2021-08-25 14:38:02 +00:00
_Render
Add all minimal function in place; not onto debugging
2021-07-09 20:38:32 +00:00
jsr _ApplyBG0YPos ; Set stack addresses for the virtual lines to the physical screen
Add initial build-out of BG1 tile map support
2021-08-19 06:22:36 +00:00
jsr _ApplyBG1YPos
Fix some small bugs with tile rendering; tiles display but crash after scrolling 8 bytes
2021-08-06 19:42:18 +00:00
; _ApplyBG0Xpos need to be split because we have to set the offsets, then draw in any updated tiles, and
; finally patch out the code field. Right now, the BRA operand is getting overwritten by tile data.
jsr _ApplyBG0XPosPre
Add initial build-out of BG1 tile map support
2021-08-19 06:22:36 +00:00
jsr _ApplyBG1XPosPre
Fix some small bugs with tile rendering; tiles display but crash after scrolling 8 bytes
2021-08-06 19:42:18 +00:00
Working through integration bugs * Gave active list dedicated direct page space * Change active list bit test from ror to asl to avoid barrel shift * Various address fixes
2022-02-21 16:31:35 +00:00
nop
Nearly complete integration of sprites into rendering function
2021-10-31 20:42:59 +00:00
jsr _RenderSprites ; Once the BG0 X and Y positions are committed, update sprite data
Tile rendering reorganization This significantly simplifies the dispatch process by creating a proper backing store for the tiles. Most values that were calcualted on the fly are now stored as constants in the tile store. Also, all tile updated are run through the dirty tile list which solved a checken-and-egg problem of which order to do sprites vs new tiles and affords a lot of optimizations since tile rendering is deferred and each tile is only drawn at most once per frame.
2021-10-21 13:50:07 +00:00
jsr _UpdateBG0TileMap ; and the tile maps. These subroutines build up a list of tiles
jsr _UpdateBG1TileMap ; that need to be updated in the code field
Fix some small bugs with tile rendering; tiles display but crash after scrolling 8 bytes
2021-08-06 19:42:18 +00:00
Working through integration bugs * Gave active list dedicated direct page space * Change active list bit test from ror to asl to avoid barrel shift * Various address fixes
2022-02-21 16:31:35 +00:00
nop
Tile rendering reorganization This significantly simplifies the dispatch process by creating a proper backing store for the tiles. Most values that were calcualted on the fly are now stored as constants in the tile store. Also, all tile updated are run through the dirty tile list which solved a checken-and-egg problem of which order to do sprites vs new tiles and affords a lot of optimizations since tile rendering is deferred and each tile is only drawn at most once per frame.
2021-10-21 13:50:07 +00:00
jsr _ApplyTiles ; This function actually draws the new tiles into the code field
Add all minimal function in place; not onto debugging
2021-07-09 20:38:32 +00:00
Tile rendering reorganization This significantly simplifies the dispatch process by creating a proper backing store for the tiles. Most values that were calcualted on the fly are now stored as constants in the tile store. Also, all tile updated are run through the dirty tile list which solved a checken-and-egg problem of which order to do sprites vs new tiles and affords a lot of optimizations since tile rendering is deferred and each tile is only drawn at most once per frame.
2021-10-21 13:50:07 +00:00
jsr _ApplyBG0XPos ; Patch the code field instructions with exit BRA opcode
jsr _ApplyBG1XPos ; Update the direct page value based on the horizontal position
; The code fields are locked in now and ready to be rendered
Get the PEI Slammer working for exposing shadowed writes
2021-07-20 03:42:51 +00:00
Background rendering again
2022-02-19 02:43:55 +00:00
; jsr _ShadowOff
Get the PEI Slammer working for exposing shadowed writes
2021-07-20 03:42:51 +00:00
Small improvements to sprite prototype to fix dirty tiles getting out of sync
2021-10-31 00:24:23 +00:00
; Shadowing is turned off. Render all of the scan lines that need a second pass. One
; optimization that can be done here is that the lines can be rendered in any order
; since it is not shown on-screen yet.
Tile rendering reorganization This significantly simplifies the dispatch process by creating a proper backing store for the tiles. Most values that were calcualted on the fly are now stored as constants in the tile store. Also, all tile updated are run through the dirty tile list which solved a checken-and-egg problem of which order to do sprites vs new tiles and affords a lot of optimizations since tile rendering is deferred and each tile is only drawn at most once per frame.
2021-10-21 13:50:07 +00:00
Sync up with current WIP
2021-11-15 18:23:38 +00:00
; ldx #0 ; Blit the full virtual buffer to the screen
; ldy #8
; jsr _BltRange
Tile rendering reorganization This significantly simplifies the dispatch process by creating a proper backing store for the tiles. Most values that were calcualted on the fly are now stored as constants in the tile store. Also, all tile updated are run through the dirty tile list which solved a checken-and-egg problem of which order to do sprites vs new tiles and affords a lot of optimizations since tile rendering is deferred and each tile is only drawn at most once per frame.
2021-10-21 13:50:07 +00:00
; Turn shadowing back on
Get the PEI Slammer working for exposing shadowed writes
2021-07-20 03:42:51 +00:00
Background rendering again
2022-02-19 02:43:55 +00:00
; jsr _ShadowOn
Get the PEI Slammer working for exposing shadowed writes
2021-07-20 03:42:51 +00:00
Tile rendering reorganization This significantly simplifies the dispatch process by creating a proper backing store for the tiles. Most values that were calcualted on the fly are now stored as constants in the tile store. Also, all tile updated are run through the dirty tile list which solved a checken-and-egg problem of which order to do sprites vs new tiles and affords a lot of optimizations since tile rendering is deferred and each tile is only drawn at most once per frame.
2021-10-21 13:50:07 +00:00
; Now render all of the remaining lines in top-to-bottom (or bottom-to-top) order
Background rendering again
2022-02-19 02:43:55 +00:00
; lda ScreenY0 ; pass the address of the first line of the overlay
; clc
; adc #0
; asl
; tax
; lda ScreenAddr,x
; clc
; adc ScreenX0
Sync up with current WIP
2021-11-15 18:23:38 +00:00
; jsl Overlay
Small improvements to sprite prototype to fix dirty tiles getting out of sync
2021-10-31 00:24:23 +00:00
Sync up with current WIP
2021-11-15 18:23:38 +00:00
ldx #0 ; Blit the full virtual buffer to the screen
Add all minimal function in place; not onto debugging
2021-07-09 20:38:32 +00:00
ldy ScreenHeight
jsr _BltRange
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; ldx #0
; ldy ScreenHeight
; jsr _BltSCB
Sync up with current WIP
2021-11-15 18:23:38 +00:00
Add all minimal function in place; not onto debugging
2021-07-09 20:38:32 +00:00
lda StartY ; Restore the fields back to their original state
ldx ScreenHeight
jsr _RestoreBG0Opcodes
Fix tile rendering This is not quite correct yet. IT appears that two rows or columns are drawn on the edges when only a single solumn or row is necessary. Also, this code is based on the old GTE codebase, so the initial rectangle for rendering tiles is width+1, height+1. This can be improved.
2021-08-10 12:59:14 +00:00
lda StartY
sta OldStartY
lda StartX
sta OldStartX
Add initial build-out of BG1 tile map support
2021-08-19 06:22:36 +00:00
lda BG1StartY
sta OldBG1StartY
lda BG1StartX
sta OldBG1StartX
Fix tile rendering This is not quite correct yet. IT appears that two rows or columns are drawn on the edges when only a single solumn or row is necessary. Also, this code is based on the old GTE codebase, so the initial rectangle for rendering tiles is width+1, height+1. This can be improved.
2021-08-10 12:59:14 +00:00
stz DirtyBits
Background rendering again
2022-02-19 02:43:55 +00:00
stz LastRender ; Mark that a full render was just performed
Split up source code a bit more; work toward completing render pipeline
2021-07-08 12:46:35 +00:00
rts
Checkpoint of work
2022-01-20 02:58:57 +00:00
Background rendering again
2022-02-19 02:43:55 +00:00
; This is a specialized render function that only updates the dirty tiles *and* draws them
Checkpoint of work
2022-01-20 02:58:57 +00:00
; directly onto the SHR graphics buffer. The playfield is not used at all. In some way, this
; ignores almost all of the capabilities of GTE, but it does provide a convenient way to use
; the sprite subsystem + tile attributes for single-screen games which should be able to run
; close to 60 fps.
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
;
; Because we are register starved, there is a lot of inline code to quickly fetch the information
; needed to render sprites appropriately. If there was a way to efficiently maintain an ordered
; and compact array of per-tile VBUFF addresses, rather than the current sparse array, then
; the sprite handling code could be significantly streamlined. A note for anyone attempting
; this optimization:
;
; The _MarkDirtyTiles simply stores a sprite's per-tile VBUFF address and marks the tile
; as being occupied by the sprite with just 4 instructions
;
; sta (vbuff_array_ptr),y
; lda TileStore+TS_SPRITE_FLAG,x
; ora SpriteBit,y
; sta TileStore+TS_SPRITE_FLAG,x
;
; Then, we have an unrolled loop that does repeated tests of
;
; lsr
; bcc *+
; lda vbuff_array_ptr,y
; sta spriteVBuffArr
;
; The only gain to be had is if the sprites that are marked are in the high bits and there are no low-index
; sprites. Skipping over N bits of the SPRITE_FLAG takes only 5*N cycles. So, on average, we might waste
; 40 cycles looking for the proper bit.
;
; Any improvement to the existing code would need to be able to maintain a data structure and get the final
; values into the spriteVBuffArr for a total cost of under 75 cycles per tile.
Checkpoint of work
2022-01-20 02:58:57 +00:00
RenderDirty ENT
phb
phk
plb
jsr _RenderDirty
plb
rtl
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; In this renderer, we assume that there is no scrolling, so no need to update any information about
Checkpoint of work
2022-01-20 02:58:57 +00:00
; the BG0/BG1 positions
_RenderDirty
Fix dirty sprite renderer when StartX and StartY are not zero
2022-02-04 05:44:46 +00:00
lda LastRender ; If the full renderer was last called, we assume that
bne :norecalc ; the scroll positions have likely changed, so recalculate
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
lda #2 ; blue
jsr _SetBorderColor
Fix dirty sprite renderer when StartX and StartY are not zero
2022-02-04 05:44:46 +00:00
jsr _RecalcTileScreenAddrs ; them to make sure sprites draw at the correct screen address
:norecalc
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
lda #3 ; purple
jsr _SetBorderColor
Checkpoint of work
2022-01-20 02:58:57 +00:00
jsr _RenderSprites
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
lda #4 ; dk. green
jsr _SetBorderColor
Checkpoint of work
2022-01-20 02:58:57 +00:00
jsr _ApplyDirtyTiles
Fix dirty sprite renderer when StartX and StartY are not zero
2022-02-04 05:44:46 +00:00
lda #1
sta LastRender
Checkpoint of work
2022-01-20 02:58:57 +00:00
rts
_ApplyDirtyTiles
bra :begin
:loop
; Retrieve the offset of the next dirty Tile Store items in the Y-register
jsr _PopDirtyTile2
; Call the generic dispatch with the Tile Store record pointer at by the Y-register.
phb
jsr _RenderDirtyTile
plb
; Loop again until the list of dirty tiles is empty
Continue fixing code issues; strange relocation error happening
2022-02-18 19:42:37 +00:00
:begin ldy DirtyTileCount
Checkpoint of work
2022-01-20 02:58:57 +00:00
bne :loop
rts
; Only render solid tiles and sprites
_RenderDirtyTile
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
ldal TileStore+TS_SPRITE_FLAG,x ; This is a bitfield of all the sprites that intersect this tile, only care if non-zero or not
bne dirty_sprite
; The rest of this function handles that non-sprite blit, which is super fast since it blits directly from the
; tile data store to the graphics screen with no masking. The only extra work is selecting a blit function
; based on the tile flip flags.
pei TileStoreBankAndBank01 ; Special value that has the TileStore bank in LSB and $01 in MSB
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 18:12:32 +00:00
plb
Checkpoint of work
2022-01-20 02:58:57 +00:00
Rough outline of streamlined sprite subsystem * Split the creation of the sprite stamps from adding the sprites themselves. This allows for 48 stamps that can be pre-rendered and quickly reassigned to sprites for animations. * Inlined all calls to PushDirtyTile. This both removed significant overhead from calling the small function and, since almost all callers we checking multiple tiles, we were able to avoid incrementing the count each time and just add a single incrments at the end. * Switched from recording each tile that a sprite intersects with each from to only recording the top-left tile and the overlap size. This reduced overhead for larger sprites and removed the needs for an end-of-list marker. * Much more aggressive caching of Sprite and Tile Store values in order to streamline the inner tile dispatch routines. * Moving TileStore and Sprites (and other supporting data structures) into a separate data bank. Needed just for size purposes and provide micro-optimizations by opening up the use of abs,y addressing modes. * Revamped multi-sprite rendering code to avoid the need to copy any masks and all stacked sprites can be drawn via a sequence of and [addrX],y; ora (addrX),y where addrX is set once per tile. * General streamlining to reduct overhead. This work was focused on removing as much per-tile overhead as possible.
2022-04-20 12:43:16 +00:00
lda TileStore+TS_DIRTY_TILE_DISP,x ; load and patch in the appropriate subroutine
Background rendering again
2022-02-19 02:43:55 +00:00
stal :tiledisp+1
Checkpoint of work
2022-01-20 02:58:57 +00:00
Rough outline of streamlined sprite subsystem * Split the creation of the sprite stamps from adding the sprites themselves. This allows for 48 stamps that can be pre-rendered and quickly reassigned to sprites for animations. * Inlined all calls to PushDirtyTile. This both removed significant overhead from calling the small function and, since almost all callers we checking multiple tiles, we were able to avoid incrementing the count each time and just add a single incrments at the end. * Switched from recording each tile that a sprite intersects with each from to only recording the top-left tile and the overlap size. This reduced overhead for larger sprites and removed the needs for an end-of-list marker. * Much more aggressive caching of Sprite and Tile Store values in order to streamline the inner tile dispatch routines. * Moving TileStore and Sprites (and other supporting data structures) into a separate data bank. Needed just for size purposes and provide micro-optimizations by opening up the use of abs,y addressing modes. * Revamped multi-sprite rendering code to avoid the need to copy any masks and all stacked sprites can be drawn via a sequence of and [addrX],y; ora (addrX),y where addrX is set once per tile. * General streamlining to reduct overhead. This work was focused on removing as much per-tile overhead as possible.
2022-04-20 12:43:16 +00:00
ldy TileStore+TS_SCREEN_ADDR,x ; Get the on-screen address of this tile
lda TileStore+TS_TILE_ADDR,y ; load the address of this tile's data (pre-calculated)
tax
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
Checkpoint of work
2022-01-20 02:58:57 +00:00
plb ; set the bank
; B is set to Bank 01
; A is set to the tile word offset (0 through 80 in steps of 4)
; Y is set to the top-left address of the tile in SHR screen
; X is set to the address of the tile data
:tiledisp jmp $0000 ; render the tile
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; Use some temporary space for the spriteIdx array (maximum of 4 entries)
stkSave equ tmp9
screenAddr equ tmp10
tileAddr equ tmp11
spriteIdx equ tmp12
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
; Handler for the sprite path
dirty_sprite
pei TileStoreBankAndTileDataBank ; Special value that has the TileStore bank in LSB and TileData bank in MSB
plb
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; Cache a couple of values into the direct page, but preserve the Accumulator
ldy TileStore+TS_TILE_ADDR,x ; load the address of this tile's data (pre-calculated)
sty tileAddr
ldy TileStore+TS_SCREEN_ADDR,x ; Get the on-screen address of this tile
sty screenAddr
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
; Now do all of the deferred work of actually drawing the sprites. We put considerable effort into
; figuring out if there is only one sprite or more than one since we optimize the former case as it
; is very common and can be done significantly faster.
;
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; This is a big, unrolled chunk of code that packs the VBUFF addresses for the sprite positions marked
; in the bitfield into the spriteIdx array and then jumps to an optimized rendering function based on
; the number of sprites on the tile.
;
; After each set bit is identified, we check to see if that was the last one and immediately exit. Since
; a maximum of 4 sprites are processed per tile, this only results in (at most) 4 extra branch instructions.
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
ldy TileStore+TS_VBUFF_ARRAY_ADDR,x ; base address of the VBUFF sprite address array for this tile
lsr
bcc :loop_0_bit_1
ldx: $0000,y
stx spriteIdx
cmp #0
jne :loop_1_bit_1
jmp BlitOneSprite
:loop_0_bit_1 lsr
bcc :loop_0_bit_2
ldx: $0002,y
stx spriteIdx
cmp #0
jne :loop_1_bit_2
jmp BlitOneSprite
:loop_0_bit_2 lsr
bcc :loop_0_bit_3
ldx: $0004,y
stx spriteIdx
cmp #0
jne :loop_1_bit_3
jmp BlitOneSprite
:loop_0_bit_3 lsr
bcc :loop_0_bit_4
ldx: $0006,y
stx spriteIdx
cmp #0
jne :loop_1_bit_4
jmp BlitOneSprite
:loop_0_bit_4 lsr
bcc :loop_0_bit_5
ldx: $0008,y
stx spriteIdx
cmp #0
jne :loop_1_bit_5
jmp BlitOneSprite
:loop_0_bit_5 lsr
bcc :loop_0_bit_6
ldx: $000A,y
stx spriteIdx
cmp #0
jne :loop_1_bit_6
jmp BlitOneSprite
:loop_0_bit_6 lsr
bcc :loop_0_bit_7
ldx: $000C,y
stx spriteIdx
cmp #0
jne :loop_1_bit_7
jmp BlitOneSprite
:loop_0_bit_7 lsr
bcc :loop_0_bit_8
ldx: $000E,y
stx spriteIdx
cmp #0
jne :loop_1_bit_8
jmp BlitOneSprite
:loop_0_bit_8 lsr
bcc :loop_0_bit_9
ldx: $0010,y
stx spriteIdx
cmp #0
jne :loop_1_bit_9
jmp BlitOneSprite
:loop_0_bit_9 lsr
bcc :loop_0_bit_10
ldx: $0012,y
stx spriteIdx
cmp #0
jne :loop_1_bit_10
jmp BlitOneSprite
:loop_0_bit_10 lsr
bcc :loop_0_bit_11
ldx: $0014,y
stx spriteIdx
cmp #0
jne :loop_1_bit_11
jmp BlitOneSprite
:loop_0_bit_11 lsr
bcc :loop_0_bit_12
ldx: $0016,y
stx spriteIdx
cmp #0
jne :loop_1_bit_12
jmp BlitOneSprite
:loop_0_bit_12 lsr
bcc :loop_0_bit_13
ldx: $0018,y
stx spriteIdx
cmp #0
jne :loop_1_bit_13
jmp BlitOneSprite
:loop_0_bit_13 lsr
bcc :loop_0_bit_14
ldx: $001A,y
stx spriteIdx
cmp #0
jne :loop_1_bit_14
jmp BlitOneSprite
:loop_0_bit_14 lsr
bcc :loop_0_bit_15
ldx: $001C,y
stx spriteIdx
cmp #0
jne :loop_1_bit_15
jmp BlitOneSprite
; If we get to bit 15, then it *must* be a bit that is set
:loop_0_bit_15 ldx: $001E,y
stx spriteIdx
jmp BlitOneSprite
:loop_1_bit_1 lsr
bcc :loop_1_bit_2
ldx: $0002,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_2
jmp BlitTwoSprites
:loop_1_bit_2 lsr
bcc :loop_1_bit_3
ldx: $0004,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_3
jmp BlitTwoSprites
:loop_1_bit_3 lsr
bcc :loop_1_bit_4
ldx: $0006,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_4
jmp BlitTwoSprites
:loop_1_bit_4 lsr
bcc :loop_1_bit_5
ldx: $0008,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_5
jmp BlitTwoSprites
:loop_1_bit_5 lsr
bcc :loop_1_bit_6
ldx: $000A,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_6
jmp BlitTwoSprites
:loop_1_bit_6 lsr
bcc :loop_1_bit_7
ldx: $000C,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_7
jmp BlitTwoSprites
:loop_1_bit_7 lsr
bcc :loop_1_bit_8
ldx: $000E,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_8
jmp BlitTwoSprites
:loop_1_bit_8 lsr
bcc :loop_1_bit_9
ldx: $0010,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_9
jmp BlitTwoSprites
:loop_1_bit_9 lsr
bcc :loop_1_bit_10
ldx: $0012,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_10
jmp BlitTwoSprites
:loop_1_bit_10 lsr
bcc :loop_1_bit_11
ldx: $0014,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_11
jmp BlitTwoSprites
:loop_1_bit_11 lsr
bcc :loop_1_bit_12
ldx: $0016,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_12
jmp BlitTwoSprites
:loop_1_bit_12 lsr
bcc :loop_1_bit_13
ldx: $0018,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_13
jmp BlitTwoSprites
:loop_1_bit_13 lsr
bcc :loop_1_bit_14
ldx: $001A,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_14
jmp BlitTwoSprites
:loop_1_bit_14 lsr
bcc :loop_1_bit_15
ldx: $001C,y
stx spriteIdx+2
cmp #0
jne :loop_2_bit_15
jmp BlitTwoSprites
:loop_1_bit_15 ldx: $001E,y
stx spriteIdx+2
jmp BlitTwoSprites
:loop_2_bit_2 lsr
bcc :loop_2_bit_3
ldx: $0004,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_3
jmp BlitThreeSprites
:loop_2_bit_3 lsr
bcc :loop_2_bit_4
ldx: $0006,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_4
jmp BlitThreeSprites
:loop_2_bit_4 lsr
bcc :loop_2_bit_5
ldx: $0008,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_5
jmp BlitThreeSprites
:loop_2_bit_5 lsr
bcc :loop_2_bit_6
ldx: $000A,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_6
jmp BlitThreeSprites
:loop_2_bit_6 lsr
bcc :loop_2_bit_7
ldx: $000C,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_7
jmp BlitThreeSprites
:loop_2_bit_7 lsr
bcc :loop_2_bit_8
ldx: $000E,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_8
jmp BlitThreeSprites
:loop_2_bit_8 lsr
bcc :loop_2_bit_9
ldx: $0010,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_9
jmp BlitThreeSprites
:loop_2_bit_9 lsr
bcc :loop_2_bit_10
ldx: $0012,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_10
jmp BlitThreeSprites
:loop_2_bit_10 lsr
bcc :loop_2_bit_11
ldx: $0014,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_11
jmp BlitThreeSprites
:loop_2_bit_11 lsr
bcc :loop_2_bit_12
ldx: $0016,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_12
jmp BlitThreeSprites
:loop_2_bit_12 lsr
bcc :loop_2_bit_13
ldx: $0018,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_13
jmp BlitThreeSprites
:loop_2_bit_13 lsr
bcc :loop_2_bit_14
ldx: $001A,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_14
jmp BlitThreeSprites
:loop_2_bit_14 lsr
bcc :loop_2_bit_15
ldx: $001C,y
stx spriteIdx+4
cmp #0
jne :loop_3_bit_15
jmp BlitThreeSprites
:loop_2_bit_15 ldx: $001E,y
stx spriteIdx+4
jmp BlitThreeSprites
:loop_3_bit_3 lsr
bcc :loop_3_bit_4
ldx $0006,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_4 lsr
bcc :loop_3_bit_5
ldx $0008,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_5 lsr
bcc :loop_3_bit_6
ldx $000A,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_6 lsr
bcc :loop_3_bit_7
ldx $000C,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_7 lsr
bcc :loop_3_bit_8
ldx $000E,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_8 lsr
bcc :loop_3_bit_9
ldx $0010,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_9 lsr
bcc :loop_3_bit_10
ldx $0012,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_10 lsr
bcc :loop_3_bit_11
ldx $0014,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_11 lsr
bcc :loop_3_bit_12
ldx $0016,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_12 lsr
bcc :loop_3_bit_13
ldx $0018,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_13 lsr
bcc :loop_3_bit_14
ldx $001A,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_14 lsr
bcc :loop_3_bit_15
ldx $001C,y
stx spriteIdx+6
jmp BlitFourSprites
:loop_3_bit_15 ldx $001E,y
stx spriteIdx+6
jmp BlitFourSprites
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
Complete initialization sequence.
2022-04-25 21:35:47 +00:00
DirtyTileProcs dw _TBDirtyTile_00,_TBDirtyTile_0H,_TBDirtyTile_V0,_TBDirtyTile_VH
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
;DirtyTileSpriteProcs dw _TBDirtySpriteTile_00,_TBDirtySpriteTile_0H,_TBDirtySpriteTile_V0,_TBDirtySpriteTile_VH
Checkpoint of work
2022-01-20 02:58:57 +00:00
; Blit tiles directly to the screen.
_TBDirtyTile_00
_TBDirtyTile_0H
]line equ 0
lup 8
ldal tiledata+{]line*4},x
sta: $0000+{]line*160},y
ldal tiledata+{]line*4}+2,x
sta: $0002+{]line*160},y
]line equ ]line+1
--^
rts
_TBDirtyTile_V0
_TBDirtyTile_VH
]src equ 7
]dest equ 0
lup 8
ldal tiledata+{]src*4},x
sta: $0000+{]dest*160},y
ldal tiledata+{]src*4}+2,x
sta: $0002+{]dest*160},y
]src equ ]src-1
]dest equ ]dest+1
--^
rts
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; If there are two or more sprites at a tile, we can still be fast, but need to do extra work because
; the VBUFF values need to be read from the direct page. Thus, the direct page cannot be mapped onto
; the graphics screen. We use the stack instead, but have to do extra work to save and restore the
; stack value.
BlitFourSprites
BlitThreeSprites
BlitTwoSprites
plb
tsc
sta stkSave ; Save the stack on the direct page
sei
clc
Checkpoint of work
2022-01-20 02:58:57 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
ldy tileAddr
lda screenAddr ; Saved in direct page locations
tcs
Working through integration bugs * Gave active list dedicated direct page space * Change active list bit test from ror to asl to avoid barrel shift * Various address fixes
2022-02-21 16:31:35 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
_R0W1
Working through integration bugs * Gave active list dedicated direct page space * Change active list bit test from ror to asl to avoid barrel shift * Various address fixes
2022-02-21 16:31:35 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{0*TILE_DATA_SPAN},y
ldx spriteIdx+2
andl spritemask+{0*SPRITE_PLANE_SPAN},x
oral spritedata+{0*SPRITE_PLANE_SPAN},x
ldx spriteIdx
andl spritemask+{0*SPRITE_PLANE_SPAN},x
oral spritedata+{0*SPRITE_PLANE_SPAN},x
sta $00,s
Checkpoint of work
2022-01-20 02:58:57 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{0*TILE_DATA_SPAN}+2,y
ldx spriteIdx+2
andl spritemask+{0*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{0*SPRITE_PLANE_SPAN}+2,x
ldx spriteIdx
andl spritemask+{0*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{0*SPRITE_PLANE_SPAN}+2,x
sta $02,s
Checkpoint of work
2022-01-20 02:58:57 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{1*TILE_DATA_SPAN},y
ldx spriteIdx+2
andl spritemask+{1*SPRITE_PLANE_SPAN},x
oral spritedata+{1*SPRITE_PLANE_SPAN},x
ldx spriteIdx
andl spritemask+{1*SPRITE_PLANE_SPAN},x
oral spritedata+{1*SPRITE_PLANE_SPAN},x
sta $A0,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{1*TILE_DATA_SPAN}+2,y
ldx spriteIdx+2
andl spritemask+{1*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{1*SPRITE_PLANE_SPAN}+2,x
ldx spriteIdx
andl spritemask+{1*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{1*SPRITE_PLANE_SPAN}+2,x
sta $A2,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
tsc
adc #320
tcs
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{2*TILE_DATA_SPAN},y
ldx spriteIdx+2
andl spritemask+{2*SPRITE_PLANE_SPAN},x
oral spritedata+{2*SPRITE_PLANE_SPAN},x
ldx spriteIdx
andl spritemask+{2*SPRITE_PLANE_SPAN},x
oral spritedata+{2*SPRITE_PLANE_SPAN},x
sta $00,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{2*TILE_DATA_SPAN}+2,y
ldx spriteIdx+2
andl spritemask+{2*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{2*SPRITE_PLANE_SPAN}+2,x
ldx spriteIdx
andl spritemask+{2*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{2*SPRITE_PLANE_SPAN}+2,x
sta $02,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{3*TILE_DATA_SPAN},y
ldx spriteIdx+2
andl spritemask+{3*SPRITE_PLANE_SPAN},x
oral spritedata+{3*SPRITE_PLANE_SPAN},x
ldx spriteIdx
andl spritemask+{3*SPRITE_PLANE_SPAN},x
oral spritedata+{3*SPRITE_PLANE_SPAN},x
sta $A0,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{3*TILE_DATA_SPAN}+2,y
ldx spriteIdx+2
andl spritemask+{3*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{3*SPRITE_PLANE_SPAN}+2,x
ldx spriteIdx
andl spritemask+{3*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{3*SPRITE_PLANE_SPAN}+2,x
sta $A2,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
tsc
adc #320
tcs
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{4*TILE_DATA_SPAN},y
ldx spriteIdx+2
andl spritemask+{4*SPRITE_PLANE_SPAN},x
oral spritedata+{4*SPRITE_PLANE_SPAN},x
ldx spriteIdx
andl spritemask+{4*SPRITE_PLANE_SPAN},x
oral spritedata+{4*SPRITE_PLANE_SPAN},x
sta $00,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{4*TILE_DATA_SPAN}+2,y
ldx spriteIdx+2
andl spritemask+{4*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{4*SPRITE_PLANE_SPAN}+2,x
ldx spriteIdx
andl spritemask+{4*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{4*SPRITE_PLANE_SPAN}+2,x
sta $02,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{5*TILE_DATA_SPAN},y
ldx spriteIdx+2
andl spritemask+{5*SPRITE_PLANE_SPAN},x
oral spritedata+{5*SPRITE_PLANE_SPAN},x
ldx spriteIdx
andl spritemask+{5*SPRITE_PLANE_SPAN},x
oral spritedata+{5*SPRITE_PLANE_SPAN},x
sta $A0,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{5*TILE_DATA_SPAN}+2,y
ldx spriteIdx+2
andl spritemask+{5*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{5*SPRITE_PLANE_SPAN}+2,x
ldx spriteIdx
andl spritemask+{5*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{5*SPRITE_PLANE_SPAN}+2,x
sta $A2,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
tsc
adc #320
tcs
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{6*TILE_DATA_SPAN},y
ldx spriteIdx+2
andl spritemask+{6*SPRITE_PLANE_SPAN},x
oral spritedata+{6*SPRITE_PLANE_SPAN},x
ldx spriteIdx
andl spritemask+{6*SPRITE_PLANE_SPAN},x
oral spritedata+{6*SPRITE_PLANE_SPAN},x
sta $00,s
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 18:12:32 +00:00
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
lda tiledata+{6*TILE_DATA_SPAN}+2,y
ldx spriteIdx+2
andl spritemask+{6*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{6*SPRITE_PLANE_SPAN}+2,x
ldx spriteIdx
andl spritemask+{6*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{6*SPRITE_PLANE_SPAN}+2,x
sta $02,s
lda tiledata+{7*TILE_DATA_SPAN},y
ldx spriteIdx+2
andl spritemask+{7*SPRITE_PLANE_SPAN},x
oral spritedata+{7*SPRITE_PLANE_SPAN},x
ldx spriteIdx
andl spritemask+{7*SPRITE_PLANE_SPAN},x
oral spritedata+{7*SPRITE_PLANE_SPAN},x
sta $A0,s
lda tiledata+{7*TILE_DATA_SPAN}+2,y
ldx spriteIdx+2
andl spritemask+{7*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{7*SPRITE_PLANE_SPAN}+2,x
ldx spriteIdx
andl spritemask+{7*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{7*SPRITE_PLANE_SPAN}+2,x
sta $A2,s
_R0W0
lda stkSave
tcs
cli
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 18:12:32 +00:00
rts
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; There is only one sprite at this tile, so do a fast blit that directly combines a tile with a single
; sprite and renders directly to the screen
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
;
Commit to a huge unrolled loop to do bitfield -> render function
2022-02-25 23:05:32 +00:00
; NOTE: Expect X-register to already have been set to the correct VBUFF address
BlitOneSprite
ldy tileAddr ; load the address of this tile's data
lda screenAddr ; Get the on-screen address of this tile
plb
More sprite streamlining * Added a TS_LAST_VBUFF cached value in the tile store * Added a fast path for single sprite w/fast test * Improved raster timing granularity for visual profiling All of the code paths are generally good. Both the _RenderSprites and _ApplyDirtyTiles functions take a fair bit of raster time. Will continue to try and streamline the data structures and code to reduce overhead.`
2022-02-22 08:35:21 +00:00
phd
sei
clc
tcd
_R0W1
lda tiledata+{0*TILE_DATA_SPAN},y
andl spritemask+{0*SPRITE_PLANE_SPAN},x
oral spritedata+{0*SPRITE_PLANE_SPAN},x
sta $00
lda tiledata+{0*TILE_DATA_SPAN}+2,y
andl spritemask+{0*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{0*SPRITE_PLANE_SPAN}+2,x
sta $02
lda tiledata+{1*TILE_DATA_SPAN},y
andl spritemask+{1*SPRITE_PLANE_SPAN},x
oral spritedata+{1*SPRITE_PLANE_SPAN},x
sta $A0
lda tiledata+{1*TILE_DATA_SPAN}+2,y
andl spritemask+{1*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{1*SPRITE_PLANE_SPAN}+2,x
sta $A2
tdc
adc #320
tcd
lda tiledata+{2*TILE_DATA_SPAN},y
andl spritemask+{2*SPRITE_PLANE_SPAN},x
oral spritedata+{2*SPRITE_PLANE_SPAN},x
sta $00
lda tiledata+{2*TILE_DATA_SPAN}+2,y
andl spritemask+{2*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{2*SPRITE_PLANE_SPAN}+2,x
sta $02
lda tiledata+{3*TILE_DATA_SPAN},y
andl spritemask+{3*SPRITE_PLANE_SPAN},x
oral spritedata+{3*SPRITE_PLANE_SPAN},x
sta $A0
lda tiledata+{3*TILE_DATA_SPAN}+2,y
andl spritemask+{3*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{3*SPRITE_PLANE_SPAN}+2,x
sta $A2
tdc
adc #320
tcd
lda tiledata+{4*TILE_DATA_SPAN},y
andl spritemask+{4*SPRITE_PLANE_SPAN},x
oral spritedata+{4*SPRITE_PLANE_SPAN},x
sta $00
lda tiledata+{4*TILE_DATA_SPAN}+2,y
andl spritemask+{4*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{4*SPRITE_PLANE_SPAN}+2,x
sta $02
lda tiledata+{5*TILE_DATA_SPAN},y
andl spritemask+{5*SPRITE_PLANE_SPAN},x
oral spritedata+{5*SPRITE_PLANE_SPAN},x
sta $A0
lda tiledata+{5*TILE_DATA_SPAN}+2,y
andl spritemask+{5*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{5*SPRITE_PLANE_SPAN}+2,x
sta $A2
tdc
adc #320
tcd
lda tiledata+{6*TILE_DATA_SPAN},y
andl spritemask+{6*SPRITE_PLANE_SPAN},x
oral spritedata+{6*SPRITE_PLANE_SPAN},x
sta $00
lda tiledata+{6*TILE_DATA_SPAN}+2,y
andl spritemask+{6*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{6*SPRITE_PLANE_SPAN}+2,x
sta $02
lda tiledata+{7*TILE_DATA_SPAN},y
andl spritemask+{7*SPRITE_PLANE_SPAN},x
oral spritedata+{7*SPRITE_PLANE_SPAN},x
sta $A0
lda tiledata+{7*TILE_DATA_SPAN}+2,y
andl spritemask+{7*SPRITE_PLANE_SPAN}+2,x
oral spritedata+{7*SPRITE_PLANE_SPAN}+2,x
sta $A2
_R0W0
cli
pld
Rough outline of streamlined sprite subsystem * Split the creation of the sprite stamps from adding the sprites themselves. This allows for 48 stamps that can be pre-rendered and quickly reassigned to sprites for animations. * Inlined all calls to PushDirtyTile. This both removed significant overhead from calling the small function and, since almost all callers we checking multiple tiles, we were able to avoid incrementing the count each time and just add a single incrments at the end. * Switched from recording each tile that a sprite intersects with each from to only recording the top-left tile and the overlap size. This reduced overhead for larger sprites and removed the needs for an end-of-list marker. * Much more aggressive caching of Sprite and Tile Store values in order to streamline the inner tile dispatch routines. * Moving TileStore and Sprites (and other supporting data structures) into a separate data bank. Needed just for size purposes and provide micro-optimizations by opening up the use of abs,y addressing modes. * Revamped multi-sprite rendering code to avoid the need to copy any masks and all stacked sprites can be drawn via a sequence of and [addrX],y; ora (addrX),y where addrX is set once per tile. * General streamlining to reduct overhead. This work was focused on removing as much per-tile overhead as possible.
2022-04-20 12:43:16 +00:00
rts
Reference in New Issue Copy Permalink