Worlds has many interesting file formats and specs surrounding itself, some not properly documented, some we know too much about. But if there was one format we truly do not have any information for despite it's common and required usage in Worlds, it is the CMP/MOV format. Most people think these file-types differ due to the extension, but they are entirely the same and interchangeable. Try it out, change the extension and use it. This thread serves to be a community effort to figure out the true origins and purpose of this file format, as well as reverse engineer it for expanding upon it. I will update this post with additional info when more becomes available.
The general idea of the format is that it's a multi-frame/multi-layer compressed image format. The format allows for more than one frame in a single file, used for animations, 2D rotatable avatars, etc.
What we know so far is that the "magic" or header of the format always starts the same:
4C 7A 48 32 or in ASCII: "LvH2"
The '2' could possibly be used as a version or compression-type byte, but we know every single CMP file uses these as it's first 4 bytes and will refuse to be read as otherwise.
Additionally, the 5th byte is required: C6. The 5th byte in Windows is C6 while in Mac format, it's 22. Refer to Sypha's post below:
Spoiler: Syphas work
So I did a little work on this a while back. I didn't get very far, probably because of a lack of experience with image formats, but this is what I managed to figure out. Please correct me if I'm wrong with anything, these notes are at least two years old, probably closer to four.
First 4 bytes are constant, like Wirla said.
4C 7A 48 32. Next two bytes are either
0680,
0280,
4680, and according to Wirla with some very old CMP files use
C680 and
2280. I don't have notes on what this means.
Next two bytes are the number of vertical pixels. After that are the number of horizontal pixels.
Then what seems to be the loss factor, from 0 to 99. Again, two bytes. I have a question mark by this one.
Next two bytes are the number of colors.
Finally is the reduced color palette number. Again, two bytes. I really don't remember what this means. A note says 1C if pallette is standard, 2X if not. Not sure what X was.
Not so verbose:
σ - Signature (sigma)
φ - ??? (phi)
Pv - Vertical Pixels
Ph - Horizontal Pixels
κ - Loss Factor? (kappa)
C - Number of Colors
δ - Reduced Color Palette Number (delta)
http://kensmom.net/beam1.pngFrom the CompImg help, we can determine a multitude of information.
Spoiler: CompImg Help
CompImg Version 0.68 (Win32)
Copyright (C) 1993-95 Knowledge Adventure, Inc. All Rights Reserved
Usage: compimg <image_filespec or +image_list> {...} {options}
Compress image file(s) (any format) to paletted compressed image file(s).
Output name, by default, will be input file name, with .im# extension,
where # is lossiness factor. Pal files will ALWAYS be named with
.pa# extension, where # is 0 through 8, for 1, 2, 4, 8, ..., 256 colors.
Options [defaults shown in brackets]:
-eExt Output extension (without leading '.').
-pairs Use first filename as input name, next as output name, and so on.
-c# Colors in full resolution palette (between 2 and 256) [64].
-r# Colors in reduced resolution palette (power of 2, <= 256) [8].
-r0 Do not include reduced resolution palette.
-fName Name of fixed palette file [fixed.pa5].
-f0 Do not include fixed resolution palette.
-mName Create a movie file from the specified images, output to Name.
-MName Create a mouse-movie from a single .rel file, or several images
and no .rel file (internal .rel file); output to Name.
-ow Compress to Microsoft Windows orientation output file(s).
-om Compress to Apple Macintosh orientation output file(s).
-po{Name} Compute common palette for all images {write to Name}.
-pOName Compute common palette, write to Name, then stop.
-piName Use specified palette file for all images.
-pt Temporary palettes; don't read/write palettes from/to disk.
-pk Keep unused colors in the palette.
-px Don't include any palette information in output file(s).
-pc Don't include cuts (for synthesizing 2X zooms) in output file(s).
-pf Force palette generation, even if input image is paletted.
-pm# Memory & time used by palette generation: 0 (small & fast) to 3 [2].
-pn Instead of palette, include name of -pi palette file in image or movie.
-pw Use the 20 Windows fixed colors for the entire palette.
-d{#} Dither image (Sierra Lite), optional # is maximum dither error [8].
-da{#} Use alternate ditherer: 1=Floyd, 2=Stucki, 3=Jarvis, 4=Burkes [1].
-Xd# Scale image width to specified # of pixels.
-Yd# Scale image height to specified # of pixels.
-Go# Gamma correct image (# is floating point new gamma value).
-C#,#,#,# Crop: specify left,top,right, and bottom # of pixels to remove.
-CLName Crop images using left,top,right,bottom in named listing file.
-s#,#,# Set scale of image; x,y pixels/meter, exponent (base 2).
-l#{,#} Loss factors, higher numbers -> more loss; range 0 to 99 [8,6].
-L Allow loss-less blocks. Combine with -l0,0 for total losslessness.
-LL1 Use loss-less compression for first image of a movie or animation.
-t{#,#} Optional x,y of transparent pixel; -1 -> right/bottom [0,0].
-tc#,#,# Use transparency, but directly specify R,G,B of transparent pixel.
-td# Allow pixels to vary by # (sq. distance) and still be transparent [0].
-tC{Name} Auto. crop transparent pixels from edges of images/movies.
Optional name is output file to save cropping information.
-D Conserve disk space by reading/converting images, when necessary, twice.
-h#,# X and Y coordinate of hot-spot (only used when making a cursor).
-fps# Frames per second (movies only) [6].
-mpf# Milliseconds per frame (instead of -fps) [166].
-delay# Sound delay (in frames) (movies only) [0].
-flip Make a page-flipped movie.
-vc{#} Vary movie loss so no more than % of CPU used by pixels [50].
-vr{#} Drop images so no more than % of CPU used by pixels [50].
-vs# Set video speed (in 1000's pixels/sec) for -vc/-vr options [1000].
-vl#,# Increase loss factors by #'s when too many pixels change [1.00,1.00]
-io Also produce 6 intermediate movie files (.mi0-5) for merging.
-iO Only produce 6 intermediate movie files (.mi0-5) for merging.
-ii Merge a list of intermediate movie files (extensions ignored).
-T{Dir} Use TMP then TEMP environment vars {or Dir} for temporary files.
-qBits Inverse palette precision for movie/mouse movie (0, 5, 6, or 7) [0].
-ace Use common Accomplish options: -ow -pk -pf -pc -f0 -ecmp/-emov.
-tape Read tar files from ASPI/SCSI tape drive (use TAPEID variable).
-tapeid#:#:# Tape drive cntrlr:scsiid:unit instead of TAPEID environ. var.
-tar# Position tape to tar archive set # [1].
-tile#,# Break images into pieces no bigger than X by Y; produce .til file.
-a{#} Use animation compression for movies, # is change threshold [0].
-wca Always close window when finished (Windows version).
-wcs Close window when finished, if successful (Windows version).
-@OptionFile Read additional options from the specified file.
- It was made in-house by Knowledge Adventure Inc, which makes sense since Worlds Inc originally came from them, even being known as "Knowledge Adventure Worlds Inc."
- This tool has existed or atleast been copyrighted since 1993.
- Ties to the Accomplish engine?
- Accomplish was the name of the engine Worlds Chat and Worlds Chat Gold used, and it was developed by Worlds for Starbright.
- Possible different types due to a Windows argument and a Mac argument?
- Either supports being a "movie" or is just a term they use to signify more than one frame.
- A few tape arguments?
There is a whole lot to digest in that help menu, some things we just don't understand, others confusing. Most users only use the generic spread around options they can understand.
Additionally, we know that it's very likely to be a compressed variant of the BMP format, which none is documented. The references in the documentation of Worlds to "Compressed Bitmap" and the requirement for the input files to be a BMP really says all there can be to make this conclusion. Perhaps some digging into that file format can lead down a path.
The start year interests me though. Worlds Inc. was founded in 1994, and the history between Starbright Worlds and then is not quite told in full. So much information is just full of gaps in the time frame and it makes it hard to understand. Perhaps if we got the entire story and history, we could find a clue that could bring us closer to understanding the format. This year though might mean it was developed before the engine, or the project was in the works for a year prior than what was thought. Possibly apart of some Knowledge Adventure games?
There is also a tool called CmpView, which is used to display the files. This has little new information, but it's helpful to look at still.
Spoiler: CmpView About
CmpView 1.2
By Lee Hasiuk (leeh@worlds.net)
Copyright (c) 1996 Worlds, Inc.
All Rights Reserved.
I have attempted to find Lee Hasiuk, but could not get any concrete details.
Last, but certainly not least, we have a BBC documentary.
https://youtu.be/j7f370kVRUU?t=794At the time set above, Worlds is talked about. Among a few details that are like WOW, we see Starbright Worlds a little later in the video. Starbright Worlds... has walking animations for the avatars. Now this could be a neat trick utilizing some cool programming to make it seem like it's got actual animations, but remember that this is BEFORE Worlds Chat. There was no Shaper, or Animate Actions at the time. The custom tools and utilities for world creation had to be made CUSTOM and from scratch. That means they had to specifically program these avatars to have walk animations with this trick if so, which would be a tad too much effort necessary. I am not sure if the footage is actually using real users too, or if they are "NPCs". The fact is, walking animations DO EXIST or are possible. The argument descriptions in CompImg seem to suggest it may be possible to create this, but we need much experimenting and it might not even be the case. What's interesting is that one of the "woody" avatars from a variation of WCJ has what seems to be a single "animation-frame" of woody walking, something not seen before.
Hopefully, we get the history, the information, and details about this mysterious file format. Maybe someday, you'll be exporting avatars in GIMP. Please, feel free to share ANY of your findings, your discoveries, or anything at all that you know of that'll help. And ask questions, as questions give us goals to answer!
Download links:CompImg v0.58 (Win16)CompImg v0.68 (Win32)CmpView 1.2NOTE: We currently have CompImg 0.68, which is in English, but there exists an older version in the Japanese language for Win16. I know I saw this on a Japanese Worlds page at some point but I can no longer find it. If anybody has it or know where to find it, let me know!