| |
Cybernator
Registered: Jun 2002
Posts: 154 |
16 rasterlines tall sprites
I need to multiplex 4 sprite rows. However, the sprites I use should be 16 rasterlines tall (instead of 21). If I move the sprite 16 pixels down after the first line has been displayed, will the next sprite be displayed from its 1st rasterline?
I mean because MCBASE is incremented by 3 after each rasterline, will it reset when the second sprite starts?
Quote from the VIC article:
"In the first phases of cycle 55 and 56, the VIC checks for every single sprite if the corresponding MxE bit in register $D015 is set and the Y coordinate of the sprite match the lower 8 bits of RASTER. If this is the case and the _DMA for the sprite is still off_, the DMA is switched on, MCBASE is cleared..."
Well, seems that if the Y coord. of the sprite matches the raster, MCBASE is cleared, BUT only if the DMA is STILL off.
Does this mean that if it's on, MCBASE contiunes counting from where it stopped? If so, I got a problem here. ;-P |
|
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
If sprite 0 is on line $50, you can't set it to $60 and expect it to be displayed there. It just won't show up. You can't start displaying a sprite again until it's finished. This is very basic knowledge, and you could easily have found out yourself by trying it.
There's a trick to shrink sprites vertically though, called sprite crunching. Check out Krestage by Crest if you absolutely want to do this.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
if you change the Y position of a sprite while it's displayed nothing will happen to the sprite itself. it will still be 21 pixels high. the multiplexed sprite at the new Y position will only be displayed when the Y position is higher than old Y+20 because a sprite will only be started to display if it isnt being displayed currently. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Puterman wrote:
> This is very basic knowledge,
> and you could easily have found
> out yourself by trying it.
In fact, I have noticed it when my knowledge about the internal functions of the VIC was practically zero. I was thinking if there's any way to reset MCBASE, so that the sprite could be displayed correctly. (something like reseting RC as in FPP). Obviously, there isn't.
Ah yes, whenever I post about VIC stuff, I end up with conversation about various of its features, not just the thing I have asked at first. :-D
I have never thought about how sprite-crunch works. IIRC, the sprites were 17 rasterlines tall in Krestage. Can this be used for 16? :)
|
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
What I'd really like to know is why you absolutely need sprites that are 16 lines...
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
If it's some sort of bitmap drawing or dual-layer thing, I'd recommend switching roles of chars & sprites, if possible.. |
| |
CreaMD
Registered: Dec 2001
Posts: 3057 |
I'm not 100% sure but I think all that crunching/read reseting stuff must have something to do with gfx-bank switching. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Puterman wrote:
> What I'd really like to know is
> why you absolutely need sprites
> that are 16 lines...
Cadaver wrote:
> If it's some sort of bitmap drawing
> or dual-layer thing, I'd recommend
> switching roles of chars & sprites,
> if possible..
I don't _absolutely_ need this. An effect crossed my mind (rather poor one :)), where 16 rasterlines tall sprites would make it easier to code. Imagine squares which scale down (ie. become smaller), and as they do that, they uncover the background behing them. These squares are 16 rasterlines tall and 16 pixels wide (so that they can cover 2x2 chars). I wanted to use 8 sprites per row. So it would be nice if MCBASE could be reseted. The effect can also be achieved by covering the whole area with sprites, and writing into the sprites directly, instead of modifying the sprite pointer. Or by using 4 sprites per row (a cheap trick :)).
That doesn't matter now, since the project is canceled. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Sprite crunching is a pretty kewl effect, but pretty hard to master too I think. I remember discovering myself that you could fuck up the updating of the sprite gfx by changing $D017 randomly, but I didn't think it could be used for anything useful. Like lots of other VIC bugs it would probably never had been fully tamed if it hadn't been for the VIC-bug master himself, Crossbow/Crest.
For an effect with some blocks that reveal some gfx, I would suggest multiplexing the sprites at each 21st rasterline, and then having some different instances of the block animation that starts on different lines in the sprite, if you know what I mean... |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Cruzer wrote:
> and then having some different
> instances of the block animation
> that starts on different lines in
> the sprite, if you know what I mean...
Yes, that's even better way to do it. Did I say it was canceled? There was misunderstanding with some dudez, but it's not canceled after all. ;-)))
However, I've used another 3D-ish effect as the purpose has changed. |
