Help With Sprites & Assembly

[Cybearg]

This is basically a re-telling of a question posed elsewhere because I'm just not getting responses there and I don't know if it's because people are forgetting to check that forum or because no one knows. Maybe this will get more attention from you Assembly wizards.

 

I need a way to efficiently assign any sprite to any player. The idea here is the ability to randomize levels and the types and numbers of enemies that appear in them. Currently, a single player's sprite is set (at least through bB's DPC+ kernel) like so:

 

player2set0
   lda #<(playerpointers+2)
   sta DF0LOW
   lda #(>(playerpointers+2)) & $0F
   sta DF0HI
   LDX #<chop0
   STX DF0WRITE
   LDA #((>chop0) & $0f) | (((>chop0) / 2) & $70)
   STA DF0WRITE
   LDA #7
   STA player2height

chop0
   .byte  %00010000
   .byte  %00010000
   .byte  %00111001
   .byte  %00111001
   .byte  %01111111
   .byte  %01111111
   .byte  %00101000

 

This allows for some level of abstraction. The "<(playerpointers+2)" can be put in a data set and referenced by an index, as can "(>(playerpointers+2)) & $0F" and "#<chop0"

 

The problem comes with finding the high end of a sprite set. The "((>chop0) & $0f) | (((>chop0) / 2) & $70)" will not work in a data set, presumably due to the statement's complexity.

 

How can I set this up so that I can reference the player AND the sprite from an array, such as:

 

ldx temp1 ;the index of the player
ldy temp2 ;the index of the sprite

lda pointerlo, x
sta DF0LOW
lda ponterhi, x
sta DF0HI

LDX spritelo, y
STX DF0WRITE
LDA spritehi, y
STA DF0WRITE

LDA spriteheight, y
STA player2height, x

data pointerlo
<(playerpointers+2), <(playerpointers+4), <(playerpointers+6), <(playerpointers+, <(playerpointers+10)
end

data poniterhi
(>(playerpointers+2)) & $0F, (>(playerpointers+4)) & $0F, (>(playerpointers+6)) & $0F, (>(playerpointers+) & $0F, (>(playerpointers+10)) & $0F, 
end

data spritelo
<chop0, <tank0, <plane0
end

data spritehi
???
end

data spriteheight
7, 7, 7
end

 

How can this be done?

Edited April 3, 2013 by Cybearg

[RevEng]

The problem comes with finding the high end of a sprite set. The "((>chop0) & $0f) | (((>chop0) / 2) & $70)" will not work in a data set, presumably due to the statement's complexity.

 

Right. This complexity isn't supported by bB's data statement, which you appear to be using. If you substitute dasm .BYTE commands it will deal with that calculation just fine.

 

e.g.

 

spritehi
  .BYTE ((>chop0) & $0f) | (((>chop0) / 2) & $70)
  .BYTE ((>tank0) & $0f) | (((>tank0) / 2) & $70)
  .BYTE ((>plane0) & $0f) | (((>plane0) / 2) & $70)

[Cybearg]

And those can be referenced such as: STA spritehi, x ?

[RevEng]

Yep, though obviously LDA spritehi,x makes more sense in this context.

[Cybearg]

It doesn't seem to work correctly. I can make the ASM data sets with no problem, but referencing them gives me nothing but a black screen for a game. Even this:

 

temp1 = 0
temp2 = 0

 asm

playerlo
   .BYTE <(playerpointers+2)

playerhi
   .BYTE (>(playerpointers+2)) & $0F

spritelo
   .BYTE <chop0

spritehi
   .BYTE ((>chop0) & $0f) | (((>chop0) / 2) & $70)

   LDX temp1
   LDY temp2

   lda playerlo,x
   sta DF0LOW
   lda #(>(playerpointers+2)) & $0F
   sta DF0HI
   LDA #<chop0
   STA DF0WRITE
   LDA #((>chop0) & $0f) | (((>chop0) / 2) & $70)
   STA DF0WRITE
   LDA #7
   STA player2height,x
end

 

If I turn "lda playerlo,x" into "lda #<(playerpointers+2)" it works fine, but obviously then it isn't doing anything of what I need it to. What am I doing wrong, here?

Edited April 4, 2013 by Cybearg

[RevEng]

Stick your data outside of the code flow. What you've written will cause your data to be executed as opcodes.

[Cybearg]

Stick your data outside of the code flow. What you've written will cause your data to be executed as opcodes.

Excellent! It seems to work so far, at least with that single sprite I was testing. Thank you!

 

So why was it interpreted differently when in the game loop versus being outside it?

[RevEng]

No problem.

 

Assembly is low-level and literal. The statement ".BYTE <(playerpointers+2)" says to store a byte in ROM with the value of whatever "<(playerpointers+2)" evaluates to.

 

So your previous version was trying to execute your data as assembly commands, causing some random-ish crash. Moving the data ouside of the code flow allowed the rest of your code to actually run.

 

This isn't a problem with bB data statements, because bB generates assembly commands in front of the data that tells the CPU to jump over them. Assembly language leaves that detail up to you.