| |
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
|
|
... 20 posts hidden. Click here to view all posts....
|
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
If you have more cycles than memory, you can cheat by copying first two or three rows from lower sprite to the one above it when you update the y coordinate. That way the sprite repeats with the new y position and new graphics, and you have couple of lines to change the sprite pointer before display reaches non-copied gfx rows. You need to restore those lines later, of course. |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
I finally got it to work. :-)
It was a bug after all (isn't it always). My color memory in the bufferscreen is located at $dc00 under the i/o. Normally i/o is up and roms are down. When my mainloop was copying the colorram it took the i/o down of course. My multiplexer then wrote Y-coordinates to ram therefore missing a frame.
And as a bonus the vertical scroll also works perfectly despite of the repositioning of the bad lines.
Thanks for all your help.
John
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"And as a bonus the vertical scroll also works perfectly despite of the repositioning of the bad lines."
huh? :) |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Well I think I can explain that. The sprites also move together with the background. So the position of the bad lines in relation to the sprite positions never change.
I was just anticipating some problems with that, but hey sometimes things aren't as bad as they seem to be :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ok, now I get it :) |
| Previous - 1 | 2 | 3 - Next |
