Reuse multiple bitmaps on multiple sprites

[vitoco]

To define a sprite bitmap, it is required to do something like this:

 

  playerX:
  %00011000
  %01100110
  %11011011
  %01100110
  %00011000
end

X is a number from 0 to 1 (standard kernel), 0 to 5 (multi sprite kernel) or 0 to 9 (DPC+ kernel), so you need to repeat the piece of code multiple times.

 

If you want to do some animation with N frames, you have to repeat the code inside IF-THEN or ON-GOTO structures for every player frame.

 

Is there a way in batari Basic to use the same N frames for all X players without having to rewrite X * N blocks when all players are moving at their own speed/direction/whatever?

 

I guess I could manually assign the pointers to a given data block and also update the corresponding height if needed, but how? Is there a simple bB instruction/assignment or must I write an ASM block?

 

Thanks...

 

 

 

[bogax]

This does something like what you want I think.

[vitoco]

Ok... the trick is to assign the following for each player when needed:

  playerXpointerlo = <BITMAP
  playerXpointerhi = >BITMAP
  playerXheight = HEIGHT

Thanks!

 

[CapitanClassic]

As explained on the randomterrain website, you can also do (at least for DPC+)

 Or all sprites 1-9 (sprite0 is special)

player2-3:
   %00111111
   %00111110
   %00000111
   %00011111
   %00111111
   %11111110
   %00111111
   %00011111
   %00000111
   %00111110
   %00111111
end

 

[+Karl G]

The data also needs to be defined in the last bank if it's a multi-bank project. If the data crosses a page boundary, then it may cause visual glitches. 

[vitoco]

5 minutes ago, CapitanClassic said:

As explained on the randomterrain website, you can also do (at least for DPC+)

 Or all sprites 1-9 (sprite0 is special)

player2-3:
   %00111111
   %00111110
   %00000111
   %00011111
   %00111111
   %11111110
   %00111111
   %00011111
   %00000111
   %00111110
   %00111111
end

 

I've read that, but it sets all the sprites in the range to the same frame at the same time... it is not what I want.

 

6 minutes ago, Karl G said:

The data also needs to be defined in the last bank if it's a multi-bank project. If the data crosses a page boundary, then it may cause visual glitches. 

I was thinking about that. How can I force the data block to be defined in the last bank?

 

I'm trying DPC+ kernel, BTW, so it will be banked 32K as I saw.

 

Am I too ambitious? This is my 6th day of bB experiments. And I also want to include the QuadTari!!! ?

 

[bogax]

1 hour ago, vitoco said:

Ok... the trick is to assign the following for each player when needed:

  playerXpointerlo = <BITMAP
  playerXpointerhi = >BITMAP
  playerXheight = HEIGHT

Thanks!

 

correct and as needed so eg in the example I pointed to the height never changes so it's set once

 

A slight elucidation of Karl G's point, the table can span a page boundary but an individual sprite definition should not cross a page boundary

If all the definitions are in a single page then you'll only need to change the lo byte

[vitoco]

6 hours ago, bogax said:

correct and as needed so eg in the example I pointed to the height never changes so it's set once

 

A slight elucidation of Karl G's point, the table can span a page boundary but an individual sprite definition should not cross a page boundary

If all the definitions are in a single page then you'll only need to change the lo byte

Those are great hints. Thanks!

 

Unfortunately, this does not seem to work for DPC+ kernel, except for player0. By reading DPCplusbB.h, it seems that a structure to manage each virtual player is copied into RAM portion of the ARM... this is completely new to me, so I can't figure out how this works. I'll try to find some examples...

 

[+Karl G]

6 hours ago, bogax said:

A slight elucidation of Karl G's point, the table can span a page boundary but an individual sprite definition should not cross a page boundary

If all the definitions are in a single page then you'll only need to change the lo byte

That is true, but not what I meant. If an individual table crosses a page boundary in the middle, it will likely result in screen distortion this is what Freshbrood experienced with his Mortal Kombat work-in-progress. I have been brainstorming ways to get around this problem, such as perhaps having the ability to define a data statement in a way that forces it to be aligned properly at compile time. Alternate leg, perhaps a way could be devised to Define Sprites without assigning them, and allow them to be assigned to multiple player objects. 

[+Karl G]

20 minutes ago, vitoco said:

Those are great hints. Thanks!

 

Unfortunately, this does not seem to work for DPC+ kernel, except for player0. By reading DPCplusbB.h, it seems that a structure to manage each virtual player is copied into RAM portion of the ARM... this is completely new to me, so I can't figure out how this works. I'll try to find some examples...

 

Yeah, Sprites are stored differently internally with the DPC+ kernel. As CaptainClassic explain, though, you can Define multiple players at once to share Sprite data with that kerneln tthough. Unless I am misunderstanding you, in your example, you could set multiple players at once with one loop using DPC+.

[bogax]

1 hour ago, Karl G said:

That is true, but not what I meant. If an individual table crosses a page boundary in the middle, it will likely result in screen distortion this is what Freshbrood experienced with his Mortal Kombat work-in-progress. I have been brainstorming ways to get around this problem, such as perhaps having the ability to define a data statement in a way that forces it to be aligned properly at compile time. Alternate leg, perhaps a way could be devised to Define Sprites without assigning them, and allow them to be assigned to multiple player objects. 

hmm

You shouldn't need to align the table as a whole.

 

Freshbrood didn't post his code so it's hard to know what's going on there.

 

As far as aligning the table goes, what's wrong with the align directive you were using?

 

bB sometimes includes some assembly to generate the correct padding. (15 is the length of the table -1)

 

   2511  f730                  -          if    (<*) > (<(*+15))
   2512  f730                  -          repeat    ($100-<*)
   2513  f730                  -          .byte    0
   2514  f730                  -          repend
   2515  f730                          endif

 

   

[+Karl G]

27 minutes ago, bogax said:

hmm

You shouldn't need to align the table as a whole.

 

Freshbrood didn't post his code so it's hard to know what's going on there.

 

As far as aligning the table goes, what's wrong with the align directive you were using?

 

bB sometimes includes some assembly to generate the correct padding. (15 is the length of the table -1)

 

 

   2511  f730                  -          if    (<*) > (<(*+15))
   2512  f730                  -          repeat    ($100-<*)
   2513  f730                  -          .byte    0
   2514  f730                  -          repend
   2515  f730                          endif

 

 

   

 

I looked at his code privately, and that's what I figured out.

 

Yes, bB does align data such as player graphics to avoid cycle count discrepancies during the display kernel. Data from a normal data table does not automatically get aligned, however. Normally there is no need to align these kinds of data tables, as the extra cycles when reading from parts of the table that cross the page boundary have a minimal impact for non-kernel code. My conditional align directive is a solution for that.

 

As it stands now, sharing sprite data requires going "under the hood" and setting pointers, making sure the data is defined in the right place, and making sure the data does not cross a page boundary, which are things a bB programmer doesn't usually need to worry about. Since I am trying to help with bB maintenance, I was brainstorming how sharing sprite data could be accomplished in a more user-friendly way via changes to the language itself. E.g. perhaps a "spritedata" keyword could be added that would automatically put data in the graphics bank, and ensure that the data doesn't cross page boundaries. What do you think?

[bogax]

50 minutes ago, Karl G said:

As it stands now, sharing sprite data requires going "under the hood" and setting pointers, making sure the data is defined in the right place, and making sure the data does not cross a page boundary, which are things a bB programmer doesn't usually need to worry about. Since I am trying to help with bB maintenance, I was brainstorming how sharing sprite data could be accomplished in a more user-friendly way via changes to the language itself. E.g. perhaps a "spritedata" keyword could be added that would automatically put data in the graphics bank, and ensure that the data doesn't cross page boundaries. What do you think?

 heh heh
 
 I think they ought to just bite the bullet and learn enough about what's
 going on under the hood to know what they're doing
 Its not THAT complicated.

 I think it would be useful to have some lowest-common-denominator way of choosing
 among multiple sprite definitions for animations and such built in to bB
 Something more stream-lined than the usual clumsy, wasteful string of if-thens

 

 Given the variety of ways it might be done and the possible tradeoffs
 it might be better to have a utility that generated bB or assembly
 and could be more general (in addition to whatever got included in bB)

 

Besides, if bB is going to be augmented I'd rather see the effort
go in to other things.