| |
Ricky
Registered: Jan 2008
Posts: 3 |
Strange sideborder error
So I've put some sprites in the sideborder and multiplexed them.
It seems that the sprites starts displaying one scanline before expected, and the output is garbaged bytes - but only when they're in the right border and only when they're about 24+ pixels from the edge of the normal screen.
Anyone has the slightest idea why this is happening?
|
|
| |
j0x
Registered: Mar 2004
Posts: 215 |
Sounds like the (well-known) internal sprite data pointer update, which happens in the border.
|
| |
Ricky
Registered: Jan 2008
Posts: 3 |
Are there any good tricks to avoid it? |
| |
j0x
Registered: Mar 2004
Posts: 215 |
You could try using another sprite (e.g., use sprite #7 instead of sprite #0, since each sprite has its pointer/data updated at a different horizontal position), but that may not help you. For an explanation, check out the section on access types in http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 359 |
The Vic's rasterlines doens't start at the first and last pixel postions (0 and 511) of the screen.
They start and end somewhere in the border. The same applies to sprites, but the beginning of a sprite rasterline is again at another x position.
By switching $d010 you can display one of the eight sprites
two times, so you get nine. But only at a certain position in the right border. So theres not much use of it.
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:The Vic's rasterlines doens't start at the first and last pixel postions (0 and 511) of the screen. its not very important in this case but i believe the last pixel position is 503 (63 cycles x 8 pixels == 504) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
As a general rule, use sprites 0,1,2,3 in the left border and sprites 4,5,6,7 in the right border. Preferably in reversed order, i.e:
3210 ........ 7654
This should help you avoid most update bugs in the sprites.
The problem you have is that the VIC fetches new sprite data at the exact same time as it is plotting the sprite.
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: As a general rule, use sprites 0,1,2,3 in the left border and sprites 4,5,6,7 in the right border. Preferably in reversed order, i.e:
3210 ........ 7654
This should help you avoid most update bugs in the sprites.
The problem you have is that the VIC fetches new sprite data at the exact same time as it is plotting the sprite.
Why would you want to use them in reverse order? I'm a bit confused? If you do that, sprite 4 is displayed very closely to where it gets updated. I dont understand why one would want to do this? |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
if you show sprites in order: 2,3,4,5,6,7,8,1 all is ok |
| |
HCL
Registered: Feb 2003
Posts: 728 |
I also don't get the idea of reverse order, does it really help for something? Me usually have #0 to the left and #7 to the righ in order. If with badlines, i use #4,5 to the left and #6,7 to the right (in order again).
AFAIK There is no *trick* to make that bug disappear. Often i open the border one line lower to avoid the bug, thus wasting one line of the sprite. But if you have a classic multiplexer with ypos-sinus stuff that's not a solution.
Last time i had this problem i think was in Smart Girls Hate Booze ,but that was a party demo so could just leave the bugs there to prove it was real. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
i once set the color and multicolor for that particular sprite in the rasterline below by having it "singlecolored bordercolored" (wow *G*) before iirc. that gave solution :) but for timecritical things its wasted cycles in the first line. |
... 2 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
