| |
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? |
|
... 15 posts hidden. Click here to view all posts....
|
| |
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. |
| Previous - 1 | 2 | 3 - Next |
