Page 1 of 2
Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Tue Apr 21, 2015 6:04 pm
by 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.
)
Re: Help! (Wierd Stuff When Slowdown Occurs)
Posted: Tue Apr 21, 2015 7:53 pm
by 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.
Re: Help! (Wierd Stuff When Slowdown Occurs)
Posted: Tue Apr 21, 2015 8:10 pm
by Drew Sebastino
Khaz wrote: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.)
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Tue Apr 21, 2015 8:17 pm
by 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.
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Tue Apr 21, 2015 8:35 pm
by Drew Sebastino
psycopathicteen wrote: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.
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Tue Apr 21, 2015 9:28 pm
by 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.
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Tue Apr 21, 2015 9:55 pm
by Drew Sebastino
Maybe it would be ideal to give single sprites have their own routine?
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Tue Apr 21, 2015 10:28 pm
by 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.
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Wed Apr 22, 2015 5:01 am
by 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.
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Wed Apr 22, 2015 1:56 pm
by 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
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Wed Apr 22, 2015 7:57 pm
by 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?
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Wed Apr 22, 2015 8:06 pm
by Khaz
"BSS" is on line 97 of the game.asm file you attached:
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.
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Wed Apr 22, 2015 8:14 pm
by Drew Sebastino
Khaz wrote: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.
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Wed Apr 22, 2015 8:18 pm
by Khaz
Espozo wrote: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.
Re: Help! (Wierd Stuff When Slowdown Occurs) (Solved)
Posted: Wed Apr 22, 2015 8:26 pm
by Drew Sebastino
FROM? What is that?