X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f996b,eb87e25afefa9969 X-Google-Attributes: gidf996b,public X-Google-ArrivalTime: 2001-11-24 15:56:46 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!news.tele.dk!not-for-mail From: "CeeJay" Newsgroups: alt.ascii-art References: <3bfac461.17885109@news.concentric.net> <3BFADA65.66A37D3F@rz.uni-karlsruhe.de> <3baa0398.0111202237.7660675e@posting.google.com> <3bfb538a.54540074@news.concentric.net> <3BFB7C5D.28B7BCA2@rz.uni-karlsruhe.de> <3bfb9fc1$0$89826$edfadb0f@dspool01.news.tele.dk> <3BFC0EA3.2A7D1039@rz.uni-karlsruhe.de> <3bffafce$0$248$edfadb0f@dspool01.news.tele.dk> <3C0007A2.C139E33B@rz.uni-karlsruhe.de> <3c0013b4$0$74724$edfadb0f@dspool01.news.tele.dk> <3C001C4E.CDBF128C@rz.uni-karlsruhe.de> Subject: Re: jmove JavE Date: Sun, 25 Nov 2001 00:57:33 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 125 Message-ID: <3c0033bc$0$74803$edfadb0f@dspool01.news.tele.dk> Organization: TDC Internet NNTP-Posting-Host: 80.62.219.116 X-Trace: 1006646205 dread03.news.tele.dk 74803 80.62.219.116 X-Complaints-To: abuse@post.tele.dk Xref: archiver1.google.com alt.ascii-art:11581 > > > Most of the code is from the AsciiPacker class form the open source JMOV > > > player applet. Other parts are from the original Javascript player. We > > > have added code for the sleep time between two frames and a new frame > > > compression format "D" (that almost only makes sense with 'making of' > > > movies): It only can be used when the difference between two subsequent > > > frames are a few characters in a single line. > > > > I plan to change that. Packing controlcommands into the highascii chars and > > doing other thing to reduce the overhead. > > This should reduce the size to less than 50%. or more possibly .. if you consider that out of the 7bit 128 chars not all are valid for ascii-art .. and of thoose not all are common chars .. we normally only use chars like .:,`'/-_\")([]{}+* .. etc .. letters are'nt common. However you must consider that not all chars are valid chars in javascript arrays .. a / f.x will need to be encoded with // which is something to avoid .. thoose kinds of char will need to be replaced with highchars in the array/string. I will try to find out what the valid chars are for both ascii and javascript and find the best arrangement. If it turns out that there are more than double the amount of chars available then two chars could be packed into one byte. Especially if you consider that we usually use a very limited charset of the possible range then we should be able to encode several chars into one byte. Then the exceptions (the uncommon chars) would be coded to a larger size than they would normally (same thing for extended ascii if you wanted to do ascii-art with extended ascii chars) > > One thing is to remove all the new lines , because they aren't needed .. > > I did not care about this 1kB, for I wanted to have a code that also > looks good in an editor :-) > > > anothing will be to pack to entire movie into one long javascript string because > > you waste bytes defining "",[return char] all the time > > Joaquim and I decided to use an array in order to get rid of the startup > time needed to unpack all frames at once. This was very annoying with > the old JavaScript player. Of course one can think of a different way to > pick out the single frames subsequently. I was thinking of just such a thing ! I was thinking of seperating large movies into multiple arrays so the playback could start when array 1 was loaded and the rest of the arrays would load while playing array 1 .. streaming playback ;) I also plan to reduce the number of bytes it takes to define a position by packing the number into either 2 8bit numbers (entire window maxsize would be 256 * 256) or 2 4bit numbers ( 16 x 16 window) .. or better yet .. ability to define what bits define x and what bits define y value so one could use more bits in one direction than another ( 3 x 5 bits f.x ) or use spare bits to define the char that should be in this position. I was thinking that there should be different commands for different types of position changes .. absolute or relative and with from 4 to 8 (is 256 positions enough ? or should we say 10 bits ) using the leftover bits to define the next char (and usually the only in that frame .. at least when you do "the making of ???" types of movies) one could also set the position in relation to the current cursor position and get away with have fewer bits for defining the position because normally you would only moved a short distance with the cursor. You could use even fewer chars to define position if you implemented prediction .. if a position was simply omited from the next frame then you could asume that the cursor had moved in the same direction (based on the last two frames - default would be east/right) and by the same number of chars as last time .. usually and default 1 char .. but if you altered every other char or every third that too would work fine. I also plan to decompres to a tiny little buffer so that display would not be slowed by the time to decompress but decompression could happen during delays in the display .. and maybe to start two thread for greater precision in the timing .. A trick used when you move objects in the screen with DHTML since some built in limitation in some OS's or maybe javascript implementation set a minimum delay that is not low enough to achive decent framerates .. Though I don't think this will be nessisary for asciimations since they don't normally run in this high FPS that normal animations needs. > I am looking forward to seeing the file size of the nerd boy animation > dropping below 24kB. The limit should be about 5kB for that is what > 7-Zip makes out of it removing all redundant parts from the current > code. If you made the data smaller you should be able to make it even smaller .. but if we can get below 5 KB BEFORE compressing it with a standard compression formula like zip then we have really done well. I'm going to bed now , but I'd like to post my short scribbles ( a brainstorm ) about a improved format .. some of it I have explained here ---- Use highchars as commmands Special doublebyte command for when you really want to display a highchar (non-ascii-art) Next char prediction - direction of next char Deltacompression .. either as two 8 bit (not really) input or as two 4 bit pack "/" and """ and "'" and all the other javescript specialchars into highchar commands possible commands : scrolling selection moving Store delays with a framenumber and only record changes or when different from a standard delay (deltacompression) Separate player and data. Store repeated characters as a command followed by a 4 bit number + 4 bit char (runlenght encoding) or 3 bit number and 5 bit char .. something like that ... IF the char repeated was a common char It would probably need 2 bytes if it was not a common char Parting the data into several array if the movie was very big .. for streaming playback :) --