| |
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?
|
|
... 2 posts hidden. Click here to view all posts....
|
| |
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. |
| |
j0x
Registered: Mar 2004
Posts: 215 |
IIRC, I used the method that Danzig is describing for my sideborder dypp in The Barn 3. OTOH, the bordersprite usage in that one is simple, so any method would work.
|
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
the solution I used is somewhat "quick & dirty", but it
worked for me at the time:
If a sprite is in the problematic area (check X coord)
then close the border on the 1st line of the sprite.
It has some visible side-effects when another sprite is
displayed in the border on the same line, but that can be
improved with some sinus tweaking..
You can see an example of this in the side-border scroller
in Insomnia. |
| Previous - 1 | 2 - Next |
