| |
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
|
|
... 15 posts hidden. Click here to view all posts....
|
| |
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)! |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Quote: 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)!
I update the spritepointers on position Y and the updated sprite starts to draw at Y also (not at Y+1). That's what I find strange. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
your 'other' problem will be a badly synchronized doublebuffering of d018 writes & changing of spr ptr writes. your first problem may be an emulator bug, vic article bug, or you are not on the cycle you think you are :D btw if you will only scroll horizontally, you should use the HW horizontal scrolling trick, the only disadvantage of it is that you loose 1 screen line at the bottom (sprite pointers weill become visible).
search for vsp and horizontal scrolling / agsp:
http://codebase64.org/ |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Well I use a rasterinterrupt at the appropiate rasterline and I walked through the VIC x-positions step by step via the emulator so I think I know where I am.
As far as the synchronizing I will have to look into it some more. If the flicker is not something obvious I must be doing something wrong.
As for the scrolling, it is in all directions, not only horizontal. But after I added the sprites I was first trying to get it to work horizontally. Don't need any more timing problems due to unpredictable bad lines. :-)
Well thanks for all the input, although I am not much wiser. Back to the drawing board.
|
| |
Barbarossa
Registered: May 2007
Posts: 31 |
I figured it out by myself.
Problem one:
I thought the raster Y is always the same as the sprite Y. But in fact raster Y = sprite Y + 1. I think WVL was trying to tell me that. It didn't come across though. :-)
Problem two:
On closer examination I noticed that the flickering also happened when modifying $d016 (not only on screen swaps). Since the main loop is copying the screen at that point, the instructions are more cycle insentive than when the screen is static and the main program is in a polling loop waiting for user input. Conclusion my interrupt arrives late and I miss a frame. I probably will need a stable raster for that to work.
After that I probably will need to find a solution how to change the spritepointers on a badline with all the sprites active :-(
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
Yes, that was what I was trying to say ;) |
| Previous - 1 | 2 | 3 - Next |
