Settings

The page will reload to apply your changes.
Theme

ASCII Art Font

ASCII Art Menu

Original Usenet message from alt.ascii-art, 24 Nov 2001.
Re: jmove JavE

Re: jmove JavE

> > > 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 :)

--

Original message headers
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" <use...@ceejay.cjb.NOSPAMnet>
Newsgroups: alt.ascii-art
References: <3bf...@news.concentric.net> <3BF...@rz.uni-karlsruhe.de> <3ba...@posting.google.com> <3bf...@news.concentric.net> <3BF...@rz.uni-karlsruhe.de> <3bfb9fc1$0$89826$edf...@dspool01.news.tele.dk> <3BF...@rz.uni-karlsruhe.de> <3bffafce$0$248$edf...@dspool01.news.tele.dk> <3C0...@rz.uni-karlsruhe.de> <3c0013b4$0$74724$edf...@dspool01.news.tele.dk> <3C0...@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$edf...@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: abu...@post.tele.dk
Xref: archiver1.google.com alt.ascii-art:11581
About this message. This message was posted publicly to the newsgroup alt.ascii-art in 2001 and is mirrored here unchanged as part of the Historic Archives – only email addresses are masked. The artwork and text belong to their original authors: if you copy a piece, keep the artist's initials or signature intact and credit them where you can. Are you the author? Contact us to get your posts attributed, connected to your artist profile, or removed.

Report this message

Help us keep the archive clean and accurate. Reports are reviewed by a person – nothing is changed automatically.

Help classify this post