Animation playback on the TI-99/4A

[Tursi]

Reposting my bit from the 512k cart thread, which will hopefully get the other posts moved here.

 

oh well. C'est la vie! Here's my take on it, 2MB cart, though.

 

 

I see yours is full screen and still looks pretty decent.. I went with 1/2 screen, but I do a full 4 rows before flipping between color and pattern. (So 96 characters). This version runs in scratchpad, but I have a larger version that runs from CPU memory and it doesn't make much of an impact (compared to the data transfer, comparably little time is spent reading program data). My eventual goal is hardware that reads from SD and streams the data with autoincrement so the CPU doesn't need to do it.

 

This was tested for me by Karsul and he confirms it works on hardware! It will also work on Classic99 but the released version doesn't have the DAC emulation working so you won't hear anything.

 

 

vbcarttest8.zip

[Tursi]

One comment I wanted to make, Rasmus, /as I was posting/ I was thinking to myself "I'm glad it's finally ready to go, I'm sure Rasmus was going to do this any day now". That's why the 'arg!' when I saw you'd beat me by just a few hours.

 

To jumpstart a couple of questions that I was asked, I actually downloaded the source to the Genesis Bad Apple video a while ago, and was looking at it. It'd be easier to do brute force now starting from the original video. As for better frame rate, that depends.

 

I selected 1/2 a frame based on how we'd already seen that mono-only updates could be done at a reasonable rate - that's 6144 bytes. My half frame is also 6144 bytes, just there's both pixel and color in there. So if you went mono-only but full screen, it'd be about the same frame rate, or mono-only at the same resolution could nearly double the frame rate.

 

BUT... Bad Apple isn't mono - it's grey scale. Moving so quick it probably wouldn't matter, but the edges do help. On the other hand, TI bitmap mode can't do the anti-aliasing in 99% of the cases anyway, so it might as well be mono. Heh.

 

Yeah, I guess we could do it now. If we were feeling ambitious, we could even try to compress it (but that will hurt frame rate too). Tempting. I always liked that demo.

[sometimes99er]

I took some Lucky Luke animation from, I think, the Game Boy Advance.

 

Made the graphics monochrome - or created a silhouette effect (turning everything black but the background).

 

 

I knew I wanted to do the animation with 1 character-set and 8 full-screens. - There's room for more character-sets for even more breathtaking animations, all held in the VDP space.

 

I selected 8 frames that would still make a nice and fluid animation. Using every character in the set (256).

 

 

Put up the screens so that the 8 frames of animation were distributed more or less evenly. Here's the final animation.

 

 

The attached cartridge has the animation speeding up and down (frames per second). Effective size about 3.800 bytes.

 

Oh, the CPU just changes from one screen to the next, so the CPU is just waiting 99% of the time.

 

Edited February 3, 2015 by sometimes99er

[+acadiel]

I wonder how well it'll work with very high FPS action scenes.... kind of curious how something like this would look (4m7s onward is a good idea of what I'm referring to):

 

https://www.youtube.com/watch?v=RDJJbz7Ea_c&feature=youtu.be&t=4m7s

[TheMole]

BUT... Bad Apple isn't mono - it's grey scale. Moving so quick it probably wouldn't matter, but the edges do help. On the other hand, TI bitmap mode can't do the anti-aliasing in 99% of the cases anyway, so it might as well be mono. Heh.

 

Yeah, I guess we could do it now. If we were feeling ambitious, we could even try to compress it (but that will hurt frame rate too). Tempting. I always liked that demo.

 

Oh yeah, I know the source is grayscale. But it probably wouldn't suffer much when reduced to pure monochrome. I just love the fact that it's sort of a Homebrew staple when it comes to FMV on retro consoles and it'd be neat to see how the TI stacks up against other systems . The fact that you've managed to do 4-bit PCM at the same time is pretty neat and I haven't seen this on other early era systems, where they typically choose to use a PSG rendition instead!

 

As far as compression is concerned, there'd probably not a lot of room for complex algorithms if we want to keep a nice framerate (the higher the better, and if dropping color means we could double it to 16 fps, that'd be most impressive). I think a simple RLE scheme could work quite well with a true monochrome/shadow art source like Bad Apple, or perhaps something vector quantization based ala cinepak to generate a codebook. That last one would probably need an entirely different rendering method though (updating the nametable every frame, while streaming smaller updates to the pattern table).

[Asmusr]

The compression I have thought about implementing is simply to store the parts of the screen that are updated only (start address, length, bytes), where length should be higher than a reasonable threshold (around 6 bytes). For the sample animation I have used it would reduce the number of bytes to read by 40% and the number of bytes to write by 50%.

[Tursi]

Yeah, that's called "dirty rectangle" and it can work pretty well! It's pretty easy to determine whether it is better to split two changes or condense them - changing the VDP address takes two writes. So if there is one byte unchanged, it is faster to condense the blocks. Two bytes unchanged, it's equivalent (but probably more efficient to condense them). Three or more bytes unchanged and you might as well change the VDP address.

 

I was thinking about that while watching my conversion tests (I also did three music videos - "Perform This Way" and "White and Nerdy" by Weird Al, "Let It Go" from Frozen, and "Smile Smile Smile" from My Little Pony - a nice cross section of styles. One thing that impressed me was that even with heavy dithering, static areas were VERY consistent frame to frame, making dirty rectangle a real possibility even there.

 

For Bad Apple, RLE would probably work fantastically. Nice thing about RLE is that it's really easy to maintain your cycle counts while unpacking (which is important for good audio playback). Dirty Rectangle would reduce CPU load at the same time (and the two would probably work really nicely on the line animations that Sometimes suggested in the other thread - but I bet you could make those work in character mode ).

[+acadiel]

I was thinking about that while watching my conversion tests (I also did three music videos - "Perform This Way" and "White and Nerdy" by Weird Al, "Let It Go" from Frozen, and "Smile Smile Smile" from My Little Pony - a nice cross section of styles. One thing that impressed me was that even with heavy dithering, static areas were VERY consistent frame to frame, making dirty rectangle a real possibility even there.

 

 

That's why I put anime (Sword Art Online battle) up there... heh... there's a lot of action up there after that time stamp and I'm curious how well it looks. When they do anime battles, they go all out with the action.

 

Betcha my girls would be excited to see the MLP one!

[sometimes99er]

Just a bit of fun. You'll need Flash Player and a webcam. Size less than 16 KB.

 

[media=544,416]http://sometimes.planet-99.net/pic/video.ti994a.swf[/media]

[TheMole]

Cool, what is the last mode supposed to emulate? True 16 color bitmap mode with 9918a palette?

[sometimes99er]

Cool, what is the last mode supposed to emulate? True 16 color bitmap mode with 9918a palette?

Thanks. Yep. Bitmap, dithered, with no color limit per 8 pixel.

 

Tried just removing the colors least used, but that had an awful effect. I might try again as I think there's a built-in histogram function. Dithering within the 8 pixels would perhaps also work.

[Tursi]

This post will just be a bit of a dump, I guess we can't get those other posts moved into this thread?

 

Acadiel, I can't get your video to download here... files larger than a couple tens of k are seriously an overnight exercise, and sometimes don't even start.

 

Anyway, I did upload my test videos - they run from Classic99 but are far larger than 2MB. They also /all/ have problems - don't watch if out-of-sync a/v or audio pitch problems bother you. They all have both. They are all unlisted to prevent random searches from finding them. (And will probably be tagged as copyrighted audio if they aren't already). I don't mind if any of these are reposted, I just didn't want them coming up in searches due to the obvious issues.

 

White and Nerdy: http://youtu.be/OzRWl9MDqaw

Perform This Way: http://youtu.be/FK-TYq2Rp_c

Smile Smile Smile: http://youtu.be/Exfr2XZ2WFY

Let It Go: http://youtu.be/lxdQ3G6aCrk

 

I did attempt the Bad Apple conversion, but I didn't realize until I was well into it that the version I had was very low-fi - the audio was only 11kHz and badly clipped. This made for a very poor audio on conversion, although I did try to turn it down a bit (but we clip worse, and it was bad to start). The video IS nicely fluid though, so I posted it anyway - monochrome video version:

 

Bad Apple: http://youtu.be/UExHyIQPxfM

 

The conversion process itself is ridiculously manual - I use a combination of Handbrake, VLC and GoldWave. I've gone ahead and posted my tools and notes, but don't expect a simple process.

 

http://harmlesslion.com/software/tivideo

 

 

[+Ksarul]

Perform this way is already blocked. . .I liked the rest of them though. Thanks for putting them up.

[+OLD CS1]

Perform this way is already blocked. . .I liked the rest of them though. Thanks for putting them up.

 

Phuq YouTube. Seriously, this qualifies as Fair Use.

[Tursi]

Global block! First time I have gotten one of those (could affect my standing and send me to Copyright School, apparently....) SME apparently controls that video.

 

Although I marked 'acknowledged' and the status no longer said blocked on my manager page, I wonder if they just needed me to ok the ads...? If not I might as well delete that one (though that doesn't fix my status apparently ). I think it actually might play now - at least, a new Firefox session brought it up.

 

I expected 'Let it Go' to be marked first.

[Omega-TI]

Well, maybe it's okay in your neck of the woods, still no go here... but I think the keyword here may be 'country' if you can view it.

[Asmusr]

The conversion process itself is ridiculously manual - I use a combination of Handbrake, VLC and GoldWave. I've gone ahead and posted my tools and notes, but don't expect a simple process.

 

Whoa, that's a lot of steps you have to go through, but the results are incredible.

[Tursi]

Still blocked, eh? I guess I'm the only one who can see it, which is rather pointless. It was globally blocked, but still said "in your country". I'll delete it.

 

Too bad, it was one of the better synced ones.

[Willsy]

Just watched let it go! Wow! !! How much memory does that occupy? Awesome!

[+acadiel]

We might be able to use ffmpeg instead of VLC.

 

How about something like this... get your 60FPS (I don't know if it's still needed or not), and then do something like this?

 

ffmpeg output... notice I have it outputting a png @ 8.91fps:

ffmpeg -i input.flv -f image2 -vf fps=fps=8.9132 out%d.png

  Duration: 00:05:40.27, start: 0.010000, bitrate: 1984 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 1814 kb/s, 60 fps, 60 tbr, 90k tbn, 120 tbc (defa
ult)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 160 kb/s (default)
    Metadata:
      handler_name    : Stereo
Output #0, image2, to 'out%d.png':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.19.100
    Stream #0:0(und): Video: png, rgb24, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 8.91 fps, 8.91 tbn, 8.91 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc56.21.102 png
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> png (native))
Press [q] to stop, [?] for help
.pnge=  299 fps= 18 q=0.0 size=N/A time=00:00:33.09 bitrate=N/A

Would that work? No having to calculate which frames to skip manually that way.

 

Another cool thing... XNConvert is a free tool that can also do all the conversions for you:

 

* In the case of 720p files, cut off 120 off each side.

* Reduce the pic to 192x128

* Resize canvas size to 256x192 and put in upper left corner

 

I used Goldwave just as you suggested.. worked fine.

 

I ran a DOS batch command... will need to post it. Took a while.

 

Will finish it up later when it's all done.

[Tursi]

Just watched let it go! Wow! !! How much memory does that occupy? Awesome!

It says in the video description

 

(About 14MB, IIRC).

Edited February 8, 2015 by Tursi

[Tursi]

We might be able to use ffmpeg instead of VLC.

How about something like this... get your 60FPS (I don't know if it's still needed or not), and then do something like this?

The 60fps was only selected because VLC screws up if I ask it to output every frame. Upsampling allowed me to skip frames and then get a subset back.... but Handbrake doesn't allow arbitrary frame rates, thus the extra steps. I think even with all that VLC messes up (and is responsible for some of the sync problems), because on the longer runs I don't get the correct number of output frames.

 

I haven't tried ffmpeg for a long time, I didn't know it could export individual frames. As long as it's consistent, yeah. Then you tailor the audio conversion to the number of frames you ended up with, knowing the program will play 1544 samples per frame. In THEORY, it should sync up. I'll see if I still have it handy.

 

Another free image converter that is very good is ImageMagick, it can do anything as well. I use ThumbsPlus cause I've used it for a lot of stuff over the years.

[Tursi]

Yeah.. ffmpeg works a hell of a lot better than VLC for the frame extraction.

[+acadiel]

Yeah.. ffmpeg works a hell of a lot better than VLC for the frame extraction.

Yep, just for kicks and grins, did mine this morning (after it was working through a batch file all night), and got:

 

276 bytes left for the audio.

 

I now have this huge OUTPUT file. What do I do with it to play it?

 

Edit: Zipped the OUTPUT file and stuck it here: https://dl.dropboxusercontent.com/u/19597743/ti-99-4a/OUTPUT.zip

[Tursi]

Yeah, I redid Let It Go, and it looks much better with the audio in sync and the end frames not missing.

 

The packer isn't very user friendly... when it reports the audio bytes left, that was meant to give me a hint whether I had things lining up. There are three possibilities.

 

First is that it reports 0 bytes left, but before that it reports that it ran out of data too early. In this case, your audio stream is shorter than the video stream, and the end of it is going to be screwed up (and possibly out of sync, depending on how early it died).

 

Second case is it reports 0 bytes left, but did not warn. The odds are that you did not actually get exactly the correct number of bytes, more likely it ran out of data during the last frame. This usually has no ill effect.

 

Final case is you have bytes left. As long as that's less than 1544, you can be sure there is less than a single frame of audio omitted, and all is probably well. If it's more, you didn't do your math for the audio conversion right. You can decide how many frames it's off by and whether you care.

 

Now.. how to play.. that's a harder one. The new release of Classic99 has a #define in the source code to enable a dummy device. This dummy device streams a large amount of data through >7FFF, and resets the stream when >6000 is accessed. (I hope to build this device eventually ). It's not enabled by default because it could interfere with cartridges (the byte at >7FFF would be wrong for a normal cart). But rather than forcing everyone to rebuild Classic99, I'll post a hacked version here.

 

The other alternative is if you want to make a cartridge, assuming it will fit. 2MB is our current maximum size, but the naïve bankswitch tech we are using can theoretically go up to 32MB (as there are 12 bits of address available for banking, 4096 pages). Classic99 doesn't support more than 2MB at this time though. Anyway... the cart-based version of the playback routine that I build expects a single frame per 8k page, so there's another tool in the package to reformat the output file into that alignment, which may or may not work well (I did Spaceballs pretty much manually). You could write a smarter playback function, but I was worried about the overhead of checking the page more frequently. That version is also far less careful on the cycle counting, it was just a quick hack. If someone needs to go there we can talk better tools later.

 

Instead, for now, here's a build of Classic99 with the large-device hack enabled - drop into the Classic99 folder and run it from a command line, passing in the filename of that big file you want it to use. You can check in the debug output that it successfully found and loaded it.

 

After that, build, load and run videoblaster.a99 from the distribution package (EA#3, program name MAIN), and your video should play.

 

classic99BigFileHack.zip