Bad Apple Amiga Version

[sovenyimre]

Originally Posted by Yannick

Hi,

Nice work given it's done with AMOS!
One of the biggest challenge we have with Ross is to pack all data on one floppy.
We are using a little bit more than 1 16bit word/point.
Also the control words (number points / polygon, frame start, frame end, etc) is minimised.

It would be nice to share with you in order to reach the best possible compression rate.

With current setup, we are squeezing approximately 36000 polygons / 500000 points on one floppy.

Amos is ....not lighting. In this case it can draw about 128 lines per frame (25FPS), this was needed to maintain the continuous playback, but to the result of reducing the file size, after conversion, this eventually resulted in a maximum of 96 lines.
Since the timer works with 50 tick and in AMOS and I can't adapt to anything else, the timing is 50/2=25FPS.
I store the data at 8bit instead of 16bit because at 320x256 image size they caused quite a large loss due to values ??ranging from 256-320. For all these reasons, I set the image size to a size that can be described by 1 byte .... 256x256, as well as the coordinates of the points that make up the lines. In fact, I draw the line the same way the SVG file stores the route .... (m x1 y1 c x1 y2 x2 y2 x3 y3 x4 y4 l x1 y1 z)
In my (powerpacked!) DAT file, I use 255 bytes instead of M, 254 bytes instead of C and L, and 253 instead of Z, which means the end of the frame.
After any previous value, the next value that is smaller means the two coordinates x, y .... 1-1 bytes. So it’s almost SVG, but what’s even different from SVG is that it wasn’t a good idea to store negative values ??because it only required extra computation, so I use direct coordinates instead of relative coordinates.
Finally, the result
max image size 252x256 -25 FPS
Frames: 5476 (Z=byte253)
Jump to points: 67151 (m,M=byte255)
number of lines : 72365 (c,l=byte254)
...also could be some junk data :/

Postscript:
Calculating the image per frame so that the image remained recognizable despite the distance between the points and the maximum number of lines..... I learn something every day

[Yannick]

Are you calculating/interpolating the curves in real-time? Or just linking the points with lines?
In my method, I convert all curves to lines first by interpolation and then I optimize the number of points ( removing the points that do not add much details)

We have coordinates in 352x217 space for the moment. And thanks to some clever tricks we use 16.1 bits average to store one point (thanks to Ross for this)

Looking at your results, I did not expect you to have so many points stored.

[sovenyimre]

I tried to get the best result in bmp to svg conversion with potrace...few but longest strait lines as possible, so I do not interpolate. Tried to turn off the curved lines with -n switch but the result was more points even in strait lines so I converted with curves but but also used the switch -a 0.5 to get sharper corners and sadly I just left out the middle two value in curved path in svg (means: C 100 100 100 0 200 0 200 100 result: L 100 100 200 100) . Then I eleminated those points were too close to each other, step by step measuring the current step distance and skip if smaller than I wanted to be. Also counted all the lines in 1 frame and when the numer of lines was bigger what I wanted
, I increased the previous distance criteria and recalculate until it reached.
Still experimenting for a better result.
No realtime calculation, just linking. The source is only a few lines:

Screen Open 0,256,216,2,Lowres : Screen Display 0,160,,,
Palette $0,$FFF : Cls 0 : Screen Swap : View : Flash Off : Hide On : Double Buffer : Autoback 0 : Sprite Update Off : Bob Update Off : Update Off : Auto View Off : Synchro Off : Amal Off
Ppfromdisk "BadApple.dat",15
If Exist("BadApple.mod")=-1 : Track Load "BadApple.mod",5 : Track Play 5 : End If
POS=0 : ST=Timer
SF:
V=Peek(Start(15)+POS)
If V<253
If M=2 : F Draw V,Peek(Start(15)+POS+1) : Add POS,2 : Goto SF : End If
If M=1 : Gr Locate V,Peek(Start(15)+POS+1) : Add POS,2 : Goto SF : End If
Else If V=254 : M=2 : Inc POS : Goto SF
Else If V=255 : M=1 : Inc POS : Goto SF
Else
Add POS,1,0 To Length(15)
Screen Swap
Video Wait 256
FPSW:
If Timer-ST<2 : Goto FPSW : End If : ST=Timer
Blit Clear -1
Inc F
Goto SF
End If
End

[gsoravil]

Originally Posted by stevelord

Nice! What agaconv switches did you use to encode the file, and how big did it turn out? I went down the anim route because of the huge size differences between that and AGAconv. My 320x256 vids were coming in around 230mb IIRC.

Hey stevelord. Guess I'm a little slow to see this.

If you look at the video around 28 seconds or so, you can see my filename where I embed it with info (so I can remember). So fps is 30, frequency is 28867, etc. These would directly translate to agaconv options:

--max-fps=30 --max-colors=16 --screen-mode=hires --width=640 --frequency=28867

The one thing I didn't embed was that I *think* I used --color-mode=EHB on this particular video.

movec (the author of the tools) did correct me in that the video is not ~400-480 lines like I first thought but rather it's not interlaced so agaconv would have used ~200-240 lines for the vertical. i.e. 640x240, not 640x480

My filesize is visible at the end of the video, but I believe it was something like 540MB. This is massive though I am using huge partitions (by Amiga standards) so I can live with it.

[sovenyimre]

Originally Posted by sovenyimre

Jump to points: 67151 (m,M=byte255)
number of lines : 591061 (c,l=byte254)

I think i give you false statistic, not from the dat file i use in adf. The number are lower... much lower. I will correct it.
... sorrry.

Correct numbers:
Jump to points: 67151 (m,M=byte255) <---!? What a waste... Do not have to be that much ?!
number of lines : 72365 (c,l=byte254)

[Yannick]

Hi,

Yes the commands are a waste.
Each polygon is starting with an M command, you don't need to store this information.

As I'm only using lines and no more curves, I don't need a command for each point.
I store the number of points for each polygon, and a indicator to tell if this polygon is in a new frame or in the current one.
then the points are just stored consecutively without any overhead.

Some info is available here :
https://sourceforge.net/p/zunetools/...tree/BadApple/

PS :
This is a bit old, now we are storing 2 streams, one for commands/tokens and one for points, this increases compression rate a bit and eases some processing.

[sovenyimre]

Originally Posted by Yannick

Each polygon is starting with an M command, you don't need to store this information.

I reduced a few things:
I need the Z controll data (end frame) but I don not need to store the M controll (positioning) right after Z, and when I need the M (...rarely), I autoswitch back to draw mode right after that positioning so I do not have to store L controll data at all!
Conclusion... I have only 2 types of controll (Z+M)byte. 5476 byte for M End frame (25fps), 24936 byte for moving the pointer, the rest of the data is all for coordinate points, ((filesize 801364)-(5476+24936))/2= 385476 coordinate points (x+y)
-compressed Dat file 747636 byte

https://electricblacksheep.itch.io/b...iga-vectorized

[sovenyimre]

Originally Posted by sovenyimre

https://electricblacksheep.itch.io/b...iga-vectorized

If anyone is interested...
I uploaded the AMOS "Tool"? I made for creating the vector version.
If You want see the result in Your lifetime I recommend to use it under winuae.
It is an easy step by step process as I tried to solve thing....but adjustable and at the end, working on real hw.

[heavy]

something new about a "final" version ?

[Yannick]

Hi,
I believe Ross and myself have been distracted by other things.
I will get in touch with him to define what both of us think is missing to release our version.

Yannick

[chiark]

that would be awesome! The progress so far is fantastic on the video, I think that the biggest challenge was audio...

[sovenyimre]

A little update ... and ask for help:
I was able to slightly improve the detail compared to my previous version.
-I leveled the source frames individually based on whether there are black figures on a white paper or white on black.
-I removed unnecessary barely visible minor dots, such as stars
-Used multiple steps with higher numbers to reduce lines before downscaled to byte, ...for some reason, backscale to hires also looks better.
-Due to a kind of (low-pass?) filter, the lines vibrate less, this also results better compression.
https://electricblacksheep.itch.io/b...iga-vectorized

Next....I thought I'd try a filled-poly version.
To do this, I would have to split the concave polygon groups into (less as possible) convex ones, but the task is more complicated than I thought.
I know the best is to draw it by hand but...Does anyone know a good solution?

[Samurai_Crow]

The Amiga polygon plotter works fine with concave polygons but the real trick is to fill all of your polygons at once. A pixel encountered by the fill toggles between filling 1s or 0s so the trick is to exclusive-or the border bits so that only the necessary changes are made.

[xyzzy1]

How about using HAM6 mode to line-fill polygons for free?

[sovenyimre]

Originally Posted by xyzzy1

How about using HAM6 mode to line-fill polygons for free?

Interesting solution, but raises additional problems as the line drawing is counterclockwise but not arranged from left to right and there would be cases to be handled even with ordered lines.
thanks for the tip, i will still think about it.

Originally Posted by Samurai_Crow

The Amiga polygon plotter works fine with concave polygons but the real trick is to fill all of your polygons at once. A pixel encountered by the fill toggles between filling 1s or 0s so the trick is to exclusive-or the border bits so that only the necessary changes are made.

I or AMOS has a little problem to work with polygons because I can type limited length of one line to compile so I have limited number of coordinates to work with at once.
If I use Polygon to x,y the result is the first image... the problem is visible on the second image.
If I use Polygon x1,y1 to x2,y2 to ... then I have a limit. Exclusive-or works fine but the result isnt, visible on the third image.

[Samurai_Crow]

Originally Posted by sovenyimre

Interesting solution, but raises additional problems as the line drawing is counterclockwise but not arranged from left to right and there would be cases to be handled even with ordered lines.
thanks for the tip, i will still think about it.



I or AMOS has a little problem to work with polygons because I can type limited length of one line to compile so I have limited number of coordinates to work with at once.
If I use Polygon to x,y the result is the first image... the problem is visible on the second image.
If I use Polygon x1,y1 to x2,y2 to ... then I have a limit. Exclusive-or works fine but the result isnt, visible on the third image.

I thought you were using the AMCAF extension on AmosPro. It allows unlimited border bit line draws and fills in a separate step. Now that AMCAF is freeware on the Aminet there's no longer a reason to mess with AmosPro's limited polygon support.

You may want to triple buffer because fill doesn't work right on something that's already been filled.

[sovenyimre]

Originally Posted by Samurai_Crow

I thought you were using the AMCAF extension on AmosPro. It allows unlimited border bit line draws and fills in a separate step. Now that AMCAF is freeware on the Aminet there's no longer a reason to mess with AmosPro's limited polygon support.

You may want to triple buffer because fill doesn't work right on something that's already been filled.

I am using AMCAF but not that part.
I had no idea, because my mind stuck on the line limit.

It is already working with a small error but I will solve that.
I will upload tomorrow.

Thank You

[Samurai_Crow]

You're welcome!

[sovenyimre]

I fixed the line-bug and added some antialias!?... looks better
Uploaded the new version.

https://electricblacksheep.itch.io/b...iga-vectorized

[sovenyimre]

If anyone is interested:
I made a Windows converter that makes DAT file from potrace SVG image sequence.
If You have to cusomize it, the archive contains the Burebasic Source and The Bad Apple image sequence I worked with so anyone can experiment with it.
I know this is an amiga related page but for BadApple, the full conversion from .Svg sequence to .Dat is under one minute and you can play the result on amiga!