| |
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: 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 ;) |
| |
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. |
| Previous - 1 | 2 | 3 - Next |
