| |
Barbarossa
Registered: May 2007
Posts: 31 |
Sprite multiplexer question
Hi guys,
I am making a simple spritemultiplexer. And I have some timing problems.
There are two x-adjacent physical sprites (sprite 2-3) which are also y-adjacent and repeated 2 times (for a total of 2 by 3 sprites). Sprites 0-1 are also active but can be anywhere on the screen (not being multiplexed but they steal cycles).
I set the new Y-coordinate 1 or 2 rasterlines before the new sprite should be displayed. This is not a problem. But I have a problem with the spritepointers. My reasoning is that I should change the two spritepointers on rasterline Y-1 and before cycle 57 (when the new spritepointers are fetched by VIC). When I do this the last line of the previous sprite displays the data of the next sprite (too early).
When I add a couple of NOPs and wait until line Y (after the spritepointers are fetched) it seems to work. I don't understand why, because I think I am too late with the change. Or I am missing something?
One other problem. The sprites should scroll with the background graphics. The screens are doublebuffered. When the multiplexer works and I start to scroll, the sprites start to flicker as if I am missing frames. I am talking about an x-scroll here (so the badlines remain where they are), so I don't see any difference for the multiplexer whether the screen is static or scrolling. I am updating spritepointers for both screens.
It seems to me that timing is very critical even for my rather simple multiplexer. But when I read some of the multiplexers on codebase64 I never see any discussion regaring timing (only sorting). Just as if it's not that important.
This is my first go with a multiplexer so maybe you guys can point me in the right direction.
Thanks.
John
|
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Those articles probably discuss a multiplexer which re-uses all physical sprites in "round-robin" fashion, and in those timing isn't an issue until all sprites are in constant use caused by tightly packed sprite groups.
Remember that you can write the new Y-coordinate much earlier, as soon as the "old" sprite has started displaying. Though judging from what you tell about flickering when scrolling, you may well have some weird bugs in your code :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I tend to avoid needing such tight timing, either by staggering the sprite positions and using an extra sprite, eg:
0
01
01
21
20
20
10
12
12
_2
or by using slightly more definitions so I can duplicate the data from the last few pixel rows of each sprite in the last few pixel rows of the next sprite, then I can change sprite pointers every (eg) 19 lines instead of every 21, and it doesn't matter if I'm a little late switching. Note that the transition gets earlier in each row of sprites, so your sprite definitions will look a little shuffled with the muxer disabled.
Oh, and I agree with everything @cadaver wrote :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
sprite data fetch is done across 2 rasterlines. the 'right' side of the 'previous' and 'left' side of 'the current'. so you're wrong with assuming that all sprite data has been fetched in y-1.
sprites 0,1 are fetched on the right side, sprite 2 is present on both, and sprites 3,4,5,6,7 are fetched on the left side of a rasterline.
see the timings here:
https://sh.scs-trc.net/vic/vic_article_3.6.htm#3.6.3.
edit: well I'm wrong with where the sprite fetches are done, but no diagram for all 8 sprites in there.
edit2: your sprite flicker may be that you miss to update the sprite pointers in _both_ of your screens. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
For adjacent sprites, i'd always use the half-sprite method.
So for every switch of sprite, you have an extra sprite. This gives you 10 rasters of max delay you can stand, very easy.
Your extra sprite, would have the bottom part of the topmost sprite, and the top-part of your lowest sprite.
So if sprite 0 looks like
A
B
And the next like
C
D
you have an inbetween spritedefinition that looks like
C
B
Disadvantage : 50 (2 sprites) up to 100% (unlimited sprites) waste of extra memory :( |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
its funny how nobody notices, that the problem is not how to make the switch between the sprites bugfree ;) |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Quote: Those articles probably discuss a multiplexer which re-uses all physical sprites in "round-robin" fashion, and in those timing isn't an issue until all sprites are in constant use caused by tightly packed sprite groups.
Remember that you can write the new Y-coordinate much earlier, as soon as the "old" sprite has started displaying. Though judging from what you tell about flickering when scrolling, you may well have some weird bugs in your code :)
Ok, so the physical sprites are always as far apart as possible. I understand now why timing is not an issue here.
|
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Quote: sprite data fetch is done across 2 rasterlines. the 'right' side of the 'previous' and 'left' side of 'the current'. so you're wrong with assuming that all sprite data has been fetched in y-1.
sprites 0,1 are fetched on the right side, sprite 2 is present on both, and sprites 3,4,5,6,7 are fetched on the left side of a rasterline.
see the timings here:
https://sh.scs-trc.net/vic/vic_article_3.6.htm#3.6.3.
edit: well I'm wrong with where the sprite fetches are done, but no diagram for all 8 sprites in there.
edit2: your sprite flicker may be that you miss to update the sprite pointers in _both_ of your screens.
I understand how the sprite fetches work. And I am not assuming sprites fetches are done in Y-1. What I say is that I assume I have to FINISH updating the spritepointers BEFORE the VIC starts fetching them with starts in the right border on line Y-1 (with sprites 0-2).
+-----------------------------------+
| 1 2 6 |
|123456789012345678901..234567890123|Cycles
+---------[------(----..----)---]---+Borders
|3-4-5-6-7-rrrrrgggggg..gggg-N0s1s2s|Phi-1 VIC
|ss ssssss|Phi-2 VIC
|==xxxxxxxxxxxxxxxxxxx..xxxXXX======|Phi-2 CPU
+-----------------------------------+
// IRQevent - 7 cycles
// last instruction - 2-6 cycles
// sprite 3 - 2 cycles
// total - 10-15 cycles
multiplexer: sta STOREA // 13-18
stx STOREX // 16-21
sty STOREY // 19-24
preloadacc: lda #$00 // 21-26
sta $d005 // 25-30
sta $d007 // 29-34
ldy $01 // 32-37
ldx #$30 // 34-39
stx $01 // 37-42
(insert NOPs)
inc $07fa // 43-48
inc $07fb // 49-54
inc $dffa // 55-60
inc $dffb // 61-66 (next line)
The above version doesn't work. Even when not scrolling (only use one screen). Spritepointers Screen 1 ($0400) are updated in time. There are issues with screen 2 but I can always update the Y-coordinate one line earlier (which I already tried btw). But screen 1 should work and it doesn't. It does work when I insert enough NOPs so that the inc starts at the next line around cycle 4. This is the line the new sprite image starts.
I think this is strange because the VIC already read the spritepointers (and spritedata) at that point. This is what I don't understand.
edit: sorry about that mess. I did not realize that spaces were going to be trimmed. |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Quote: For adjacent sprites, i'd always use the half-sprite method.
So for every switch of sprite, you have an extra sprite. This gives you 10 rasters of max delay you can stand, very easy.
Your extra sprite, would have the bottom part of the topmost sprite, and the top-part of your lowest sprite.
So if sprite 0 looks like
A
B
And the next like
C
D
you have an inbetween spritedefinition that looks like
C
B
Disadvantage : 50 (2 sprites) up to 100% (unlimited sprites) waste of extra memory :(
This really is a nice idea. But I am afraid I don't have enough memory for that. I think I need a total of 170 sprite images. And to double that.... ouch :-(
But I like the idea. |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Quote: its funny how nobody notices, that the problem is not how to make the switch between the sprites bugfree ;)
Yes. The problem is how to understand why it is bugfree :-)
For my other problem. Scrolling of the background is done in the bottomborder, so there is no flicker and the scrolling goes at a constant speed of 1 pixel per frame.
The user can scroll the screen one charactier at a time. If the scrolling finishes after one character screen 2 is displayed. What happens is that when the screen is moved 7 pixels with $d016 everything is fine (sprites still on screen 1). Then the screen switches to screen 2 (in lower border). The sprites flicker but when the screen is static again the sprite images are ok. So updating the SP on screen 2 seems not to be a problem.
I am not ruling out any bugs at this point, but they seem rather unlikely so I was thinking maybe I am forgetting something obvious or doing something wrong. when I know that my thinking is ok I can hunt this baby to death for bugs. :-) |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Oh!
now I see :D
well, if you set your sprite pointers to Y, the sprites will be displayed at position Y+1!! And not at position Y!! So naturally, when you expect that you need to update the spritepointers at Y-1, actually you have top update at Y (Y+1-1)! |
... 15 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
