Jave Movieplayer suggestions

As usual .. Tons of suggestions
Posted here in this group to be discussed.

1) [two-way Javascript support]
Take out visible controls from the player and put in abilities to control applet
using javascript.
I have no idea how you program this, but i have used applets and javascipts long
enough to know that you can call javascript functions from a javaprogram and
vice-versa.

The idea is to open the player to infinate new possibilities by allowing artists
to develop new features through javascript.

.. Some ideas :

*The java-controls are ugly .. replace with neat buttons that call a function in
the player when pressed.

*Floating speechbubbles (made with javascript) called from a frame in the movie.
  an example .. Frame 351 included a call to
speech_bubble(15,30,"white","#3366CC","How appropriate.. you fight like a
cow!"); - The javascript function speech_bubble would then place a speechbubble
at x-position 15 and y-position 30 saying "How appropriate.. you fight like a
cow!" in white on lightblue.

*Frame 1 could have a call to curtains(open); , and cause a dhtml animation of a
movietheater-curtain to open revealing the "screen" .. ie the appletwindow. The
last frame could then have a call to close the curtain

*Interactive movies : "You come to a junction .. Do you want to go left or
right"
Depending on what you choose the movieplayer would skip to a different senario.

*Scriptable soundeffects .. Yeah .. use midi , or wav or whatever soundformat
supported by your browser to make to audiopart of your movie.
Why draw captions when you can record them in weird voices and play them back at
the apropriate frame ? :)

2) [Individual and accurate timing of specific frames]
At first define a default speed to show the movie (in fps or miliseconds between
each frame)
Continue to render frames at this speed until reaching a frame containing a new
default speed (to use from that time .. until again reaching a new default)
For further control a frame could have a command saying how long it should
display if the display time differed from the default. this could be in
miliseconds or in number of frames (at the current default speed). Like if the
frame had a command saying "15f" and the speed was 15fps , then the frame would
stay on screen for a full second.
This also reduces the filesize greatly since you no longer have to enter the
same frame 15 times to get the same effect.

3) [Recycle!]
Some frames are repeated when making movies.
Have the player support this.
A frame could have no ascii-art-image in it but instead a command saying to
display a different frame instead.
Default should be to duplicate the output of the other frame completely but with
an option to override certain or all settings.
F.x if you wanted the recycled frame to be seen only half as long time as the
first time it was displayed you would override it's displaytime. If you didn't
want to execute the functioncall in the recylcled frame (if it had one) you
could override it too .. and vice-versa if the recycled didn't have any and you
wanted one now.

(If this is confusing I can illustrate it with a small cartoon. Just say so.)

3) [advanced recylcing]
Use certain frames as background/foreground for specific frame.
You could draw a large lunar landscape and then use this as a background for the
following frames that would display a little martian spaceship landing.

4) [Moviecompression)
Store each frame as only the differences from another frame. It doesn't have to
be the previous frame (though this is easier to implement), for optimum
compression it should be based on the frame in the movie that remsembles it the
most.

5) [extra compression]
The player already does this actually .. it supports zip compressed files as
input.
The optimum would be using a compression-algoithm specificly suited for
compressing text.

6) [custom textfields)
I studied the jmov format and found that some frame have extra info such as this
example :
"
T:Ellipse Generic
A:draw ellipse
"
T: is the Text box and A: is the Action box in the player window .. showing how
you made that step in Jave.
I think it would be neat if you could define your own fields and use them for
captions in cartoons f.x.
(while we wait for this to be implemented you can hack the jmoz file and altered
the T: and A: fields by hand to include captions)
Actually this would probably be better if implemented using the "two-way
Javascript support" suggestion i made at first.
To make the file smaller and easier to edit by hand, you could define a custom
field at the beginning to be input for a javascript function.

F.x if you wanted to have a narrator "speak" while the movie was progressing you
could define a N: or Nar: or Narrator: field to be input for a function named
Narratortext();

or to reuse my example in "two-way javascript support"
speech_bubble(15,30,"white","#3366CC","How appropriate.. you fight like a
cow!");

Could be :

Say:15,30,"white","#3366CC","How appropriate.. you fight like a cow!"

if we had first defined fieldalias Say = function speech_bubble;
or something like that.

perhaps this could even be expanded with a CSS-like property assigning.

Fx if Say.blue: and Say.red: where two alias's for making speechbubbles in blue
and red.

It's late and I can't really see the perfect way to do this .. but I guess it
will be okay as long as no one starts using the term Ascii Style Sheet .. or ASS
for short. *grin*

7) [colourchange]
A supported command to change output colours.
F.x if a scene suddenly turned bloody the output could change from white on
black to bloodred on black.


Darn .. I can't remember any more for now.
I will have to come up with more later.

In the mean time have a look at http://www.asciimation.co.nz/ where Simon Jansen
hosts his StarWars Asciimation (great name Asciimation btw .. I think this
should be the Jave Asciimation player or Jave Asciimator)
It's the biggest ascii-movie project i know of and the only other Java
asciimation player in existence.
His FAQ page tells about some of the ways he handles asciimation in his player.

AND the StarWars movie is a must-see , though he have not updated it for quite
some time now .. he seems to be busy building jet-engines (
http://www.asciimation.co.nz/turbine )
What an �bergeek ! .. I kinda admire him :)

He might also have some comments and idea for what features a
asciimation-player/animator should have.
You could try emailing the man.

Sincerly
Christian 'CeeJay' Jensen

P.S. remember I posted all of theese ideas here to get some input on them ... so
give me that input.
Do they suck/rule ? .. do you have further ideas/improvements ?

Hi,

> As usual .. Tons of suggestions
> Posted here in this group to be discussed.

Great. I want to make some statements about the compression:

> 4) [Moviecompression)
> Store each frame as only the differences from another frame. It doesn't have to
> be the previous frame (though this is easier to implement), for optimum
> compression it should be based on the frame in the movie that remsembles it the
> most.

I have done lots of testing now and the result is clear to me: I will
not add this kind of differential compression to the jmov-format.

Here is what I have done:

I have written a converter to convert the star wars asciimation
(http://www.asciimation.co.nz/) into the jmov format. The asciimation
format is very simple, because it stores all frames in a compressed text
file. Each frame has a number telling for how long it has to be
displayed (how often it has to be repeated when using 15fps). (Note: the
other things discussed about differences of frames in the
asciimation-faq do not apply to the player, just to the way the
animation has been created)

To handle this multiplicity in jmov I have added a new option to the
jmov format. The jmov-command for a new frame ("J: ...") without
compressed content code attached will be handled just as if the content
did not change since the last frame.

Now here are the results from my tests:
              +------------------+-------------------+
              |       raw        |       ZIPed       |
(13934frames) |Bytes/            | Bytes/            |
              |  Bytes per frame |   Bytes per frame |
+-------------+------------------+-------------------+
|  original   |     1688323/     |      72326/       |
| asciimation |      121.1       |        5.2        |
+-------------+------------------+-------------------+
|    JMOV     |     954966/      |      65523/       |
|             |       68.5       |        4.7        |
+-------------+------------------+-------------------+
|    JMOV     |     369507/      |      51004/       |
|diffenential |       26.5       |        3.7        |
+-------------+------------------+-------------------+

So supporting differential compression is 22% better (after ZIP
compression) than compressing w/o looking at the differences. On the
other hand it makes it much more difficult to write software for the
jmov format.

So I do not want to add support for this kind of compression.
BTW: I think 4.7Bytes per frame is very good - the best ascii animation
compression I have seen in the www (consider the JavaScript animations).

But if you insist on getting better compression rates have a look at
AsciiPacker.java in the Jave Player package. There is only one (real)
compression algorithm in there for compressing a single frame - and it
is not a very good one either. Today I have tested two ideas for
improving it but the result always was the same: the raw jmov file
becomes slightly smaller, but the ZIPed one grows...

> 7) [colourchange]
> A supported command to change output colours.

Support for that will be available in the next release.

Markus

PS: It is an open source project - everybody is invited to improve the
player :)