Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > NUFLI Sprite Layer
2011-04-14 09:30
Sabbi

Registered: Jan 2002
Posts: 8
NUFLI Sprite Layer

Hi everybody,

I'm trying to understand what's going on with the sprite layer on NUFLI-Pictures or more precise the NUFLI-Viewer, and something I just don't get.

It's about Y-Position and Y-Expand:

Acording to the Vice-Monitor, Sprite Y-Positions are only written at Raster 43, 45 and 248, while $d017 (Y-Expand) is written at Raster 45 and 46.

So, with no new Y-Positions between 45 and 248, and no $d017-stretcher, how can there be sprites upto 248?

I know I (obviously) oversee something, but I cannot find the missing piece.

Thank a lot for any directions :)

Sabbi

(btw: Observed on 25 Years of Yie Ar Kung-Fu)
2011-04-14 09:38
WVL

Registered: Mar 2002
Posts: 902
Just google for 'magic sprite stretch'. Using two d017 writes, you can stretch sprites by a factor 3 (and even factor 6 if you use y-expansion).

It works by creating a misalignment between the bytes the VIC reads. Normally, a sprite is ended when $3f gets read (this would be the first byte on the next row of the sprite), but when reading that byte from $3f, the vic stops displaying the sprite.

If you let the VIC read the bytes at on offset, then $3f does not get read the first time, and also not the second time. thus the sprites 'stretches'.

Also take a look at the table that crossbow showed in Krestology (I think?). about how sprite-crunching works
2011-04-14 11:35
HCL

Registered: Feb 2003
Posts: 728
It's in here: Krestage.

You just need one write to $d017 at exactly the right cycle to trigger this weird stuff. Has been used to both enlarge and shrink y-size of sprites. Has been used in several BoozeDesign demos also, just with less benefit :P.
2011-04-14 12:03
Sabbi

Registered: Jan 2002
Posts: 8
Ahhh, now I get it - I forgot about the possibilites of MCBASE+2/+1, just had the +3 for "normal" stretchers in mind..

From the VIC-Text:
7. In the first phase of cycle 15, it is checked if the expansion flip flop is set. If so, MCBASE is incremented by 2.

8. In the first phase of cycle 16, it is checked if the expansion flip flop is set. If so, MCBASE is incremented by 1.

So if I understand this correctly, the viewer just takes care that 7. does happen, but 8. doesn't, then it takes 2 complete "sprite-displays" to get the MC/MCBASE right again.

This explains a lot :) Thanks Guys!


2011-04-15 10:42
Cruzer

Registered: Dec 2001
Posts: 1048
"Magic sprite stretch", there's a trick I wasn't aware of. Cool!
2011-04-15 14:24
WVL

Registered: Mar 2002
Posts: 902
Quote: "Magic sprite stretch", there's a trick I wasn't aware of. Cool!


Dunno what other people call it, but i think this should be the only correct name ;)
2011-04-15 15:25
Cruzer

Registered: Dec 2001
Posts: 1048
WVL: Wasn't poking fun of your name. I have never called it anything - maybe "sprite fuckup" when I discovered that you could fuck up the gfx updating by changing d017. But I never knew it was possible to use this for stretching them 6 times, which can be quite useful.
2011-04-15 17:40
Oswald

Registered: Apr 2002
Posts: 5094
the "official" name is spritecrunch :) afaik because it was first used to reduce the size of sprites. check xbow's multiplexer record :)
2011-04-16 20:46
Digger

Registered: Mar 2005
Posts: 437
I know the unlimited $d017 stretch trick when you can stretch any given sprite line as long as you keep setting & reseting that sprite bit ($d017), then you can switch screen sprite pointers to set any sprite line. Is this the same what "magic sprite stretch" does?

Ah sorry, just understood it's not!
2011-04-17 10:15
WVL

Registered: Mar 2002
Posts: 902
No, it's not. With 'magic sprite stretch' you can stretch sprites up to 6 times with just one (or two) $d017 writes. If they're on top of FLI on y-expansion is on, then you get 6*21 = 126 different lines, because of $d018 switching that your FLI routine does.

F.e, check out Crossbow's 5 sprites over FLI in Demus Interruptus and measure how high his FLI picture is ;) -> no multiplexing needed with magic sprite stretch.

Actually, what you can do is this :

at line X, you start your sprites, and perform the magic sprite stretch. Then at line X+1, you set new sprite y-co's (multiplexing!) and at line X+2 your effect begins. That way you can even have 8*21-2 lines of sprite for your effect, without having to bother with multiplexing or something else.. really nice :) And now I think of it, I think this is what crossbow does in Demus Interruptus.. so expect around 168 lines of FLI in there.
2011-04-17 10:52
tlr

Registered: Sep 2003
Posts: 1790
There are some additions/corrections to the VIC-Article regarding sprite crunch here:
http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/trunk/vice/..
(see "sprite crunch")

That text also explains the logic behind the table.
2011-04-20 08:38
Sabbi

Registered: Jan 2002
Posts: 8
Thanks :) Now it's all clear about the magic!

But while we're at the VIC-II Text....

3. In the first phases of cycle 55 and 56, the VIC checks for every 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.

4. In the first phase of cycle 58, it is checked if the DMA for the sprite is turned on and the Y coordinate of the sprite matches the lower 8 bits of RASTER. If this is the case, the display of the sprite is turned on.

The Vic checks TWICE if the Y-Coordinate is same as the raster? So if you change SpriteY on cycle 57, the DMA is on, but the sprite will not be visible?
2011-04-20 10:27
tlr

Registered: Sep 2003
Posts: 1790
Yes.

See here: http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/testprogs/V..
(spriteenable[1-5].prg)

The source is in core[1-5].asm.
2011-04-20 11:47
Sabbi

Registered: Jan 2002
Posts: 8
Intresting... Inactive Sprites eating Cycles :)
2011-05-04 23:13
Digger

Registered: Mar 2005
Posts: 437
OK, so 1 extended layer of sprites (42px high) + 3 times wrapped extended sprites (3 *42 = 126px) gives 168 pixels. The NUFLI pic is 200 px high. What about the remaining 32 lines? If the "sprite crunch" trick is only performed once (@ lines 45 and 46) how can this work?

Anyone wants to play with the source, here's what I've got so far...
https://gist.github.com/956683
2011-05-05 08:41
Sabbi

Registered: Jan 2002
Posts: 8
Digger: Not checked, but afaik the sprites are multiplexed once.

At raster 43 is the first Y-Position for the 168 stretched-sprites is set, at raster 45 already the next position (Y + 168) is set to have 42 extra-lines of normal expanded sprites.

RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mike
MWR/Visdom
Mibri/ATL^MSL^PRX
Peacemaker/CENSOR/Hi..
WVL/Xenon
deetsay
icon/The Silents, Sp..
csabanw
Guests online: 120
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.045 sec.