September 22nd, 2011, 11:31
Posts: 151
Threads: 10
Joined: Nov 2010
This is what I have so far:
http://i18.photobucket.com/albums/b102/Zeraan/lbx.png
Right now, it just loads the text, not bitmap. It don't save changes yet, will work on that last. It have problems with displaying special characters, so I replaced them with "-".
I have a question, as you can see from the screenshot, there are "placeholder" characters where the game replaces the character with numbers or names (They're just - right now). Are those spots hardcoded in the game (meaning that special character will need to be at that exact spot?), or does the game actually look for those special characters?
September 22nd, 2011, 12:06
(This post was last modified: September 22nd, 2011, 12:47 by Zeraan.)
Posts: 151
Threads: 10
Joined: Nov 2010
I realized that I will also need color palette from MoO 1. For example, what is the color value of "25"? If I remember correctly, MoO 1 uses 256 colors, so I'll need the color value of all 256 colors. Kyrub, can you provide that information?
Edit: I did some digging, and found this link:
http://masteroforion2.blogspot.com/
If you scroll down, he describes how color palettes work in MoO 2. I'm wondering if it's the same system as in MoO 1? Or is there just one universal color palette?
September 23rd, 2011, 10:17
Posts: 151
Threads: 10
Joined: Nov 2010
I digged around in "BACKGRND.LBX" since I know for sure that it contain images, to see if I can figure out the image format. I got good news, it's pretty much how that blog described the image encoding for MoO 2. This is the first image file in the BACKGRND.LBX:
The area in red denotes the image width. (40 hex) + ((01 hex) * 256) = 320
The area in green denotes the image height. (C8 hex) + ((00 hex) * 256) = 200
So we can see that this image is 320x200 pixels, which makes sense because I knew MoO 1 had to use one of the two formats, 320x200 or 320x240.
The area in yellow is the "frames" of the image. In this case, it's just 1 frame. The rest of the highlighted image is information on where each frame starts/end, frame delay between each frames, and other parameters.
This is enough information for me to load in an image. I don't need to guess the image's width/height/frames. Now, if I can just find out where the color palettes are stored...
September 25th, 2011, 16:56
Posts: 901
Threads: 28
Joined: Oct 2008
Nice. Do you need any help from me with the palettes?
All I can try is try to look in the code for subroutines that load palettes. My problem is, that I basically avoid all graphics data in program analysis. So I know next to nothing about palettes. - I remember that I was checking numbers representing colors when trying to change the interface, though. That's about all. Ahem.
September 26th, 2011, 10:22
Posts: 151
Threads: 10
Joined: Nov 2010
kyrub Wrote:Nice. Do you need any help from me with the palettes?
All I can try is try to look in the code for subroutines that load palettes. My problem is, that I basically avoid all graphics data in program analysis. So I know next to nothing about palettes. - I remember that I was checking numbers representing colors when trying to change the interface, though. That's about all. Ahem.
What I need to know is which files contains palettes, or if it's hardcoded inside the game itself.
Also, if you could find the subroutine that loads in images, could you figure out the encoding pattern? What I need to know is the areas marked with light brown.
The yellow is the number of frames, and at end of this "header", there are frame offsets (shaded in light and dark grey). There are frames + 1 offsets, so there's two in this file. Those offsets are relative to the beginning of the file. It looks like every frame starts with "01" as highlighted in purple.
So far so good, then I found out that the method it uses for storing images isn't straightforward. This is basically a compressed image, where all the "unused pixels" are stripped out. So it actually just points to the next relevant pixel, then say "There will be 12 pixels", so you need to load in 12 pixels at the appropriate x/y offset, then go to the next sequence.
I noticed a pattern in the file. It seems like every sequence starts with "80 XX" (I've shaded some with light brown), I'm not sure what this is actually used for, I need to know if 80 is just a marker, or if it's used for something (My gut feeling is that 80 is just a marker, since it's in other files as well). Also, what is the next number after 80 (in this, there's 10, 12, and 14, and so forth) for? My best guess is that it marks amount I need to move in X position before next sequence starts. I do know that the next two bytes are used for telling the amount of pixels.
So for example, 80 10 0E 00 (the first sequence) tells me that I need to load 14 pixels. If you count the bytes between that and the next sequence's header, you can see 14 bytes.
I think if I understand the LBX format well enough, I could make my program be able to create a new LBX file dynamically, with all the correct headers, and MoO 1 would be able to load it correctly. This would mean that we won't be restricted to modifying pixels, we could add or remove pixels, meaning complete new images.
September 26th, 2011, 10:37
Posts: 151
Threads: 10
Joined: Nov 2010
Arg, while trying to figure out the number after 80, I found something that broke the pattern:
If you look at the "80 XX" header before the problem, you can see it says 8 pixels. But at that position after the 8 pixels, it's not "80 XX", it's something else. I'll try and figure this out, but if you can look and find out the LBX loading routine, this will help me out a lot.
September 26th, 2011, 13:55
(This post was last modified: September 26th, 2011, 15:49 by Zeraan.)
Posts: 151
Threads: 10
Joined: Nov 2010
I looked at MoM forums to see if someone has cracked the code for LBX, and found a re-make in progress. I looked at their LBX loading code, and I think I understand the format better. However, MoO 1's LBX format is different from MoM, so I'll have to dig around some more. But this helped me understand the format better!
While thinking about the LBX format, I was struck by a crazy idea. Kyrub, you've complained about the restricted space/memory of being able to fix MoO and the AI for it. What if we work together to create a re-write of MoO 1, using the original data files, combining your knowledge of how MoO 1 works internally, and my experience in writing Beyond Beyaan and LBX research?
I know, it's a big task, but this would give you the ability to write advanced AI for the game. And I am capable of creating 4x games, as shown in my signature
September 26th, 2011, 15:58
Posts: 151
Threads: 10
Joined: Nov 2010
Ugh, I feel like I'm spamming this thread
I just wanted to let you know that I've found the color palette for MoO 1. It's located in FONTS.LBX, in third file. I think it's the only palette *crossing fingers*.
I also discovered that in .LBX files, it do actually say what kind of file it is. The 7th and 8th bytes into this file is a 16 bit integer that contains one of the five values:
0 - images
1 - sounds
2 - palette/other data (only FONTS.LBX is of this type)
3 - help? (Only HELP.LBX is of this type)
5 - text
Then at 200 (hex) bytes, it start listing filenames, which is very handy in understanding the LBX files. I didn't realize that they were file names until I decided to count the list of names and compare it to the count of files in a LBX, and they were the same!
September 27th, 2011, 11:04
Posts: 21
Threads: 0
Joined: Jan 2010
oh, you mean to follow the OpenXCom way - I would love to see that happen... but that would require devoted developers (the more the better), especially in the UI (graphics/sound) field ... and not to die in the midway (as projectxenocide & many more) due to the lack of manpower Although one good developer with required skills would be enough to start ball rolling
Zeraan Wrote:While thinking about the LBX format, I was struck by a crazy idea. Kyrub, you've complained about the restricted space/memory of being able to fix MoO and the AI for it. What if we work together to create a re-write of MoO 1, using the original data files, combining your knowledge of how MoO 1 works internally, and my experience in writing Beyond Beyaan and LBX research?
I know, it's a big task, but this would give you the ability to write advanced AI for the game. And I am capable of creating 4x games, as shown in my signature
September 27th, 2011, 14:17
Posts: 151
Threads: 10
Joined: Nov 2010
This depends on if Kyrub's willing to provide details on how things work internally (spying, etc). I can do the UI and artwork stuff, but it's all for naught if I can't copy exactly how it operates underneath.
Speaking of artwork, I've made some progress in loading LBX images! I've taken a screenshot of the same ship in MoO for comparision:
It works kinda, it throws an exception with some images, so my image loading isn't fully working yet. Also, I need to fix the palette so that it'd use the right colors. But this is encouraging!
|