B-movie;)

Compressed animations on VMU!

History of B-movie;) development:

Read from bottom to top:

Some features previously not mentioned: When a movie plays, the keys are checked after every frame - so pressing sleep and mode button will have effect. The last pressed keys are saved so that the application can react when the movie finishes - if necessary. Also it is possible to include forward/backward play control into this keycheck so that the user can decide to play forward or backward at every position in the movie.

Update: I decided to solve the problem of equal images for a number of frames another way: When an image contains no changes to the previous one, it is indicated with one header bit. This looks like there is the beginning header nibble and the end header nibble, but no imagedata in between. Advantage is that you can display an arbitrary amount(not only one as before) of those images without wasting space. Another thing is, that such empty frames can also be the last frame of movie.

Another great idea - I think... - following. Imagine to built menus with cursors and click-on-areas. This is a quite time consumpting work and also difficult sometimes. Implementing little movies and animation to switch between different menu-items and cursor positions makes much more interesting and good looking menus possible that previously were not. So, what needs B-movie;) to fit these goals? When implementing menus like mentioned above, its necessary to play movies backwards. Instead of compressing every movie to a forward and a backward version, why don't simply play the same movie backwards? So from now on, every image does not only have a header nibble, it got also an end nibble.

!Updated above! Still examining cases to save bytesize. In every movie, there are situations when a message or something is displayed longer as only one frame. The difference image consists only of zero bits. Encoding these results in 16,5 bytes per frame. So, still having one control bit left in the header(previously dedicated to signalize framerate, but because of only two rates to choose from not a good idea - so, before starting the movie, select framerate in your code) I defined this bit to indicate that the next image contains no changes and updating the screen continues after that no-changes-frame. So you don't have to care about wasted space when displaying the same image for some time in a movie. Now, this case takes only 8,25 bytes a frame.

Don't underestimate the power of header nibbles;). Still space in these first four bits left, why don't let them indicate when the movie is over? At this point, a lot of the movie control is done itself. Cool!

I experienced, that B-compression is not in all cases the best to do. So when all kinds of compression result in higher imagesize, header nibble tells decompressor, that the frame is uncompressed. This led to a point where B-compressed movies are always not bigger in size, then uncompressed movies.

This enables B-compression to take effort of the technique to only compress changes to previous frame as positive bits, leaving all others negative. Good thing! But we have to tell the decompressor how it has to treat the current image. Header nibbles were introduced.

Next thing was to show images in sequence to make animation and movies possible.

Compression was not very good. So it came in mind to compress one whole line of 48bits with only one nibble. A case that very frequently occurs. Because these nibbles like 0000 and 1000 were previously unused it caused no disadvantages to do this.

A sample program was written to show these compressed images on VMU screen. Also a tool was written to compress images produced by neuros666's bmp2asm.

Search for a compression method to compress still fullscreen images. Run length encoding came in mind(although I did not know of RLE). Several versions where worked out. Variable length of units was buggy and unlikely to implement. So decision went to constant length of 4 bits a unit. The basic concept of B-compression was born.