Nyancat Preview (STOS)

[mlynn1974]

I have converted Nyancat to the ST using STOS BASIC.
The preview version at the moment requires 1Mb. I will try to make it more memory efficient if I put it in a STOS Demo Compilation.

YouTube:
https://www.youtube.com/watch?v=X7x_d2AKpnk

Download .ST disk image (zipped):
https://www.lynn3686.com/download/st/ny ... review.zip

This probably doesn't work on TOS 2.06 - sorry.

[chronicthehedgehog]

[guythp]

Nice one! I've yet to start learning STOS (got the manual, lack the motivation) but why doesn't it fit in 512Mb? is the screen an animation?

[mlynn1974]

Hi! Yes it is an animation.

Nyan Cat has 10 frames of animation but frame 2 is the same as frame 3, so that's 9 frames. A half-meg ST has about 370k free when TOS is loaded and each screen is 32k: (32*9)k + 64k (logic + physic) + 60k executable + 30k music + 2k for stack I think = 380k!
So it needs 1Mb minimum to run.

The music player has to play in a loop every frame because it's written in STOS too (1% CPU time when compiled).
The screen is copied with the skopy 4 command 50 scanlines each frame so it updates every 4 frames. I am sure with tile mapping it could be decompressed and copied very quickly. Much faster than the unpack command.

[thomas3]

Hi Michael,

Couldn't you just change the physic screen pointer every four vbls to cycle through the screens, rather than copying to logic? That way, you could STOS's 64kb screenbase for two of your screens, meaning you only need a further 7 in another buffer.

Just a thought

[simonsunnyboy]

The latter should work well, align the frames properly in memory for STF use.

BTW TOS 1.0 from AUTO should have ~400K free and you can reuse the screen memory from TOS.

[evil]

I think (without having tested) that with this low framerate you could realtime depack the graphics with lz77 or possibly cranker. If the animation is "clean" from stray pixels it will likely pack very, very well using just a small bit of the 520's RAM.

And oh, the Spice guys were on this a while ago too:
https://www.youtube.com/watch?v=p77_PCxt-2w

[mlynn1974]

>Couldn't you just change the physic screen pointer every four vbls to cycle through the screens, rather than copying to logic?
I could but I wanted to add a scroller to the bottom at some point so I didn't want to change the other screens as I guess it would have to be double buffered to prevent tearing. I might give it a try.

I don't think that would save memory though as default logic and physic will still be reserved by STOS.

Each frame actually has a slightly different palette order due to the way I separated the frames from the animated GIF. I have to do a get palette (SCR) on each frame.

>I think (without having tested) that with this low framerate you could realtime depack the graphics with lz77 or possibly cranker.
I thought that too but it adds a lot more complexity to the code.

>And oh, the Spice guys were on this a while ago too:
I've never seen the Spice guys demo before but it looks good!

[thomas3]

I don't think that would save memory though as default logic and physic will still be reserved by STOS.

That's ok. You could set up a 9 element array for each screen address. Let's say you have a work buffer of 7x32k in bank 5 - you could then so this:

Sc(0)=default physic
Sc(1)=default back
S=start(5)
For I=0 to 6:sc(I+2)=s:s=s+32000:next I

You can then copy each frame to each element of sc, and cycle through them.

If your scroller is at the bottom of the screen you should have plenty of time to redraw it each vbl before the beam hits the scrolltext, as the animation itself will now take virtually no CPU.

[mrdalliard]

This is wonderful, thanks for sharing it!

[mlynn1974]

OK so the colours were different between frames because I had split the original gif in to separate BMPs and when I loaded it in to Grafx2 I think it remaps them in a histogram with the most frequent colours first. That is slightly different for every frame. To fix this I saved all 9 frames adjacent as a 16 colour IFF (LBM) and then cut and pasted each frame in to separate screen in Grafx2 and then saved each one as a PI1 and the palette was the same for each.

I then wrote a program in C# to split each frame into 16x8 tiles (4 bitplanes). Remarkably there are only 714 unique 16x8 tiles (64 bytes) across 9 frames taking 45696 bytes. The tile display list is 500*9*2=9000 bytes.

My assembly tile displayer is OK if rather simple. It takes 1.5 frames to display 500 16x8 tiles.
Interestingly it saves 25% CPU time by unrolling the loop rather than a tight DBF loop like this:

Code: Select all

copyloop:
; copy tile from a2 to screen a3
; bp0/bp1
	move.l	(a2)+,(a3)+
; bp2/bp3
	move.l	(a2)+,(a3)+
	add.l	d5,a3
	dbf	d2,copyloop

I'll convert this to STOS and hopefully be able to add a scroller and music and get it running on a half-meg!