+Random Terrain Posted March 9, 2008 Share Posted March 9, 2008 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. Quote Link to comment Share on other sites More sharing options...
MausGames Posted March 9, 2008 Share Posted March 9, 2008 http://www.atariage.com/forums/index.php?showtopic=107835 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 9, 2008 Author Share Posted March 9, 2008 http://www.atariage.com/forums/index.php?showtopic=107835 Thanks. So, you have to use asm. There's not a normal bB way. Quote Link to comment Share on other sites More sharing options...
MausGames Posted March 9, 2008 Share Posted March 9, 2008 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 9, 2008 Author Share Posted March 9, 2008 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. Quote Link to comment Share on other sites More sharing options...
Fort Apocalypse Posted March 9, 2008 Share Posted March 9, 2008 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!) Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 9, 2008 Author Share Posted March 9, 2008 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. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted March 9, 2008 Share Posted March 9, 2008 (edited) 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 March 9, 2008 by SeaGtGruff Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 9, 2008 Author Share Posted March 9, 2008 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 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted March 10, 2008 Share Posted March 10, 2008 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 10, 2008 Author Share Posted March 10, 2008 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 11, 2008 Author Share Posted March 11, 2008 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 11, 2008 Author Share Posted March 11, 2008 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.