English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 12 July 2020, 17:30   #21
Tsak
Pixelglass/Reimagine

Tsak's Avatar
 
Join Date: Jun 2012
Location: Athens
Posts: 612
Wow, that's actually quite impressive @gyagyagyerek!
Tsak is offline  
Old 12 July 2020, 19:17   #22
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 1,492
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
saimon69 is offline  
Old 12 July 2020, 19:23   #23
stevelord
Registered User

 
Join Date: Apr 2019
Location: UK
Posts: 140
Quote:
Originally Posted by gyagyagyerek View Post
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.
stevelord is offline  
Old 12 July 2020, 20:27   #24
gyagyagyerek
DIY

gyagyagyerek's Avatar
 
Join Date: Sep 2018
Location: Budapest
Age: 42
Posts: 66
Floppy disk Free

Quote:
Originally Posted by stevelord View Post
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.
gyagyagyerek is offline  
Old 12 July 2020, 20:31   #25
Seiya
Registered User

Seiya's Avatar
 
Join Date: Nov 2014
Location: Italy
Posts: 1,069
@gyagyagyerek
very very nice. good
Now, in 2020, Amiga has Bad Apple

Last edited by Seiya; 12 July 2020 at 20:41.
Seiya is offline  
Old 12 July 2020, 20:58   #26
chip
Amiga Demoscene Archive !
 
Join Date: Oct 2012
Location: Italy
Age: 45
Posts: 1,900
The "dance" version

[ Show youtube player ]
chip is offline  
Old 13 July 2020, 04:23   #27
Seiya
Registered User

Seiya's Avatar
 
Join Date: Nov 2014
Location: Italy
Posts: 1,069
Quote:
Originally Posted by chip View Post
The "dance" version

however they are great!
Seiya is offline  
Old 13 July 2020, 08:12   #28
chip
Amiga Demoscene Archive !
 
Join Date: Oct 2012
Location: Italy
Age: 45
Posts: 1,900
Yep, i think it's really funny
chip is offline  
Old 13 July 2020, 10:18   #29
Yannick
Registered User

Yannick's Avatar
 
Join Date: Jul 2020
Location: France
Posts: 23
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)
Yannick is offline  
Old 13 July 2020, 12:34   #30
Tomislav
Registered User

 
Join Date: Aug 2014
Location: Zagreb / Croatia
Posts: 230
Quote:
Originally Posted by Yannick View Post
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
Tomislav is offline  
Old 13 July 2020, 17:11   #31
chiark
Needs a life

chiark's Avatar
 
Join Date: Jan 2008
Location: England
Posts: 1,657
@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

Last edited by chiark; 13 July 2020 at 17:37.
chiark is offline  
Old 13 July 2020, 18:43   #32
Yannick
Registered User

Yannick's Avatar
 
Join Date: Jul 2020
Location: France
Posts: 23
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.
Yannick is offline  
Old 13 July 2020, 19:36   #33
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 973
Quote:
Originally Posted by Yannick View Post
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.
nogginthenog is offline  
Old 13 July 2020, 20:37   #34
chiark
Needs a life

chiark's Avatar
 
Join Date: Jan 2008
Location: England
Posts: 1,657
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.
chiark is offline  
Old 13 July 2020, 21:18   #35
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 818
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.
robinsonb5 is offline  
Old 13 July 2020, 22:17   #36
stevelord
Registered User

 
Join Date: Apr 2019
Location: UK
Posts: 140
@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.
stevelord is offline  
Old 13 July 2020, 22:53   #37
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 818
Quote:
Originally Posted by stevelord View Post
@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?



Quote:
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.


Quote:
@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.
robinsonb5 is offline  
Old 13 July 2020, 23:22   #38
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,923
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.
mcgeezer is offline  
Old 13 July 2020, 23:56   #39
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,800
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 ..
ross is offline  
Old 14 July 2020, 09:33   #40
Yannick
Registered User

Yannick's Avatar
 
Join Date: Jul 2020
Location: France
Posts: 23
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.
Yannick 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 17:08.


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