| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
short sprites
Just checking - there's no way to have a sprite that's less than 21 lines high, right?
I need a four pixel high sprite every 36 lines for an effect, and would rather avoid wasting DMA time in the intervening 32 if at all possible, but I suspect it's not. |
|
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
It is possible to reduce a sprite's height a bit with spritecrunching, the minimum possible height being 17 pixels, but this requires 2 register writes each in 4 lines, and one out of each 2 writes requires cycle-exact timing. It might nor might not be worth it (16 to 19 cycles saved in 4 rows vs. 2 register writes each in 4 rows + overhead due to precise timing and because you need to load a a register with the value to write first or use INC/DEC). |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Just the information I needed @Kabuto, thank you!
I'll be running a precisely timed routine, and can contrive to have two values available at no extra cost to the routine (as long as the low four bits differ), so I could probably save cycles overall. However, I suspect the additional code complexity would not be worth it if all the saved cycles are in a single 4 line high region.
note to self: get to know spritecrunch. |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
Also have a look at Krestage, might save you some time. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
i have to ask coz i dotn know:
is the DROPZONE (game), "animation" a type of spritecrunch, or how did Archer Mclean do this ?
(DROPZONE logo comes down from top of screen, and expands fluently like hires, to become a bit higher, about 40% ?)
made in 1985 and very impressive still, not seen that since. |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
Didn't inspect the code of Dropzone. But judging from the appearance of the effect it's well possible without any special tricks at all, there's more than enough raster time available for rendering that logo into a charset-based buffer every frame. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11101 |
if i recall correctly, dropzone doesnt use sprites at all, similar to choplifter. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Another quick sanity check. From http://www.antimon.org/dl/c64/code/streech.txt :
Quoting Pasi OjalaSomething very weird happens when we clear the expansion bit right when VIC is adding three to the sprite image counters. The values in the counters will be increased only by two, and the data is then read from the wrong place.
Is that a different effect, or is it just plain wrong? There don't appear to be any counter values that increase by two in the table given on codebase (or by the (0b101010 & (mcbase & mc)) | (0b010101 & (mcbase | mc)) formula I found elsewhere).
Something of a moot point I know, as an exhaustive state transition search still yields a minimum sprite height of 17, even if there is a way to increment by two. |
| |
lft
Registered: Jul 2007
Posts: 369 |
That is wrong.
There's an obsolete explanation for the "magic sprite stretch" behaviour, i.e. a sprite crunch on the very first line of the sprite. This explanation says that the counter is incremented in two stages (first by 1, then by 2), and we can stop it in between the two stages. This explanation is incorrect.
The text you quoted then gets the incorrect explanation wrong by flipping the order of the alleged increments. It goes on:
Quote:$3f is not reached after 21 lines and VIC will go on counting
and will display the sprite again, now normally. If we fool the counter only
once, the counter value $3f is reached when the sprite is displayed twice.
But this description is consistent with an increment by 1, not 2 as claimed. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Ah well. In Pasi's defense, the article is mostly focussed on stretching rather than crunching
Thank you, in any case. |
