RHillFake Posted August 17, 2014 Share Posted August 17, 2014 Is there anywhere were I can get information on how to make data tables for sprite rotation and learn how to implement them? Thanks! Quote Link to comment Share on other sites More sharing options...
bogax Posted August 18, 2014 Share Posted August 18, 2014 (edited) The only real advantage to using a data statement for the sprite(s) data is that you can give it your own name which makes it easy to assign it to a constant so you can save a variable. Also you can put the data in hexadecimal or whatever and make things more compact in the source. But you don't have to use a data statement You could use the player statement. You could use seperate player statements for the different sprites and choose the appropriate one with eg an on gosub statement. Putting them all in one decleration saves code is all Here I've put the data in one long player statement. Each 7 lines/bytes is a single sprite. The first 7 bytes is sprite 0 the next 7 bytes is sprite 1 etc. The sprites are just like any other sprite they're just stacked in one sprite declaration. A data statement would be exactly the same except it would be a data statement not a player statement but the data could be exactly the same. The number of the sprite is shown in the score. sprites.bas sprites.bin Edited August 18, 2014 by bogax 1 Quote Link to comment Share on other sites More sharing options...
RHillFake Posted August 18, 2014 Author Share Posted August 18, 2014 The only real advantage to using a data statement for the sprite(s) data is that you can give it your own name which makes it easy to assign it to a constant so you can save a variable. Also you can put the data in hexadecimal or whatever and make things more compact in the source. But you don't have to use a data statement You could use the player statement. You could use seperate player statements for the different sprites and choose the appropriate one with eg an on gosub statement. Putting them all in one decleration saves code is all Here I've put the data in one long player statement. Each 7 lines/bytes is a single sprite. The first 7 bytes is sprite 0 the next 7 bytes is sprite 1 etc. The sprites are just like any other sprite they're just stacked in one sprite declaration. A data statement would be exactly the same except it would be a data statement not a player statement but the data could be exactly the same. The number of the sprite is shown in the score. sprites.bas sprites.bin Thank you Quote Link to comment Share on other sites More sharing options...
bogax Posted August 18, 2014 Share Posted August 18, 2014 Maybe I should elaborate a bit. You can use a constant with the player statement it's just a pain because the label is the line number of the player statement (ignoring white space, labels, and "end") so if you change anything there's a good chance you'll have to figure out the new label for the sprite data. Sprites can't cross page boundaries. If you use a player statement bB takes care of that for you automatically. If you use a data statement the simplest way to make sure no sprite in it crosses a page boundary is to align the data statement with a page boundary and be sure there's less than a page of sprite data. You could in principle (I think, I haven't tryed it) let a data statement cross a page boundary provided no individual sprite in it crossed a page boundary. But then you'd have to deal with the high byte of the sprite pointer and use 16 bit math (might be worth it if you have a lot of sprite data). bB sticks the sprite tables at the end of the program I think if you're using mutiple banks you end up with the sprite data in the last bank. A data statement goes where ever you put it. Presumably if you were using a data statement for your sprites the data statement would have to be in the last bank. It appears that the player statement is quite happy with hex data as long as there's not more than 8 bytes per line. With a player statement if you eg put in blank lines to seperate individual sprites each blank line ends up as a 0 byte in the data. That doesn't happen with a data statement. Quote Link to comment Share on other sites More sharing options...
bogax Posted August 20, 2014 Share Posted August 20, 2014 (edited) Just for the hell of it I tryed to parameterize the code so one could supply the details at the beginning of the code. I doubt if it's really practical I'd probably do the code differently rather than have it so generalized. If no_sprites, the number of sprites in the data statment, is 10 or less bB will use a hard coded multiply routine rather than call a mutiplication sub routine (the same as it does for any multiplication by a constant of 10 or less) There's a bit of assembly (lifted from the kernel) to fill in zero bytes if necessary to keep the data statement from crossing a page boundary. It must go immediately before the data statement. There's no provision for sprite colors. I don't expect the it would be very hard to do sprite colors (probably with a data statement). The assembler thows some errors but the code works and seems to be correct so I guess it's stuff that gets resolved after a couple passes but I'm not really sure. Here the sprites are taken from the score digits. You step through the sprites using joy right or left Of course that's not how you'd select the sprites for animation (you would use a timer or something). Works with the standard kernel I don't know if it would work with anything else. sprites_parameterized.bas sprites_parameterized.bin edit: here's something more animated note there are symmetries here that could be exploited using NUSIZx as the loon was suggesting parameterized_animation.bas parameterized_animation.bin another one removed the player no parameter and added a parameter for the number of frames between sprites changes player pointer is updated directly (no sprite number and so no multiplication) player0_parameterized.bas player0_parameterized.bin Edited August 21, 2014 by bogax 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted August 25, 2014 Share Posted August 25, 2014 (edited) Yet another one This uses two lists one to indicate the sprite to display and one for a corresponding color. If the color is odd the sprite is reflected. The lists are in reverse order, first item diplayed last, last item diplayed first. The first item/last diplayed should be the playfield background color to blank the sprite at the end of the animation. The animation starts when joy0fire is pressed (its supposed to be an explosion). list_animation.bas list_animation.bin Edited August 25, 2014 by bogax 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.