Jump to content
  • entries
    34
  • comments
    88
  • views
    25,982

bBasic - Multisprite flicker algorithm testing.

Sign in to follow this  
Robert M

707 views

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:

multitest.txt.bin

multitest.txt

 

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

Sign in to follow this  


3 Comments


Recommended Comments

Thanks for finding bugs - I wasn't aware of all of them.

 

pfheight default is 15 so I only need a table of 6 zeros for the initial playfield (as the PF is always drawn.)

 

The flickering algorithm works if no sprites overlap (in which there is no flicker, of course) or if all sprites that do overlap do so mutually (i.e if sprites 1-2 and 2-3 overlap, it may fail if 1-3 don't also overlap.) I've been meaning to improve the algorithm but haven't got around to it yet.

Share this comment


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

Actually, the kernel sets COLUP0 and COLUP1 to the scorecolor when it draws the score, so if you don't set them during every frame in the standard kernel, your player0 and player1 sprites will change to the scorecolor.

 

On the other hand, the multisprite kernel needs to use RAM to save the colors of player1 through player5, since they're all drawn with GRP1 and COLUP1, therefore it's able to remember what color to make them each time the frame is drawn. But since GRP0 isn't multiplexed (correct terminology?) the way GRP1 is, there's no separate RAM location for saving the color of player0, therefore the kernel can't remember what color to make it each time the frame is drawn; so it "inherits" the scorecolor, since that's the last color that COLUP0 is set to on each frame.

 

Aside from just setting COLUP0 during each frame (along with COLUP1 if you're using the standard kernel), a way to "correct" this behavior is to use one (or two) user variables for storing the color of player0 (and player1), and then use a vblank routine to automatically load the color into COLUP0 (and COLUP1) at the top of each frame. This would use up precious RAM, but it would save a few cycles during the overscan period. Or, you could just load a numeric literal into COLUP0 (and COLUP1) during a vblank routine, so that no RAM would need to be used; and if COLUP0 (and COLUP1) might vary depending on the situation, then you could use "if" or "on...goto" statements during the vblank to pick the correct color.

 

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

If you omit the "setheight" statement, it appears to default to 15 (16 double-lines), which gives 5.5 playfield pixels. But I'm not sure if this is always the case, or if it can vary depending on any factors.

 

------> 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.

The documentation says that screenheight can be only 80 or 84, and that 80 works only if pfheight is less than 8, but 84 works only if pfheight is less than 4. So the legal combinations should be as follows:

 

+-------+-------+-------+-------+
|-------| sh.88 | sh.84 | sh.80 |
+-------+-------+-------+-------+
| ph. 0 | valid | valid | valid |
+-------+-------+-------+-------+
| ph. 1 | valid | valid | valid |
+-------+-------+-------+-------+
| ph. 3 | valid | valid | valid |
+-------+-------+-------+-------+
| ph. 7 | valid |invalid| valid |
+-------+-------+-------+-------+
| ph.15 | valid |invalid|invalid|
+-------+-------+-------+-------+
| ph.31 | valid |invalid|invalid|
+-------+-------+-------+-------+

Note that 88 isn't a "legal" value for screenheight, but it's the default number of lines on the screen (if we exclude the score). However, you *can* set screenheight to 88, but you get the same result as if you'd set screenheight to 80-- for the most part. I defined 88 rows of playfield pixels, then tried all the combinations of pfheight and screenheight, and this is what I got:

 

+--------+------+------+------+------+
|--------|------| s.88 | s.84 | s.80 |
+--------+------+------+------+------+
| pfh. 0 | 88 r*| 80 r | 84 r*| 80 r*|
+--------+------+------+------+------+
| pfh. 1 | 44 r | 40 r | 42 r | 40 r |
+--------+------+------+------+------+
| pfh. 3 | 22 r | 20 r | 21 r | 20 r |
+--------+------+------+------+------+
| pfh. 7 | 11 r | 10 r | 10.5 | 10 r |
+--------+------+------+------+------+
| pfh.15 | 5.5r | X ***| X ***| X ***|
+--------+------+------+------+------+
| pfh.31 | 1 r**| X ***| 1 r**| X ***|
+--------+------+------+------+------+

The second column (with no screenheight shown) is where I didn't set the screenheight constant, so that the screen was the default height.

 

The third column shows where I set the screenheight constant to 88, even though that isn't supposed to be a valid value (but I wanted to try it anyway, since 88 is the default screen height). As you can see, it gave the same results as setting screenheight to 80, but with one interesting exception. In all cases where pfheights was set to 0, the last pfrow on the screen was the same as the one above, as if the next-to-last pfrow was stretched twice as high as the other pfrows. *But*, when I set screenheight to 88, I got the same number of lines as if I'd set screenheight to 80, except the last pfrow was correct!

 

In the boxes that say "1 r**," I got only 1 tall (32-line high) pfrow as indicated, except the rest of the screen was chopped off-- the single pfrow was followed by the score, and then by a huge overscan.

 

In the boxes that say "X ***," the screen rolled like crazy.

 

So my testing results don't quite jive with the "valid/invalid" chart given above. The "valid/invalid" chart is correct for screenheight 80, but pfheight 7 is actually valid (if weird) for screenheight 84. It's debatable whether pfheight 31 is valid with screenheight 84, since the screen is way too short. And it's debatable whether pfheight 31 is valid when no screenheight is specified (meaning it should default to 88), for the same reason.

 

Michael

Share this comment


Link to comment

Thanks for the feedback from both of you.

 

I just noticed that the virtual sprites can not scroll smoothly off and on the top of the screen as they can on the bottom. They just vanish 4 lines from the top. It looks like the horizontal positioning of the first virtual sprite happens in the top 4 lines on screen. Its no biggie, just a characteristic about the kernel worth noting.

 

Cheers!

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...