Nyan Cat Animation on Propeller! (done)
potatohead
Posts: 10,261
This project archive includes the Nyan Cat top level program, a basic 8 bit per pixel graphics library, and a slightly modified 8 bit per pixel driver, authored by Eric Ball. I really like this driver! Color generation is done via software wave generation, synced perfectly to the pixels, allowing stable artifact color on NTSC.
You can see some of his other excellent driver work here: http://forums.parallax.com/entry.php?104-Links-to-Propeller-stuff-I-ve-done Be sure and send him a note, if you use the driver cores he's produced. We've got a lot of interesting color methods and signal options because of that. (thank you)
Right now, the graphics library includes the core things needed to make use of the screen. Pixel plot, fill area, clear screen, bitplot (move image from RAM to screen with transparency)
The graphics animation and library are being ported to C. I'm actually very interested in how things will perform. There are a fair number of VGA 8 bpp graphics functions out there. These could prove very useful in C, depending.
I've a line function in Spin that is in the process of being ported to PASM.
All graphics functions are RAW with no clipping, etc... You need to bounds check, clip, etc...
A single display buffer is used. Was doing some graphics on my Color Computer 3, which also has a nice artifact color 8 bit per pixel mode, not unlike what this driver produces, and it has only bitmap graphics. The same techniques apply here on the Propeller, but with a lot more speed! The TV COG sends blanking signals to other COGs so synchronized screen drawing can occur. 0 = bottom of screen, in blanking period. The screen isn't visible at this time. 1 = start of active graphics odd frame, 2 = start of active graphics even frame. Video output is interlaced NTSC, composite.
The main loop waits for the bottom of screen blanking signal, then rapidly clears the display buffer, followed by the current state of the animation. This animation consumes about 70 percent of the draw capability at 80Mhz.
[video=youtube_share;0yLOoOhG1LI]
Enjoy! Any and all comments welcome.
Display issue reported, and fixed. Release version with Ahle2 Retronitus sound attached to this post.
It's not hard to adjust the cat speed now. Modify to suit your taste. (in main).
Fill color black. Report any display failures to doug@opengeek.org, or here! To change this:
(in main)
(in drawstars)
***Alas, I have no sound capture capability at the moment. If you want to hear it, run it! (and you should run it, because the sound is cool)
You can hear it here!!
You can see some of his other excellent driver work here: http://forums.parallax.com/entry.php?104-Links-to-Propeller-stuff-I-ve-done Be sure and send him a note, if you use the driver cores he's produced. We've got a lot of interesting color methods and signal options because of that. (thank you)
Right now, the graphics library includes the core things needed to make use of the screen. Pixel plot, fill area, clear screen, bitplot (move image from RAM to screen with transparency)
The graphics animation and library are being ported to C. I'm actually very interested in how things will perform. There are a fair number of VGA 8 bpp graphics functions out there. These could prove very useful in C, depending.
I've a line function in Spin that is in the process of being ported to PASM.
All graphics functions are RAW with no clipping, etc... You need to bounds check, clip, etc...
A single display buffer is used. Was doing some graphics on my Color Computer 3, which also has a nice artifact color 8 bit per pixel mode, not unlike what this driver produces, and it has only bitmap graphics. The same techniques apply here on the Propeller, but with a lot more speed! The TV COG sends blanking signals to other COGs so synchronized screen drawing can occur. 0 = bottom of screen, in blanking period. The screen isn't visible at this time. 1 = start of active graphics odd frame, 2 = start of active graphics even frame. Video output is interlaced NTSC, composite.
The main loop waits for the bottom of screen blanking signal, then rapidly clears the display buffer, followed by the current state of the animation. This animation consumes about 70 percent of the draw capability at 80Mhz.
[video=youtube_share;0yLOoOhG1LI]
Enjoy! Any and all comments welcome.
Display issue reported, and fixed. Release version with Ahle2 Retronitus sound attached to this post.
It's not hard to adjust the cat speed now. Modify to suit your taste. (in main).
k++ 'update the animation key variable if k == 5 'Adjust your Nyan Speed Here!!! (was 4) k := 0 anim ++
Fill color black. Report any display failures to doug@opengeek.org, or here! To change this:
(in main)
repeat 'Clear screen right at the start of blanking! 'We are at bottom of frame, invisible screen blanking time 'Clear graphics screen to black --Some color fringing may appear on high contrast 'color borders. Use grey or lower contrast changes to marginalize this. clear($00000000) <--modify to suit
(in drawstars)
'Mask off extra graphics fill(41, 18, $00, 86, 2) fill(41, 20, $00, 3, 58) fill(117, 19, $00, 10, 59) <--- change $00
***Alas, I have no sound capture capability at the moment. If you want to hear it, run it! (and you should run it, because the sound is cool)
You can hear it here!!
Comments
Just FYI, picking this one apart was actually educational. The entire animation is based on a single counter. There are some great classic animation techniques used in this thing! The star - field actually is just 6 shapes, placed on the screen in static positions, then "lit" up sequentially to give the illusion of both forward motion, and the stars being more complex than they are. 12 frames of animation are all that is needed to capture everything, with most of it being simple one or two pixel moves that contrast with the stars to convey a lot more motion than is really there. I've included the frames I captured in the assets package, in case you are curious...
-Phil
This basically is a reference for some C work to come. I've got some VGA 8bpp graphics code identified and am eager to put it through the Propeller compilers. Wanted a SPIN + PASM reference / benchmark. And it's goofy fun.
Of course, I'm a sucker for goofy little animations. NyanCat is actually a fun one! And it's been ported all over the place too. Seems the thing to do is put it on classic computers. Was thinking about the CoCo3, which doesn't have it yet... Most other machines do. Can't leave the Prop out, particularly since we have at least one FAN.
Atari 800 port: https://www.youtube.com/watch?v=I3-tAB7b2c0 (not bad actually)
C= Plus 4 port: https://www.youtube.com/watch?v=Yphs-Vhye_g (better sound, IMHO)
C64 port: https://www.youtube.com/watch?v=pTevgtyYbpc (weak)
BBC Micro: https://www.youtube.com/watch?feature=player_embedded&v=HBVQdx3dJ1c#! (ugh)
Spectrum ZX: https://www.youtube.com/watch?v=ZYibyWpK10o&feature=related
NES: https://www.youtube.com/watch?v=j5mCvOAU7gA&feature=related (embellished!)
VCS (2600): https://www.youtube.com/watch?v=tQ4S6NgT0s8 (not bad for 4K ROM + 128 bytes of ram and no screen buffrer)
I'm currently kicking around the idea of writing a simple SID tracker... Really, only two sound channels are needed to do the tune, and surprisingly, plenty of people have transcribed it, so I have a score to work from. Maybe do both, as I've not played WAV files from SD yet. Would like it to run on the chip from RAM though. Options, options... Thanks for the suggestion, I'll check it out!
PlayWav_8bit.spin
I haven't changed the file name in the spin file, so you will need to copy the Nyan loop into your Propeller library and change the file name in the DAT section of the Propeller program.
Here's 6 seconds of the annoying Nyan loop to test it with: http://microcontrolled.com/Nyan.wav
Hope this helps,
Microcontrolled
I've found a little MIDI file (4kB) on the Net, this fits well in the Propeller RAM.
Normally this MIDI file plays only 2 Piano Tracks, but I have tweaked the MIDI player to use other sounds, even random sounds on every loop.
The whole object including the MIDI is under 10k Byte.
Andy
Andy, that's a nice MIDI player / Synth!
Features:
* Runs in one cog
* Small (a total of 2.8kB for both sound engine plus music data )
* High sample rate (68 kHz)
* Easy to include and use
@All downloaders
This version of Retronitus is NOT meant to be spread.
In fact I didn't want to release any source code until it was completely finished; But for the good cause I changed my mind.
NyanCat-Retronitus.zip
(and it is a good cause too --Nyan Cat everywhere!)
Can't wait to try the sound options out.
(@potatohead The cat runs a tiny bit too fast!!)
wip_nyan - Archive [Date 2011.11.29 Time 21.16].zip
/Johannes
Maybe I'll drop a frame every so often and fix it.
Edit: Was my first one. Appreciate you integrating the sound. I'll be able to have a play with it later today.
A 25 year old "gif animator", Christopher Torres from Texas, was bored. When he asked some friends in a live video chat what he should animate next, he got two different answers, cat and pop-tart.
So he did just that, a animated pop-tart cat. He uploaded it to his website on April 2, 2011.
On July 25, 2010, a user called "daniwell" uploaded a tune he had made to the japanese video sharing site called "Nico Nico Douga".
The tune was called "nyanyanyan....." and became quite popular.
Half a year later(January 31, 2011) a user called "Momo Momo" uploaded a remix of the tune to the same video sharing site. "Momo Momo" just added some extra vocals.
Then on April 5, 2011 "saraj00n" combined Momo Momo's version of the tune with Christopher's gif animation and the rest is history.
Fun story: one day I walked into Bump's office to ask him about some capabilities of the Drupal back end running Parallax Semiconductor. I heard a strangely familiar tune playing in the background...it took me a while to place it. When I finally realized that it was the Nyan Cat theme, I asked him about it. He had some flash app loaded and looping in the background that was playing the song and animating the rainbow-cat-poptart-thing that recorded "how long you have been Nyan-ing". At that point, I think it had been playing straight for something like 2 hours...lol.
How about making a nyan cat game?
/Johannes
What would the game be? Avoid the Xmos / Pic / Avr / etc... chips, and get the Props for points?
But with microcontrollers?!
-Phil
I feel that the gray background i see in the code was maybe a hack to get a video capture card to not mess up?
For me right now the pixel lines of the top of the "tart" and the paws of the cat is where there is no horizontal stability.
I can remember seeing the same sort of "bowing to the right" of the lines in the wolfenstein raycast demo and on the title screen for the block moving game "unterwelt?" in its name (man I miss all of the old posts).
This is a postmodern CRT television, one of the few good TV's APEX ever stamped their name on. I like using this TV as a benchmark, because it still uses a lot of analog processing and it does like to follow the NTSC standard with little margin for bad timing.
-Phil
In fact, if I highlight the code between the label "catsize" (line 253) and the comment "'Starfield animation data, position 12 off screen" (line 467)
and then select Edit->Find/Replace, and replace all within that range of $00 with $11, it works fine.
To me, I think the long horizontal lines of $00 make it seem to the TV that it is a sync pulse?
On high color contrasts, this driver can create "ghost" colors, and the grey minimized the impact of that. This code was developed on an 80's era TV. Normally I use a capture, and would probably have seen this. I did one capture session after solidifying the display. My good card won't typically break down on that, (ADS HDTV USB) but the "EZ CAPTURE" one absolutely will. (I think it's a lot like your TV)
In the end, I liked the grey, so that's why it's there.
That said, I've not really tested all aspects of this driver. It uses some techniques new to me, and I ran it largely as is. Looks like a test 'n tweak cycle is warranted.
No worries here. Glad you mentioned it.
I like it because it generates it's own color burst that is always in phase with the pixels, making the artifact colors seen possible. I suspect the 4 color pixels in the active display include a sync, not black level. Probably an easy change.
"catsize" has two bytes that detail the x and y size of the image data to follow in pixels.
The function "bitplot" will read those two bytes, then draw all the pixels to follow according to those sizes, at a given screen buffer position, and will not draw one designated color in particular, so that other objects can be seen through.
The $00 in the image data is simply mapped to one of the four active display colors. The remaining color values do not map to the usual Propeller colors, because the means of color generation does not use the internal color phase generator. That also means the horizontal pixel size of this particular driver is fixed at the resolution seen here, just FYI.
I'll correct the one with the sound integrated, set for a black background, just to be sure, and put it up here in a few minutes! And that did cut down on the fringing I was seeing too. Still there, but at levels I think are just how this method of color is.
So it's two fixes in one. Nice catch Whicker! Appreciated.
To be perfectly clear, with this edit, the value $00 is acceptable, and will be black. $FF will be white. All 8 bits are valid color specifications.
The grey values are:
$00, $11, $44, $55, $22, $88, $99, $66, $cc, $33, $dd, $aa, $77, $ee, $bb, $ff
About six shades are possible, each with some position / color fringing trade-offs.
All changes done, see top post!
I didn't quite know how it was generating color, so I made a wild guess.
Simple stuff like this is what makes the propeller so fun.
Too fun, isn't it?