Page 1 of 1

Posted: Wed Nov 16, 2005 8:01 am
by Industry
So, I now understand why the PC collection tool, Tahoe, does nothing but import and export the color maps and bitmaps. I have been working on an Amber clone for days and I haven't even gotten that far. And the color table and bitmap tables are the simple stuff, 256 RGBA colors right where the header says they should be, nice; RLE bitmaps (339 for the warrior tag) again right where the header says they should be, okay.

But the REST of the collection tags are hell.
Hue Changes, 128 bytes of data the first 64 bytes of which is the name:

00009a0: 4875 6520 4368 616e 6765 2031 0000 0000 Hue Change 1....
00009b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00009c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00009d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00009e0: 4000 6aab 0000 0000 0000 0000 0000 0000 @.j.............
00009f0: 0000 0000 0000 0040 0081 e3cd 5e02 e30b .......@....^...
0000a00: 0001 0000 0000 5555 0001 0000 0000 0000 ......UU........
0000a10: e8f4 ae3e 5632 0000 0100 0000 0000 0000 ...>V2..........

What the heck are the next 64 bytes?

Then we have a mystery table of 64-byte entries, like these (the first 4 from the warrior tag):
0000aa0: 0000 0000 0000 ffff 0000 0000 0017 003b ...............;
0000ab0: 0000 0000 0000 0000 0000 0000 0030 0000 .............0..
0000ac0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000ad0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000ae0: 0000 0000 0000 ffff 0000 0000 0019 003b ...............;
0000af0: 0000 0000 0000 0000 0000 0000 0038 0000 .............8..
0000b00: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000b10: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000b20: 0000 0000 0000 ffff 0000 0000 001b 003b ...............;
0000b30: 0000 0000 0000 0000 0000 0000 0040 0000 .............@..
0000b40: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000b50: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000b60: 0000 0000 0000 ffff 0000 0000 0021 003a .............!.:
0000b70: 0000 0000 0000 0000 0000 0000 0031 0000 .............1..
0000b80: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000b90: 0000 0000 0000 0000 0000 0000 0000 0000 ................

The only thing I can figure out from these is bytes 29-30 seem to be a unique index number, meaning that of the 432 entries in this table in the warrior tag, each one of them was numbered in these 2 bytes from 1-432 (in hex, or course 1-1b0 ). To make it extra confusing though they weren't in this order. Now this tag has only (only?!) 339 bitmaps so what the heck could these be? Anyone? Buehler?

Ah, then we have the sequence table. Starts out simple enough since for the warrior tag there are only 14 sequences. And hey, look, at the right offset we find the first one:
00076a0: 626c 6f63 6b00 0000 0000 0000 0000 0000 block...........
00076b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00076c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00076d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00076e0: 0000 7f20 0000 00fa 072e bee0 0000 0000 ... ............
00076f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0007700: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0007710: 0100 0087 00cc 0014 0000 0000 0000 0000 ................

We have 64-bytes for the name of the sequence, and then what? Where is the list of bitmaps? There's only 64-bytes left in this and most of it's zeroes, there's no way that there can be a list of bitmaps, sounds tag references and whatever else in here. Oh wait, there is a suspicious looking offset/length combo in there... ARGH! These aren't the actual sequences, these are references to the actual sequences!

I hate you Bungie. I gonna go look at the open source Marathon 2 code and see if Myth inherited enough from your earlier games to make this stuff readable. Of course, if you were any other company even that would be impossible...

Posted: Wed Nov 16, 2005 9:25 am
by Industry
Okay, looking at the Marathon 2 code, maybe the mystery table is what the Marathon collection_definition.h calls the low level shape definition. The stuff that keeps the bitmaps from being under ground or up in the air maybe, and I guess its used for pathfinding too. Holy cow, this game is complex.

Posted: Wed Nov 16, 2005 1:10 pm
by Killswitch
I can shed a little light on hue changes. Each hue tag entry (128 bytes) goes something like this:

//my index numbers are zero based
0-62 = hue change name (yes it's 63 bytes unlike other Myth tag names of 32)
63 = null byte (00) for end of name

64-65 = hue start (integer, more on this later)
66-67 = hue end
68-99 = unknown - spacer mb? weird place for 32 empty bytes
100-101 = minimum saturation (fixed number)
102-103 = hue middle (kind of like a 'bias' between the hue start and hue end)
104-105 = "use as..." flag (0=Normal hue change, 1=primary hue change, 2=secondary)
106-111 = unknown - another spacer?

112-113 = replacement color red (for preview in editing app)
114-115 = replacement color green
116-117 = replacement color blue
118 = spacer (00)
119 = reverse hue change flag (either 1 or 0) - use opposite side of the spectrum
120 = 'use this hue change' flag (either 1 or 0)
121-127 = spacer?


******************

About Hue start & hue end
Normally hues are defined as a degree (ie 262°). To translate the integer to the degree, it's quite simple. Take the int, divide by 65535 (FFFF), then multiply that decimal by 360 to get the degree.

deg=360*( int / 65535 )




I hope this helps and I didn't already cover what you know.

Killswitch

Posted: Thu Nov 17, 2005 4:38 am
by Industry
Oh, it definitely helps, and I certainly didn't already know it. I knew that the hues where defined by degrees from the screenshots you sent but I couldn't figure out where they were stored or how they were converted into hex. One or the other would have helped, but I'll take both!

Thanks.

Posted: Thu Nov 17, 2005 7:21 pm
by haravikk
Sequences store a whole ton of crap besides just which bitmaps to use, so I'm gonna be surprised if 64 bytes cuts it.

They contain the following (in rough order):
BASIC INFO
Sequence name (long string as you know)
Frames
Views
Transition per frame (fade from one frame to another. These three are all short numbers).

Method (Normal, Fade Out, Fade In)
Use Mirroring (flag) (half as many views plus 1 where missing views are horizontal flips of their opposite. For example 225º would be 135º flipped)
No rotation (flag)

EXTRA INFO
Key frame (the frame on which an attack is actually performed)
Loop frame (frame on which a loop begins)
First sound (sound to play on start of sequence)
Key sound (sound to play on key frame)
Last sound (sound to play on end of sequence)
Indexes (I have no idea what these do, there appears to be one for each sound) but they server no known purpose.
Ticks per frame (short number) (fairly self explantory, how many ticks each frame last for before going to the next)

BASIC FRAME INFO
Transparent (flag) (does this frame treat colour #3 in it's colour table as transparent (or #2 if you go from #0))
Horizontal Mirroring (flag) (flip horizontally)
Vertical Mirroring (flag) (flip vertically)
Texture (flag) (if in RAW format, can be used as texture)
Minimum/Maximum light intensity (decimal fractions, not a clue)
Each frame must also have a pointer to the bitmap it uses (these must be uniquely identified somehow).

EXTRA FRAME INFORMATION
Reg point (where in relation to the ground the image should be positioned (higher up, lower down, off centre?)
Key point (if an attack is performed on this frame, where does it come from?)

SHADOWS
Shadows are also sequence related, and there is one per frame, but not per view (so if your animation has 8 views and 5 frames, it will have 40 individual frames, but only 5 shadows). These also have their own reg point.



That's a ton of data to try and pick through and I don't envy you for having to do it, but I respect your attempts to try, and wish you good luck!

Posted: Sun Nov 20, 2005 3:39 pm
by Gleep
Wasn't Baak trying to make a PC version of Amber also? Talking to him may shed some more light on your project. I for one would love to use a better PC project than Tahoe.

Good Luck!

Posted: Sun Nov 20, 2005 4:03 pm
by haravikk
I'm under the impression there are 3 or 4 doing it, you all should work together, get it done quicker maybe =)

Posted: Mon Nov 21, 2005 6:09 am
by Baak
I'm not working on a PC version of Amber - I dug into it recently when trying to tweak a collection from the PC and ran into the same mysterious fog Industry encountered at first... Then I ran straight for the hills!

Melekor is working on a PC Amber - and you're right, all you guys who know the ins and outs of collections should pool your selves together (heh) and whip something out!


I've got a zillion other Myth projects just waiting to be finished up though - they're coming, I swear! - including RDF 5.1 which we just finished the final playtesting weekend on... :D




Edited By Baak on 1132571436