12 replies to this topic

[Random Terrain]

If you have two sprites that are going to use the same images, is there any way for the sprites to share the same image information instead of having two sets of the same images?


Thanks.

[MausGames]

http://www.atariage....howtopic=107835

[Random Terrain]

MausGames, on Sun Mar 9, 2008 5:57 AM, said:

http://www.atariage....howtopic=107835

Thanks. So, you have to use asm. There's not a normal bB way.

[MausGames]

Not yet, that I know of, but I think I remember hearing about Batari adding something to allow this in the next update. Seems like it would have already been there, with the majority of two-player games using the same sprite, huh?

[Random Terrain]

MausGames, on Sun Mar 9, 2008 7:06 AM, said:

Not yet, that I know of, but I think I remember hearing about Batari adding something to allow this in the next update. Seems like it would have already been there, with the majority of two-player games using the same sprite, huh?

That would be a great addition to bB. I hope it's included in the next update.

[Fort Apocalypse]

See the code that Michael gave me in the later/latest version of Titan Diamonds.

The only wierd thing is having to go into the asm generated by the compiler to get a number out of it when it doesn't compile, but other than that is relatively straightforward to use. (Thanks, Michael!)

[Random Terrain]

Fort Apocalypse, on Sun Mar 9, 2008 11:53 AM, said:

See the code that Michael gave me in the later/latest version of Titan Diamonds.

The only wierd thing is having to go into the asm generated by the compiler to get a number out of it when it doesn't compile, but other than that is relatively straightforward to use. (Thanks, Michael!)

Thanks. Still looks kind of complicated with lots of stuff to add, so I'll just use multiple copies until the next version of bB is released.

[SeaGtGruff]

Random Terrain, on Sun Mar 9, 2008 12:59 PM, said:

Fort Apocalypse, on Sun Mar 9, 2008 11:53 AM, said:

See the code that Michael gave me in the later/latest version of Titan Diamonds.

The only wierd thing is having to go into the asm generated by the compiler to get a number out of it when it doesn't compile, but other than that is relatively straightforward to use. (Thanks, Michael!)

Thanks. Still looks kind of complicated with lots of stuff to add, so I'll just use multiple copies until the next version of bB is released.

Depending on what you're trying to do, you might not need any assembly code at all. For example, if you want to set the two sprites to the same shape at the same time, just do something like the following:

   player0:
   %00111100
   %01000010
   %10011001
   %10100101
   %10000001
   %10100101
   %01000010
   %00111100
end

   player1pointerhi = player0pointerhi
   player1pointerlo = player0pointerlo
   player1height = player0height

It's really only when you want the two sprites to share the same data tables, yet be able to have different shapes than each other at any given time, that you might need to start using any assembly code-- and even then, you don't need assembly, you really just need a way to set the pointers as needed. For example:

   rem * define a table of three 8x8 sprite shapes, using player0
   player0:
   %00111100
   %00011000
   %00011000
   %00011000
   %00011000
   %00011000
   %00111000
   %00011000
   %01111110
   %00110000
   %00011000
   %00001100
   %00000110
   %00000110
   %01100110
   %00111100
   %00111100
   %01100110
   %00000110
   %00000110
   %00011100
   %00000110
   %01100110
   %00111100
end

   rem * set the hi pointers and heights (player0pointerhi is already set)
   player1pointerhi = player0pointerhi
   player0height = 7 : player1height = 7

   rem * save the lo pointer for the start of the table
   dim save_pointerlo = a
   save_pointerlo = player0pointerlo
   rem * you could also save a variable by using a constant,
   rem * but then you'd need to know where the shape table is stored in ROM
   rem * so you could set the constant to the appropriate value

   rem * define a table of offset values
   data offset
   0,8,16
end

   rem * set the two players to whichever shapes are desired
   rem * the three shapes are numbered 0 to 2

   rem * set player0 to shape 1
   player0pointerlo = save_pointerlo + offset[1]

   rem * set player1 to shape 2
   player1pointerlo = save_pointerlo + offset[2]

This example assumes that all the shapes in the table are the same height. You could also use shapes of different heights, but then you'd also need a table of height values:

   rem * define a table of offset values
   rem * each offset increases by the height of the previous shape
   data offset
   0,4,10,18,28
end

   rem * define a table of height values
   rem * the height values are 1 less than the actual height
   rem * (i.e., 4 lines high would be a value of 3),
   rem * since the line numbers begin with 0
   data height
   3,5,7,9,11
end

   rem * set the two players to whichever shapes are desired
   rem * the five shapes are numbered 0 to 4

   rem * set player0 to shape 2
   player0pointerlo = save_pointerlo + offset[2]
   player0height = height[2]

   rem * set player0 to shape 4
   player1pointerlo = save_pointerlo + offset[4]
   player1height = height[4]

Michael

Edited by SeaGtGruff, Sun Mar 9, 2008 4:56 PM.

[Random Terrain]

SeaGtGruff, on Sun Mar 9, 2008 5:54 PM, said:

Depending on what you're trying to do, you might not need any assembly code at all.

Thanks. I don't know what I'll need in the future, but right now I have a list of numbers (0 through 31). Some sprites would use 0-31 while others would only use 0-15. The numbers would be changed by the movement of the joystick.

As the old code is at this moment, it jumps to the needed sprite image:

 on frequency goto 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

[SeaGtGruff]

Random Terrain, on Sun Mar 9, 2008 6:17 PM, said:

SeaGtGruff, on Sun Mar 9, 2008 5:54 PM, said:

Depending on what you're trying to do, you might not need any assembly code at all.

Thanks. I don't know what I'll need in the future, but right now I have a list of numbers (0 through 31). Some sprites would use 0-31 while others would only use 0-15. The numbers would be changed by the movement of the joystick.

As the old code is at this moment, it jumps to the needed sprite image:

 on frequency goto 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

That should be pretty easy to simplify using a table of offsets, and if necessary a table of heights as well. Are the shapes all the same height? And what about colors, are they all the same color? (You could make a data table of colors as well, if the sprites are all solid colors instead of multicolored.)

Michael

[Random Terrain]

SeaGtGruff, on Sun Mar 9, 2008 7:43 PM, said:

That should be pretty easy to simplify using a table of offsets, and if necessary a table of heights as well. Are the shapes all the same height? And what about colors, are they all the same color? (You could make a data table of colors as well, if the sprites are all solid colors instead of multicolored.)

Yep, same height and no multicolored sprites (all of the sprites can be the same color). I'd be using the Multisprite Kernel for maximum sprites since I need to display 6 numbers. I'm looking for whatever is easiest to do and understand. Too much of what I learn doesn't stick, so the easier the better since I'll have to relearn it over and over again.

Here's an example of my old code for just one sprite:

0
 player1:
 %00000000
 %11100000
 %10100000
 %10100000
 %10100000
 %10100000
 %10100000
 %11100000
end
 goto gameloop

1
 player1:
 %00000000
 %11100000
 %01000000
 %01000000
 %01000000
 %01000000
 %11000000
 %01000000
end
 goto gameloop

2
 player1:
 %00000000
 %11100000
 %10000000
 %10000000
 %11100000
 %00100000
 %00100000
 %11100000
end
 goto gameloop

3
 player1:
 %00000000
 %11100000
 %00100000
 %00100000
 %01100000
 %00100000
 %00100000
 %11100000
end
 goto gameloop


 . . . blah blah blah . . .


29
 player1:
 %00000000
 %11100010
 %10000010
 %10000010
 %11101110
 %00101010
 %00101010
 %11101110
end
 goto gameloop

30
 player1:
 %00000000
 %11101110
 %00101010
 %00101010
 %01101010
 %00101010
 %00101010
 %11101110
end
 goto gameloop

31
 player1:
 %00000000
 %11101000
 %00101000
 %00101000
 %01101000
 %00101000
 %00101000
 %11101000
end
 goto gameloop

Thanks.

[Random Terrain]

After a lot of trial and error and irritation because the program wouldn't compile, I found out that sprites seem to have a height limit of 255 (which makes sense). If I wanted to use 8 by 8 sprites, I couldn't use a full 32, I could only have 31. The good news is that the sprites I made have one blank row, so all I need to do is remove the blank rows with find and replace and I can have all 32 sprites.

Thanks again for giving me a way to reuse sprite images.

[Random Terrain]

I figured out that I didn't need to define a table of offset values. So instead of using this:

   rem * set player0 to shape 1
   player0pointerlo = save_pointerlo + offset[1]

   rem * set player1 to shape 2
   player1pointerlo = save_pointerlo + offset[2]

I set player0height and player1height to 6 and used this:

   rem * set player0 to shape 1
   player0pointerlo = tone * 7 + 1

   rem * set player1 to shape 2
   player1pointerlo = frequency * 7 + 1

Now that I have this part figured out, I need to see if it will work with more than 2 sprites.