Bad Apple demos

[stephen_usher]

It turns out that the offset etc. was actually the ImageMagick "convert" program screwing up when coalescing the animated GIF frames and rescaling them at the same time. Then there was the issue of the XBM images being in inverted "colour", so I'm going to have the re-write my pre-processing stage to account for these things.

Still, it's too slow at the moment.

[stephen_usher]

You may be more interested in these videos:

https://youtu.be/ZPp0dYEpaCY
https://youtu.be/HjWm5r31Ysw

Convert still seems to be causing some issues and there's an aspect ratio issue too.

[mk79]

I think you should be telling us a lot more about your AY equipped QL too

Well, it's a QL. With an AY chip Connected to the SGC PAR port. Quite simple really. One of many things I've been playing with the last year and didn't find the time to actually document/release.

[Cristian]

Convert still seems to be causing some issues and there's an aspect ratio issue too.

What about removing the dithering, and/or switching to MODE8? May this help somehow?

[stephen_usher]

The dithering is being done by ImageMagick and Mode 8 would be slower. There are just as many bytes to move and the pixels are more complex.

The a lot of the time is the writing to screen memory. Someone could probably re-write it better in assembler but screen writes are always slow on a QL.

[stephen_usher]

Hmm.. Just tried it on the Trump Card. Each frame takes about 4 seconds up update (minor changes) with the more complex frames taking double that.

I think that's as far as I can go at the moment.

If you want to run the test on your own machine/emulator you can download a DSDD floppy image here: http://www.lingula.org.uk/~steve/share/testm4v.img

And if you want to play with the latest code: http://www.lingula.org.uk/~steve/share/m4vcodec.tar.gz

[stephen_usher]

OK, I've now added a 32K disk buffer for the read and it's helped quite a bit, though not enough on a stock QL+Trump Card (still multi-seconds per frame). On the QL+SGC clone the video runs as practically full speed.

I've updated the tar file and demo disk image on my server accordingly.

P.S. Here's a video (SGC): https://youtu.be/aK-E-42Vvyk

[vanpeebles]

I think you should be telling us a lot more about your AY equipped QL too

Well, it's a QL. With an AY chip Connected to the SGC PAR port. Quite simple really. One of many things I've been playing with the last year and didn't find the time to actually document/release.

Can you play chip choons???

[Derek_Stewart]

If you want to run the test on your own machine/emulator you can download a DSDD floppy image here: http://www.lingula.org.uk/~steve/share/testm4v.img

Hi Stephen,

I downloaded your testm4v.img file and loaded onto the Q68, running SMSQ/E 3.34

I used FDI to read the FLP image, I altered the boot file not to load TK2_EXT and remove the format command on the ram disk.

The video ran very smoothly, in Q68 512x256 4 colour mode.

Well done, an excellent piece of work.

[stephen_usher]

I've been doing a little cleaning and tweaking since the img was created (and I've found how to get "convert" to stretch the image so it uses all the screen).

Here's a larger (and better rendered) version of test_m4v: http://www.lingula.org.uk/~steve/share/test_m4v

Here's a video of it: https://youtu.be/inDPk8hV2GA

From the test so far it seems that the file size/minute would be about 6MB, which means that the full 5min 24sec video would be pretty big. However, it does compress with zip well, ~47% the last time I tried. If there's enough CPU cycles available it would be useful to have the file zipped and decompressed in the decoder on the fly. Even so you'd need a WIN_ device with about 16MB to hold the file. Unless, of course you reduced the frame rate.