English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 11 August 2020, 21:33   #181
sovenyimre
Registered User

 
Join Date: Jul 2020
Location: Hungary
Posts: 14
Quote:
Originally Posted by Yannick View Post
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

Last edited by sovenyimre; 12 August 2020 at 21:31.
sovenyimre is offline  
Old 11 August 2020, 22:13   #182
Yannick
Registered User

Yannick's Avatar
 
Join Date: Jul 2020
Location: France
Posts: 23
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.
Yannick is offline  
Old 12 August 2020, 00:07   #183
sovenyimre
Registered User

 
Join Date: Jul 2020
Location: Hungary
Posts: 14
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
sovenyimre is offline  
Old 12 August 2020, 04:06   #184
gsoravil
Registered User

 
Join Date: Oct 2019
Location: North Port, FL, USA
Posts: 27
Quote:
Originally Posted by stevelord View Post
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.
gsoravil is offline  
Old 12 August 2020, 07:51   #185
sovenyimre
Registered User

 
Join Date: Jul 2020
Location: Hungary
Posts: 14
Quote:
Originally Posted by sovenyimre View Post
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)

Last edited by sovenyimre; 12 August 2020 at 21:35.
sovenyimre is offline  
Old 13 August 2020, 11:05   #186
Yannick
Registered User

Yannick's Avatar
 
Join Date: Jul 2020
Location: France
Posts: 23
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.
Yannick is offline  
Old 14 August 2020, 01:16   #187
sovenyimre
Registered User

 
Join Date: Jul 2020
Location: Hungary
Posts: 14
Quote:
Originally Posted by Yannick View Post
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

Last edited by sovenyimre; 14 August 2020 at 01:34.
sovenyimre is offline  
Old 22 August 2020, 14:31   #188
sovenyimre
Registered User

 
Join Date: Jul 2020
Location: Hungary
Posts: 14
Quote:
Originally Posted by sovenyimre View Post


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.
sovenyimre is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Is Amiga the only system without a Bad Apple demo? Glen M support.Demos 11 17 July 2020 18:07
Bad Apple - Amiga shadow animation voyager Nostalgia & memories 36 19 January 2020 11:02
Bad Apple mod Zarchos request.Modules 5 07 May 2017 04:35
SWIV unsupported version or bad dump? BarryB project.WHDLoad 13 08 January 2017 12:04
Last Ninja Apple 2GS version longplay laffer Retrogaming General Discussion 4 04 June 2008 17:50

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 10:53.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.08125 seconds with 16 queries