Page 1 of 2
Posted: Tue Jul 05, 2005 4:17 am
by Industry
Is there any chance that one of you Amber whizzes could take screenshots of Amber next time you are putting a unit together? Since I already have like 30 computers, I am loathe to spend $50 on an old Mac (and $100 to get it shipped up to me in Alaska) only so I can make sure that what I am working on is interface compatible with the original.
Thanks,
Industry
P.S. At this point I am convinced that the only reason why Amber isn't open source is because its initial code came from someone in Bungie who wasn't supposed to release it into the wild. Vodi is welcome to tell me to go to hell though.
Posted: Thu Jul 07, 2005 11:46 am
by haravikk
I'm not quite sure what you're asking for here, Amber was made entirely by a third party (Vista), mainly Vodi though I believe some others contributed. It was never made open-source because they were long-gone by the time OS X was really kicking off and Myth was being updated for it, which is really unfortunate 
Amber is purely for making and editing collection (graphics) for units/scenery etc. in Myth 2, I don't see what you mean by compitable interface, as it's a very seperate program for something no other program currently does. It is fairly intuitive though and once you get the hang of a few basic things (me and various others are more than happy to help) then it's really easy to use.
I'll get some screenshots for you when I have a bit of spare time later, but I'm not really sure what they will show you, since it's something you use, not look at 
Posted: Thu Jul 07, 2005 2:00 pm
by Graydon
I believe he's making Amber for PC Hara 
Posted: Fri Jul 08, 2005 12:13 am
by Industry
Graydon is right. I am trying to make a new Amber, but I am using Perl 5 so it should work on a PC, linux, and OS X also. I know Amber can be used to arrange the sequences, and that you can mark frames for sound. I was able to extract the text of the menus from the binary, but I want to make something that has the same (mostly) interface as the existing Amber. I don't want to end up adding a hotkey for Quiting that in the original was for Saving. Also screenshots will help me figure out what else I should expect it to do.
I personally would like to feed it a Poser/Blender/OpenInventor Model and let the tool set up the sequences, but for now I'll be happy if it works the same as Amber 2b5 on a PC or Linux box. So I say, nay I plead, if you are working on a new unit anyway, please take a few screenshots along the way, I beg you.
Posted: Sat Jul 09, 2005 12:37 pm
by Melekor
Here you go: http://www.projectmagma.net/~melekor/amber_screens/
If you need any more help please contact me. Good luck on your project!
Posted: Sun Jul 10, 2005 3:17 am
by Industry
Wow, these are great! Holy cow, Amber is as complex as Fear itself!
Oy.
Thanks, Melekor
Posted: Mon Jul 11, 2005 12:17 am
by Graydon
Theres also the whole thing with Bitmap masks.. I've got no idea how amber actually handles them, since you can never actually view the files in amber. I just know that the bitmaps that are to use masks have to be 'replaced' by the masking bitmap. So say you have Tree v2, and you wish to make some of its leaves transparent... You've already created your black and white alpha mask image. In amber you select Tree v2 bitmap, and Replace Bitmap from the menu. Select your mask, and as you're importing you select 'Alpha Mask' instead of 'Colour Bitmap'. This successfully imports and masks that bitmap. The effects of the mask cannot be checked until you're in game however :/ A function that can 'turn masking on' would be cool...
Posted: Mon Jul 11, 2005 4:46 am
by haravikk
Yeah, if you could somehow add in a visual of a mask somewhere then that would rock, since otherwise you have to constantly tweak and switch to Myth/Loathing to see if it worked!
Posted: Tue Jul 12, 2005 12:39 am
by Industry
So, you are replacing the Alpha Mask on the bitmap. I thought that most Myth bitmaps/billboards/whatever had no Alpha Channel? A feature to "turn on masking" should be simple enough to implement (once I get my mind around the collection data).
Anybody know what the numbers in the parentheses after the bitmap name in some unit sequences refers to? Is it previous and next bitmap in that particular sequence?
Posted: Tue Jul 12, 2005 12:33 pm
by Melekor
That list box displays the bitmap names as they are in the collection file. Those numbers you are seeing were part of the bungie naming convention for the bitmaps. (possibly auto-named by the Extractor, bungie's collection tool?) If you look closely, you can see that the 2 numbers in the parenthesis are the width and height of the bitmap(compare to the next column) . If you open a custom collection made in amber from a random plugin not made by bungie, you won't see those kind of numbers. IIRC, amber supports renaming the bitmaps.
Posted: Tue Jul 12, 2005 1:32 pm
by haravikk
Industry, all Myth bitmaps have an alpha channel, for most this will be plain white, however for others it may contain information. I believe these are all stored as a single image in the collection (an alpha 'plate').
Posted: Wed Jul 13, 2005 2:35 am
by Industry
Melekor, I recognized the names from hand editing collections, just never knew what the numbers meant, and my guess kept me from looking right at the answer in the screenshots you made. Duh. So I take it then that Myth (and Amber) can also handle 16 bit color depths? Once again. I learn something new. I thought it was stuck with multiple 8 bit color tables.
Haravikk, that makes sense, plain white would be almost the same as having none at all. I'll have to see where the collections put the bitmap specific alpha maps, probably another pile of data with offset references in the actual bitmaps.
So far, (This is from memory as I am away from my dev enviroment and a useable Myth CD) the collections have tables for:
bitmaps/images definitions
bitmaps/images data
sequences
shadows
and I'm guessing alpha channels.
How wide is the alpha channel? 1 bit? 8 bit? 16?
Posted: Tue Jul 19, 2005 3:48 am
by Industry
Okay, so from looking at the ghol collection from Ephor:
Tag Header
Some Stuff, probably the color table.
The Sequence Table:
theSequenceName (64bits)
theSequenceOffset (4 bits)
theSequenceLength (4 bits)
unused (56 bits)
Sequences:
bunch of stuff including sounds
Bitmap Table:
theBitmapName (64bits)
theBitmapOffset (4 bits)
theBitmapLength (4 bits)
Someother stuff (56 bits)
Bitmap Data:
the actual Run Length Encoded Bitmap Data.
Not sure yet how the Color table defines colors, or how the bitmap data references color in the color table.
Also not sure how the sequences reference the individual bitmaps, or where the shadows live, or the alpha channel.
Posted: Mon Jul 25, 2005 9:23 am
by mauglir
On a side note, Amber was based on a Bungie tool called Extractor, just as Apathy was based on the Bungie tool Vegas. Vodi and Eli were awesome programmers, but they definately weren't starting from scratch.
Posted: Mon Jul 25, 2005 10:03 pm
by Baak
Not sure yet how the Color table defines colors, or how the bitmap data references color in the color table.
I wanted to make a custom color table once upon a time that only contained the first three colors so they would remain constant and the rest would be filled in using Photoshop. I was incredibly annoyed that PS wouldn't let me edit the color table in this way, so I broke out the hex editor.
The PS .act files are simply 256 3-byte values all in a row. The 3-bytes are the good ol' RGB bytes for colors (i.e. FF FF FF for white). That's it.
As far as I know Myth bitmaps use the first byte for "transparent" (often pure blue: 00 00 FF), but I've seen other colors used. Thought the second byte was also used for something but I've never been able to confirm or deny that (it's often fuscia).
I imagine colors are simply referred to by their position in the file (00-FF, 0-255) since changing a color in the color table wreaks havoc on the same bitmap.
Dang guys, I would *really* like to be able to edit collections on my PC. I've been resorting to hacking and using Tahoe for what I can, but discovered just last weekend about the "#3 (56,64)" values in the collections meaning position and size of the bitmap. Unfortunately I couldn't easily replace a bitmap in a collection with a different *sized* bitmap, so I ended up with an entire copy of the trow collection because I couldn't create my own new collection with just one or two sequences. Sigh. Took me a long time to realize the sizing thing was the problem (read: couple of hours).
P.S. Haravikk's been a great help to me in the past when I needed to get a collection to "go through it's sequence" rather than stay static. Stuff like that is maddening for us PC'ers who can't get those unknown flags set. :;):