| |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
You could always use a variant of WVL's half sprite technique that just uses 1-2 pixel rows of overlap in definitions instead of 10. Then your overhead would only be 5-10% instead of 50%.
I tried to explain that above but may have failed. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: You could always use a variant of WVL's half sprite technique that just uses 1-2 pixel rows of overlap in definitions instead of 10. Then your overhead would only be 5-10% instead of 50%.
I tried to explain that above but may have failed.
AH! now i understand your point :)
Ofcourse you only save sprite defs if you need >2 sprites vertically.. nice :) |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Quote: AH! now i understand your point :)
Ofcourse you only save sprite defs if you need >2 sprites vertically.. nice :)
Chris,
I did read your post. It is something that would work very nicely. I will keep it in mind when I run in more problems (eg bad lines). The only problem I see with it is that I need more sprite images which consume more memory. And I predict that I need around 170 images in total
But I can see now that in the end I probably have no other choice. :-)
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: Chris,
I did read your post. It is something that would work very nicely. I will keep it in mind when I run in more problems (eg bad lines). The only problem I see with it is that I need more sprite images which consume more memory. And I predict that I need around 170 images in total
But I can see now that in the end I probably have no other choice. :-)
Well.. You could "cheat" by simply not allowing sprites to be placed on badlines (or, say, odd line to even things out). It depends on your game whether this is acceptable of course but I managed to multiplex all four sprites (with underlays) on the same line this way. I had to generate the interrupt code dynamically to manage it though.
Or I suppose you could swap all eight sprites simultaneously, even on a badline, by swapping between a pair of video matrices. Scrolling would be a mess though.. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Shorter overlaps also require nastier shuffling, and for maximal space use they also need the sprites to be triggered at different y positions depending on which frame is being displayed, and brought onscreen by changing their x-position or changing from a blank definition at the top and bottom of the area to be shown.
All quite unpleasant really, so not necessarily any less work than getting your interrupts stable. It's only a definite win if you have some memory up your sleeve.
Christopher. |
| |
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 |
