Robert M's Blog - bBasic - Playing with sprite animation.

[RSS Bot]

Goals:

-> Explore sprite animation in bBasic using the Multisprite kernel.

-> Prototyping of a possible game idea using pure bBasic.

 

Design:

-> Start from the multisprite test program.

-> Render the Playfield as a cavern. PF0 is set always on to form left and right walls.

-> Put player 0 on the bottom of the cavern as a warrior.

-> Left and right joystick motions move the player sprite.

-> four frames of running animation are used plus a single standing still frame.

-> Running left is shown with the original sprites flipped vertically.

-> Choosing the frame of animation shown is done by taking the two lowest order bits of the sprite's current x-position which form a value from 0 to 3.

 

Implementation:

main.txt ( 5.72K )

Number of downloads: 0

 

main.txt.bin ( 4K )

Number of downloads: 0

 

 

Lessons learned:

-> The REFPx registers are cleared by the score kernel and need to be set every frame.

-> BUG! There seems to be a bug in the compiler for the multisprite kernel. It seems that sprite images are stored in ROM with both a leading and trailing zero byte.

The trailing byte is left off for the last Player0: image defined, and the first byte of the playfield graphics bleeds through.

This can be seen as the horizontal bar above the player sprite when it is not moving left or right.

I can get rid of the bar by injecting a dummy image of one line with no bits set as the last image for player0, but ultimately this seems like a bug that needs to be fixed.

-> Sprite animation for player0 is really easy in bBasic, but it seems overly complex for sprites 1 through 5 in the multisprite kernel.

 

Recommendations for improving bBasic:

-> I haven't looked at all the details in the kernel, but I am surprised that sprites need to be padded on both ends with a zero byte.

I can understand a traling zero to turn the sprite off, but what is the leading zero for?

Could the height of all sprites be reduced by 1 and save a fair number of ROM bytes? More investigation is needed for me to understand what bBasic is doing.

 

-> The way the language defines sprite images and sets them to a particular sprite does not allow you to reuse a sprite definition for different sprites.

It seems that I must redefine the same sprite 5 times to set sprites 1 through 5 in the mutlisprite kernel to show the exact same thing. So ROM space is

used 5x as fast as should be necessary. An alternate method for defining and setting sprites would be a nice addition to the language.

Let the programmer declare a table of sprites images, and then set the sprite pointers and heights from the table with an index value.

Each image declaration can start with a user defined label that the compiler sets the label to the table index for the following image definition.

 

Up Next:

-> Turning 6 sprites into 12.

 

http://www.atariage.com/forums/index.php?a...;showentry=3854