| |
Bastet
Registered: Jul 2005
Posts: 88 |
Sprite multiplexing, when is it save to edit the values?
I have a little question to the pros here, when is it save to edit the sprite data so that the first one dosnt get corrupted?
Do i have to wait the full 21 lines of the sprite or can i savely edit it somewhere in betwhen there? |
|
| |
Conrad
Registered: Nov 2006
Posts: 849 |
If you mean by changing the sprite image, then yes you will have to change the sprite after 21 lines. The best time to change it is when the cycle/raster position line is positioned just after the full sprite drawn (at the bottom of the sprite in other words.) Or, when the cycle position is around the border area, that'll be the best time to change it - that applies especially if the sprite is horizontally moving as well. |
| |
Bastet
Registered: Jul 2005
Posts: 88 |
Ok, thanks.
I thought the VIC has some kind of puffer for the sprite data, but after your post i must kill that dream ;) |
| |
Conrad
Registered: Nov 2006
Posts: 849 |
Again, this only applies for 1 sprite usually.
Having 8 sprites on the same row would be more work of course :) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
If you are only interested in changing the shape (framepointer) you can use a trick Usagi Yojimbo & Double Dragon 3 (possibly others) use: have a half-shape that has the new upper part but old lower part. Then changing the framepointer isn't timecritical anymore, but there's added memory use and added trouble of changing to the real new shape after the new sprite has started displaying. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: If you are only interested in changing the shape (framepointer) you can use a trick Usagi Yojimbo & Double Dragon 3 (possibly others) use: have a half-shape that has the new upper part but old lower part. Then changing the framepointer isn't timecritical anymore, but there's added memory use and added trouble of changing to the real new shape after the new sprite has started displaying.
I use this technique a lot too :) Makes life easy :D |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
Quote: Again, this only applies for 1 sprite usually.
Having 8 sprites on the same row would be more work of course :)
One solution that might work depending on what you're doing is to have two screens and alternate between setting the spritepointers in them, and then only switching d018 at the right moment to change all sprite data |
| |
Conrad
Registered: Nov 2006
Posts: 849 |
Quote: One solution that might work depending on what you're doing is to have two screens and alternate between setting the spritepointers in them, and then only switching d018 at the right moment to change all sprite data
That's quite a good and easy way actually! :)
I never thought of that. |
| |
Bastet
Registered: Jul 2005
Posts: 88 |
I thought so that double puffering will make my life a lot easier.
I dint wanted to take that route because of the memory constrains but i will investigate that :) |
| |
Devia
Registered: Oct 2004
Posts: 401 |
what hollowman said... especially if doing no-border stuff at the same time ;-)
It gives you the convenience of updating pointers and data when YOU have the time for it.. depending on what you want to achieve of course ;-)
|
| |
Radiant
Registered: Sep 2004
Posts: 639 |
So simple, yet so elegant. Thanks hollowman! :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
so simple that I have invented it by my own in around 92 after roughly 1.5 years of asm coding at the age of 16. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
*hands Oswald a medal* |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Most often I still stick to using intermediate sprite images since switching $d018 to change all pointers are so limiting when it comes to different Y-positions of the sprites etc + intermediate sprite images allows a slack of 10-11 raster lines, where as a $d018 change still needs quite tight timing.
For instance if you have NMI timers and shit going on at the same time that collides with the raster IRQ u're fucked with the $d018 approach anyways.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
radiantx :D |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quote: If you are only interested in changing the shape (framepointer) you can use a trick Usagi Yojimbo & Double Dragon 3 (possibly others) use: have a half-shape that has the new upper part but old lower part. Then changing the framepointer isn't timecritical anymore, but there's added memory use and added trouble of changing to the real new shape after the new sprite has started displaying.
Actually this doesn't have to take that much more memory, at least not double up. E.g. if you just need a flexibility of say 3 lines to change the sprite pointer, you only need to waste about 3 lines of gfx for each 18 lines, i.e. use 1/6th more memory.
Here's how I would do it... The first sprite is displayed normally on line 1-18. Then you need to change the pointer on line 19, 20 or 21. For these lines the new sprite image should double the line 19+20+21 of the old one. Then the new sprite image is displayed normally for its line 1-15, and after that the pointer needs to be changed on line 16/17/18. For these lines the new sprite image again has to double the gfx, and after this the displaying continues normally for line 19,20,21, and then cycles to 1,2,3...12. And so on, until the final sprite, which needs to end with 3 empty lines, where you have time to switch to an empty sprite image. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@JackAsser: Well, we know you're not so good at timing and stuff, but for the rest of us it's quite ok to just split d018 i think ;)..
Btw. look at Grahams Interference-Circles in DEM for hardcore sprite splitting :). Re-implemented in Tsunami etc.. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: @JackAsser: Well, we know you're not so good at timing and stuff, but for the rest of us it's quite ok to just split d018 i think ;)..
Btw. look at Grahams Interference-Circles in DEM for hardcore sprite splitting :). Re-implemented in Tsunami etc..
@HCL: Yeah I know, I suck. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
HCL, any trick in DEM that wasnt mentioned here ? |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
Quote: So simple, yet so elegant. Thanks hollowman! :-)
And I thank Iopop. Not everyone is wonderbug like Oswald when it comes to coding |
| |
Bastet
Registered: Jul 2005
Posts: 88 |
For the curious, i want to make a playfield out of sprites.
3x3 sprites with 2 layers (one mc and one hires) and the "non shown" sprites for nice and smooth per pixel scrolling. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you can switch pointers for 6 sprites easily on a non badline, so all you have to take care of to avoid those. No tricks needed.
Hollow :P |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quote:you can switch pointers for 6 sprites easily on a non badline
Not if they move vertically. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
/me wrote a sprite multiplexer the last two days :) |
| |
ready.
Registered: Feb 2003
Posts: 441 |
Yeah, I remeber having the bad line problem while coding Aurora (2D plot part). For sprite multiplexing I used the $d018 trick, but I had to be careful not to switch $d018 during a bad line. To fix that I moved the screen downwards a few pixels. |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Quote: Actually this doesn't have to take that much more memory, at least not double up. E.g. if you just need a flexibility of say 3 lines to change the sprite pointer, you only need to waste about 3 lines of gfx for each 18 lines, i.e. use 1/6th more memory.
Here's how I would do it... The first sprite is displayed normally on line 1-18. Then you need to change the pointer on line 19, 20 or 21. For these lines the new sprite image should double the line 19+20+21 of the old one. Then the new sprite image is displayed normally for its line 1-15, and after that the pointer needs to be changed on line 16/17/18. For these lines the new sprite image again has to double the gfx, and after this the displaying continues normally for line 19,20,21, and then cycles to 1,2,3...12. And so on, until the final sprite, which needs to end with 3 empty lines, where you have time to switch to an empty sprite image.
Ah excellent idea this one. I am trying to multiplex all 8 sprites tightly under each other to create a 192x126 image and soon realised that there simply isnt enough time to change all those pointers on one scanline before it reaches the start of the new set of relocated sprites.
There should be more than enough time to do the swap (to a buffer) of those bottom 3 lines of all 8 sprites inbetween.
- Copying the real data of the next set of sprites to a buffer
- Move the bottom of the currently rendering set to the next set and then
- When the next set has started drawing, copy the buffer data back to the bottom of these sprites
A very smart algorithm indeed and would solve my hi-res sprite overlay challenge. |
