Bad Apple Amiga Version

[Tsak]

Wow, that's actually quite impressive @gyagyagyerek!

[saimon69]

My opinions for vectorize:
video frames should be posterized so to have white and max 2 shades of gray and if the converter allows i would take out the bezier option, need only lines plus some optimization to remove too much lines; not sure but the old adobe streamline might work on that a bit - i envision a good amount of hand optimization too
OR the tool made by spaceballs to do nine fingers, if is still around.

Maybe the above has been already made and i am sputtering 85

[stevelord]

Originally Posted by gyagyagyerek

Hi!

I converted all frames to svg but it is unuseable.
The lines curved, bended ....from point to point.
If anyone know a converter for fixed points... I am?

Until then... I think you all interested.

https://electricblacksheep.itch.io/bad-apple
https://www.dropbox.com/s/hziyd4xkvp...Saber.rar?dl=0
[ Show youtube player ]

Just a heads up, your itch account is selling this for $2. I'm sure you didn't just come on a thread I started about my anim to sell your own version of Bad Apple and it's just a mistake. Just wanted to give you a heads up iin case you missed it.

[gyagyagyerek]

Originally Posted by stevelord

Just a heads up, your itch account is selling this for $2. I'm sure you didn't just come on a thread I started about my anim to sell your own version of Bad Apple and it's just a mistake. Just wanted to give you a heads up iin case you missed it.

You don't have to pay, It is free! Above th $2 option there is a "No thanks, just take me to the downloads" link.

[Seiya]

@gyagyagyerek
very very nice. good
Now, in 2020, Amiga has Bad Apple

[chip]

The "dance" version

[ Show youtube player ]

[Seiya]

Originally Posted by chip

The "dance" version

however they are great!

[chip]

Yep, i think it's really funny

[Yannick]

HI All,

I've re-registered especially to post on this thread. I had an old account that is no more active it seems.

Basicaly, what I've done is :
1. Extract All images from Bad Apple in PNGs
2. Convert PNGs to Black/White (1bbp) data
3. Convert PNGs to SVGs using autotrace (or potrace)
4. Convert each SVG to single paths using only straight lines and simplify path using RamerDouglasPeuker algorithm,
5. Data is then compressed to 2 bytes / points (255*255 vector resolution)
6. Raw data is further compressed using libminiz
7. Data is formate dand stored to be able to render frames using AreaMove/AreaDraw/AreaEnd commands

The player is a simple Zune(MUI) class and is only 40kB even if full libminiz is included (also compressing routing).

The data is compressed to about 850kB (can be made less, 400kB is showing alterations but is still recognisable)

The video can be found here:
[ Show youtube player ]

The data and tools are available here:
https://sourceforge.net/p/zunetools/...tree/BadApple/

The concept is running under AROS, there is no m68k version existing, and no AmigaOS port (I guess this would require heavy optimisation for rendering in real time, if someone want to take the challenge, I'm happy to support and further work on data processing/compression)


PS : All of this have been done last year and posted on Aros-Exec (https://ae.amigalife.org/index.php?t...g4777#lastPost)

[Tomislav]

Originally Posted by Yannick

I've re-registered especially to post on this thread. I had an old account that is no more active it seems.

Maybe you had less than 10 posts of 6 months of being registered. Inactive in the forum in next link.
http://eab.abime.net/faq.php?faq=eab...aq_eab_account

[chiark]

@SteveLord, with the watch project and this I'm starting to think you're my long lost and way, way more productive twin: I've been scratching my head at how to do Bad Apple well on the Amiga.

Yannick, thanks for re-registering and sharing. Bad Apple on OCS Amiga in 1 or 2 disks is what I would love to do, and will look to help... That's awesome work - I got as far as extracting the PNGs, then converted 1 to SVG using potrace and found it came in at 5KB... And parked the idea until I had more time...

Thoughts:
- some cels are definitely a lot simpler than others and so could be represented using different simplification of Ramer/Douglas/Peucker algorithm
- is there a way of converting into a format that would be efficiently filled by the blitter (ie a raster representation)... and would that be fast enough?
- a combo of blitter and cpu filling would provide maximum performance, but my gut feeling is that if the data is in the right format, it could be manipulated with triple buffering - memory won't be a problem with 1 bitplane graphics

[Yannick]

SVG is not very size efficient. Coordinates are floats and file is in Ascii (xml) format.
Most of the gain comes from using 2 bytes per points in my method and removing all unnecessary symbols from the output file.
The file is at the end just a collection of paths each of them is a number of points and then the points themselves in a grid of 255x255.

[nogginthenog]

Originally Posted by Yannick

HI All,

I've re-registered especially to post on this thread. I had an old account that is no more active it seems.

Basicaly, what I've done is :
1. Extract All images from Bad Apple in PNGs
2. Convert PNGs to Black/White (1bbp) data
3. Convert PNGs to SVGs using autotrace (or potrace)
4. Convert each SVG to single paths using only straight lines and simplify path using RamerDouglasPeuker algorithm,
5. Data is then compressed to 2 bytes / points (255*255 vector resolution)
6. Raw data is further compressed using libminiz
7. Data is formate dand stored to be able to render frames using AreaMove/AreaDraw/AreaEnd commands

Superb!

If this could fit on a floppy with audio it would be amazing.

[chiark]

Thanks Yannick, interesting. I think it will need to be converted from a set of points as, to my limited knowledge, drawing unoptimised lines and then filling is not that efficient... Still at work at the moment, but will apply some thought to this. Not that I'm much of a coder. At all.

[robinsonb5]

Just thinking aloud here, but it seems like this is a gift for the blitter's fill mode.

How about, to encode a frame, start at the top left, scan from left to right, count for how many words the colour doesn't change, and store this value. Now store a literal word, which has a '1' bit for where the colour changes, so if the word looks like "BBBW_WWWW_WWWW_WWWW" you store 0x1000, for "BBBB_BBWW_BBBB_WWWW" you'd store 0x0288. Then repeat - count how many words until the next change in colour, then store a literal, and keep doing that for the whole frame.

Writing to a buffer from this kind of format should be really fast, and the Blitter can be filling the previous frame at the same time. I'd expect it to compress pretty well, too.

[stevelord]

@robinsonb5 I had a similar idea for 1-bit but with 16x16 blocks, a bit like the 8x8 character setup used on the c64 port. I'd extract all possible 16x16 blocks and stream in a lookup table and offsets to update per frame, and a special value to set the screen white or black. As long as dithering wasn't used it'd probably be ok.

@Yannick: Are you storing all points per frame, or only the ones that change?

@nogginthenog: I'm not sure one floppy would work, but the song is rather repetitive. It might even be possible to fit loops into a protracker mod. My raw 22030hz 2 channel stereo 8svx file is 9.5mb, so a 1ch 5.5k sample would be around 1.2mb uncompressed. That's possibly 2 floppies for the whole thing which would still be quite an achievement.

[robinsonb5]

Originally Posted by stevelord

@robinsonb5 I had a similar idea for 1-bit but with 16x16 blocks, a bit like the 8x8 character setup used on the c64 port. I'd extract all possible 16x16 blocks and stream in a lookup table and offsets to update per frame,

Right - but there are a *lot* of possible 16x16 blocks - that LUT's going to be pretty big unless I'm misunderstanding you?

and a special value to set the screen white or black.

If you're blitter filling, that can be done with the blitter's carry-in flag.


I've also just realised that if the blitter filling has a separate source and destination buffer, each successive frame only needs to write to the words that have changed, and wouldn't even need to clear the blank areas - it could merely step over those. The most efficient method might actually be to encode vertical spans of 16-pixel wide stripes, as literal data.

@nogginthenog: I'm not sure one floppy would work, but the song is rather repetitive. It might even be possible to fit loops into a protracker mod. My raw 22030hz 2 channel stereo 8svx file is 9.5mb, so a 1ch 5.5k sample would be around 1.2mb uncompressed. That's possibly 2 floppies for the whole thing which would still be quite an achievement.

I think I'd vote for an instrumental cover as a mod file, rather than low-quality samples - but that's just me.

[mcgeezer]

A1200 could probably do this from two floppies.
I love the demo and i could probably tempted to write a player if i can understand the frame format easily enough.

Standard ocs cant do it, but aga very likely - floppy.

[ross]

where it all started:
[ Show youtube player ]


and this?!?
[ Show youtube player ]




I'm writing a sectors loader with an arjm7 real-time decompressor.

Who knows ..

[Yannick]

I’m storing all points per frame, inter frame compression is very poor as only two consecutive identical frames are detected and optimized.
Detecting changes in between frames could bring improvements, but the algorithm to detect and encode point movements between frames is not trivial at all.