Help! (Wierd Stuff When Slowdown Occurs) (Solved)

[Drew Sebastino]

I don't have a clue as to what's going on, but whenever there's any slowdown, things get crazy when they normally don't. I have it to where when the player is facing right and is firing with the y button, the bullets stand still, which is intentional. Whenever there get to be something like 100 bullets, the game slows down, and for some reason, sprites or objects (I can't tell which one unfortunately...) stop appearing when according to my object spawner and object identifier codes, there are suppose to be 128 objects max, so either they are coded wrong, or the sprites just aren't displaying for some reason. I recently tried to use direct page on everything, and I could have sworn then that when the game slowed down, all the sprites still displayed, so I don't have a clue. By the way, all the sprites are supposed to be black right now. I know the small amount that I have coded so far is very rough and unoptimized, but does anyone have any obvious suggestions on how to make it better? I'm just nervous because I've hardly done anything and I've already been able to see slowdown.

By the way, mostly look at the metasprite and object files. The rest are from walker and are pretty much fine.

Anyway, here's the file: (Sorry about this. )

Help!.zip

(299.62 KiB) Downloaded 102 times

[Khaz]

Very quick appraisal: You say you're using direct page, but in your vBlank you don't "PHD" to preserve the direct page register. If anything in your vBlank routine touches the D register, it will screw up whatever was in progress before the interrupt hit. That doesn't seem to be the case, but I do see "MapX" and "MapY" being accessed during vBlank. They're declared under ".segment "ZEROPAGE"". I don't know your language but sounds to me like it's supposed to read those with D = $0000 and your direct page is something else when vBlank hits.

[Drew Sebastino]

Very quick appraisal: You say you're using direct page, but in your vBlank you don't "PHD" to preserve the direct page register.

Yeah, that fixed everything. (The BG isn't going berserk and all the sprite slots are being occupied.)

[psycopathicteen]

It's running from the $00 bank, which is always slowROM speed. It needs to run from bank $80 or higher to run at fastROM speed.

[Drew Sebastino]

It's running from the $00 bank, which is always slowROM speed. It needs to run from bank $80 or higher to run at fastROM speed.

I know, I just want to try to make it faster before I make the transition to fastrom. I don't want to get too comfy with fastrom, so I'm using slowrom until I've optimized everything as good as it can be.

[psycopathicteen]

That's a good idea.

The metasprite routine you're using, I found out wasn't ideal. The main issue is metasprite overhead on single sprites. I'll post an updated version Tomarrow if I have the time.

[Drew Sebastino]

Maybe it would be ideal to give single sprites have their own routine?

[psycopathicteen]

Now that I think about it, you can have the routine determine if a metasprite is a single sprite or multiple sprites, and have a seperate optimized path for both kinds.

[Drew Sebastino]

You could look at "MetaspriteCount" at the beginning that holds the number of sprites are left in the Metasprite and if it is 1, you jump to the other code. With single sprites, you really don't need to worry about sprite positions for horizontal and vertical flipping.

[Drew Sebastino]

Ha! I made it to where it branched to another code if there was only 1 sprite, and I minorly cleaned up the existing one (it uses slightly less space in rom). There's no slowdown (for now, anyways...). Anyway, this is it:

Code: Select all

.proc start_metasprite
  phx
  phy
  rep #$30    ; A=16, X/Y=16
  ldy a:SpriteCount
  ldx a:MetaspriteTableOffset
  lda a:MetaspriteCount
  cmp #$0001
  bne horizontal_flip_check
  brl single_metasprite

horizontal_flip_check:
  stz a:HFlipMask
  lda Attributes
  bit #$4000
  beq vertical_flip_check
  lda #$FFFF
  sta a:HFlipMask

vertical_flip_check:
  stz a:VFlipMask
  lda Attributes
  bit #$8000
  beq metasprite_loop
  lda #$FFFF
  sta a:VFlipMask

metasprite_loop:
  cpy #$0200		    ; sees if all 128 sprites are used up
  beq done
  and #$00FF
  sta a:SpriteBuf1+1,y        ; Store sprite Y position in SpriteBuf1+1,y
  lda a:MetaspriteCount       ; If MetaspriteCount is zero, then we're done.  Otherwise we have
  beq done                  ; metasprites to iterate over and populate for DMA (see VBlank)

  lda a:Empty,x               ; 1st byte = sprite X position (value 0-255)
  eor a:HFlipMask
  clc
  adc XPosition
  cmp #256
  bcc sprite_x_not_out_of_bounds
  cmp #65504
  bcs sprite_x_not_out_of_bounds
  bra sprite_out_of_bounds

sprite_x_not_out_of_bounds:
  and #$01FF
  sta a:SpriteBuf3,y          ; Store sprite X position SpriteBuf1+y
  and #$00FF
  sta a:SpriteBuf1,y          ; Store sprite X position SpriteBuf1+y
  lda a:Empty+2,x             ; 1st byte = sprite X position (value 0-255)
  eor a:VFlipMask
  clc
  adc YPosition
  cmp #224
  bcc sprite_y_not_out_of_bounds
  cmp #65504
  bcs sprite_y_not_out_of_bounds
  bra sprite_out_of_bounds

sprite_y_not_out_of_bounds:
  sta a:SpriteBuf1+1,y
  lda a:Empty+4,x
  sta a:SpriteBuf3+2,y        ; Sprite size
  lda a:Empty+6,x
  eor Attributes
  sta a:SpriteBuf1+2,y        ; Palette/Character word
  iny
  iny
  iny
  iny

sprite_out_of_bounds:
  txa
  clc
  adc #$0008
  tax
  dec a:MetaspriteCount       ; Decrement MetaspriteCount by 1
  bra metasprite_loop       ; Back to the loop...

done:
  sty a:SpriteCount	    ; Says how many sprites have been made

single_done:
  ply
  plx
  rts

single_metasprite:
  cpy #$0200		    ; sees if all 128 sprites are used up
  beq single_done
  and #$00FF
  sta a:SpriteBuf1+1,y        ; Store sprite Y position in SpriteBuf1+1,y

  lda a:Empty,x               ; 1st byte = sprite X position (value 0-255)
  clc
  adc XPosition
  cmp #256
  bcc single_sprite_x_not_out_of_bounds
  cmp #65504
  bcs single_sprite_x_not_out_of_bounds
  bra single_sprite_out_of_bounds

single_sprite_x_not_out_of_bounds:
  and #$01FF
  sta a:SpriteBuf3,y          ; Store sprite X position SpriteBuf1+y
  and #$00FF
  sta a:SpriteBuf1,y          ; Store sprite X position SpriteBuf1+y
  lda a:Empty+2,x             ; 1st byte = sprite X position (value 0-255)
  clc
  adc YPosition
  cmp #224
  bcc single_sprite_y_not_out_of_bounds
  cmp #65504
  bcs single_sprite_y_not_out_of_bounds
  bra single_sprite_out_of_bounds

single_sprite_y_not_out_of_bounds:
  sta a:SpriteBuf1+1,y
  lda a:Empty+4,x
  sta a:SpriteBuf3+2,y        ; Sprite size
  lda a:Empty+6,x
  eor Attributes
  sta a:SpriteBuf1+2,y        ; Palette/Character word
  lda a:SpriteCount	    ; Says how many sprites have been made
  clc
  adc #$0004
  sta a:SpriteCount	    ; Says how many sprites have been made

single_sprite_out_of_bounds:
  ply
  plx
  rts

.endproc

[Drew Sebastino]

This is random, but I was putting some extra stuff in ram and when I tried to assemble the file, I got a "Memory area overflow in 'BSS' ". Don't I have to move the table somewhere else then? What does "BSS" mean again?

[Khaz]

"BSS" is on line 97 of the game.asm file you attached:

Code: Select all

.segment "BSS"

I am assuming that your assembler is taking each "segment" and storing it in the first free space it finds in one of the banks of $8000 in your ROM. If you make a segment bigger than $8000 it can't fit in a bank and I'm guessing that's your problem.

EDIT: I don't know how ca65 does things but in WLA I like to keep things organized manually. I declare each of the 127 banks manually and put files in them with .include, which I'm sure is more of a pain in some ways than having more "free" sections, but at least I know where everything is.

[Drew Sebastino]

I am assuming that your assembler is taking each "segment" and storing it in the first free space it finds in one of the banks of $8000 in your ROM. If you make a segment bigger than $8000 it can't fit in a bank and I'm guessing that's your problem.

This is a table in ram though, so it shouldn't have anything to do with rom space or whatever.

[Khaz]

This is a table in ram though, so it shouldn't have anything to do with rom space or whatever.

The table is coming FROM rom, though. Either it has to fit inside a single bank, or you have to work around splitting your data across multiple banks.

It wouldn't do to have a segment arbitrarily splitting across multiple banks, say right in the middle of a table. You try to read sequentially from that table and suddenly you'll be reading from the wrong bank halfway through.

[Drew Sebastino]

FROM? What is that?