Jump to content
IGNORED

Robert M's Blog - bBasic - Multisprite flicker algorithm testing.


RSS Bot

Recommended Posts

Goals:

-> Get practice using the multisprite kernel

-> Observe the flicker management algorithm for virtual sprites in action.

 

Design:

-> Implement the playfield as a dark grey checkerboard to facilitate line counting

-> Use numbers for the sprite graphics to identify them on screen.

-> Arrange the sprites in a tight line so side by side veritcal differences are easier to measure.

-> Joy 0 moves the sprites. Up and down move virtual sprites 1 through 5 at different velocities to cause combinations of overlap.

-> Joy 0 left and right moves P0, M0, M1 and the ball vertically.

 

Implementation:

bin.gif

multitest.txt.bin ( 4K )

Number of downloads: 0

 

txt.gif

multitest.txt ( 4.33K )

Number of downloads: 0

 

 

Lessons learned:

-> M0 and M1 are drawn 1 scanline lower than all the other graphics which are aligned to the 2LK kernel line. This is not unsurprising, but may need to be considered for collision detection.

-> COLUP0 must be set every frame. The kernel resets it to black during drawscreen.

-> BUG? If a sprite or the ball is visible at the bottom line pair on the screen the last row of pixels is drawn for a 3rd scanline below the last PF graphics.

-> With the screenheight set to 84:

-----> P0's lower left corner of screen is x = 0, y = 11.

-----> P1's through P5 lower left corner of screen is x = 8, y = 8.

-----> For M0, M1 the lower left corner is x = 1, y = 1, but M0 and M1 droop 1 scanline down.

-----> Ball lower left corner is x = 1, y = 2.

-> Flicker behavior is the same for pfheight values of 1, 3 and 7.

-> Setting pfheight to 0 scrambles the screen as documented in the bBasic manual, but you can see when repositionings are being done.

-> Virtual sprites require a horizontal gap of 2 lines to reposition without flicker.

-> Flickering fails for some cases when more than 2 sprites overlap.

 

Recommendations for improving bBasic:

-> The language is fine, but the portion of the manual for the mulity sprite kernel has some unclear language.

------> What is the default value for pfheight?

------> The screenheights of 80 and 84 only work with some pfheights all 7 or less, but pfheight can be 15 and 31. What are the legal screenheights for those values. A table of legal combinations of screenheight and pfheight would make things more clear and complete.

 

Up Next:

-> TBD

 

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

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...