September 27th, 2011, 16:23
Posts: 21
Threads: 0
Joined: Jan 2010
can you cope with the C++? As I see your LBX tool is developed for the .NET framework (WinForms with C#/VB.NET).
Have looked into the OpenXCOM code - nothing fancy (SDL), but a return from the .NET world... that would be painfull till the things shake down
Zeraan Wrote: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.
September 27th, 2011, 16:30
Posts: 151
Threads: 10
Joined: Nov 2010
Doomk Wrote:can you cope with the C++? As I see your LBX tool is developed for the .NET framework (WinForms with C#/VB.NET).
Have looked into the OpenXCOM code - nothing fancy (SDL), but a return from the .NET world... that would be painfull till the things shake down
Actually, I was thinking that with VM's permission, I would use his reMoM code as a base for MoO. It's in C#, uses OpenGL, and have LBX handling code. However, the LBX format for MoM is slightly different from MoO, so I'm trying to figure out the rest of the image format (repeated pixels, skipping, etc) so it'll all load correctly. But when that's done, I will have access to most of the graphics for MoO, which means I can create a new version of MoO using the same graphics. The rest of the graphics are in FONTS.LBX (cursors), which have a different format than the image LBX files.
The biggest challenge will be replicating the AI, combat, and spying, since it'll require dissecting of the original .exe file to see how they exactly work. The rest I think I can handle, after I'm done with Beyond Beyaan.
September 27th, 2011, 17:58
Posts: 151
Threads: 10
Joined: Nov 2010
More progress! All images now load, but some have corruption issues, and there are some places where it's obvious that pixels are supposed to be repeated, but weren't, creating some lines in graphics. Anyone recognize this particular artwork?
I'm pretty excited about this stuff! One interesting thing is that with animation, the first frame contains the whole image, then subsequent frames overwrite only parts that need to be updated. So if we were to create new LBX files, we will have to match this format to conserve memory.
September 28th, 2011, 02:01
Posts: 21
Threads: 0
Joined: Jan 2010
it's a picture from the intro video. And video should be in smacker format ( http://www.spheriumnorth.com/orion-forum....php?t=214)
September 28th, 2011, 09:50
(This post was last modified: September 28th, 2011, 10:30 by Zeraan.)
Posts: 151
Threads: 10
Joined: Nov 2010
Doomk Wrote:it's a picture from the intro video. And video should be in smacker format (http://www.spheriumnorth.com/orion-forum....php?t=214)
That's for MoO 2. The intro video is split into separate files, and they're all readable in the same format as the ships, so my guess is that there's no actual video, just animations. I've looked through all the LBX files, and the graphics always shows up (albeit a bit corrupted and wrong colors), so that means there's just one graphic format for MoO 1.
I've got palette loaded from FONTS.LBX, but it still don't look correct, I'm tweaking it around to see if I can hit the magic colors.
Edit: I've got your PMs, and did research on them. It seems like most people did their research with MoO 2, but not MoO 1. Some that actually researched MoO 1 didn't get as far as I did. So it looks like I'm on my own from now on regarding LBX files. But I'm confident that I will be able to crack the LBX format and create an application for modifying the graphics for MoO.
September 28th, 2011, 14:01
Posts: 151
Threads: 10
Joined: Nov 2010
I've fixed one more thing that was messing up the image layout, the repeating pixel data! I also loaded in palette from FONTS.LBX, and you can see that the end result is pretty close to in-game look:
It seems like there's internal palettes that changes certain range of colors, so I'll need to find where they are stored, and implement loading of that, then all the colors will be correct. Also, some images don't quite match the expected format, like this one:
The above is your planet's management screen in case you have problems seeing what it is (Notice that the colors are correct!). When those two problems are resolved, that means I've fully cracked the image storing format for MoO!
September 29th, 2011, 11:44
Posts: 151
Threads: 10
Joined: Nov 2010
I've implemented internal palettes! The result can be seen here:
There's still some bugs to fix, then I'll upload it so you guys can download and use it. I will also include the source code so you can see the LBX format from my code. It will just display the images for now. I plan on adding ability to extract images to .PNG files (PNG because it have transparency), so you can edit the images. Importing the images will be a bit tricky, and I think the best solution is to just create a new LBX file instead of trying to alter the existing one.
The reason for a new LBX file is that I will have to create a header with the correct info, such as reference addresses and number of files. If images are larger or smaller, then I'd have to update all the reference addresses. Also, if you're editing an animation, the importer will have to compare the base frame and the next frame (I'm not sure if it uses the base frame, or just draws the frame on top of previous without clearing the screen), and remove duplicate information. It would also need to compress image data, so if a vertical column of pixels have the same color, it'd be compressed to two bytes, number of pixels and color palette number.
I think this will be doable. Once you understand how LBX format works, it's pretty simple. Of course, that might be due to me being a geek and being able to read hex data
September 29th, 2011, 13:13
Posts: 151
Threads: 10
Joined: Nov 2010
I investigated why some images are skewed, and looked at my loading routine. Everything looks correct, so why wasn't it working? Then when I compared the skewed images, I noticed that some are skewed in a more angled manner than others, and noticed that those has odd-sized widths. I realized that maybe it's not my code, but how bitmap handles stuff internally, and it might have issues with widths that are not multiplies of 4.
So I added "padding" on right so the image would always be divisible by 4, and presto! It fixed the problem!
I found another problem with internal color palettes, and fixed it. Now most everything is loaded correctly and rendered correctly in correct colors (try saying that three times! )
There are some odd pictures (particularly in LANDING.LBX) that don't seem to work with external palette, maybe there's another palette that it uses? I can't find it. But anyway, here's the program, complete with source code (the program is in /bin/debug/ folder), have fun exploring the MoO's graphics!
LBXManager.zip
Edit: This wouldn't have been possible if it wasn't for many people's research in LBX format (VM's reMoM project, the MoO 2 blogs, etc). All I did was to take their research and find what's different with MoO's format.
September 29th, 2011, 14:17
Posts: 58
Threads: 2
Joined: Sep 2011
Wow, teach me to turn away for a bit - you move pretty quickly Zeraan!
Going to read through this tonight and see where you are.
September 29th, 2011, 18:25
Posts: 151
Threads: 10
Joined: Nov 2010
The download above is obsolete already
I figured out how animation works in MoO. Instead of regular frame by frame display like in most games today, it starts by drawing the first frame, then the second frame on top of it, and so forth until it reaches the current frame. It relies on the fact that the screen isn't cleared on drawing each frame. It's good for saving memory, but is hard to mod.
So I've updated the bitmap loading so that it will load all the frames up to the current frame, making for a clearer image viewing. I also changed the buttons to "Import Images" and "Export Images". Export Images is implemented, it will prompt you for a folder location, then export all the images from the LBX file that you have loaded. Each frame is saved out individually.
Latest version here: LBXManager
Next up is the "Import Images". It'll have to do some heavy processing before the images are actually loaded. First, it'll have to compare each frame to the previous frame, and only keep pixels that are different (along with compression methods such as repeating pixels), as well as compare the color palette to the original. Then it'll have to create a byte array for each frame, containing the compressed and stripped frame data. Also a byte array for color palette if it's different from the external palette.
Then it'll have to create headers for each file in beginning of LBX file, as well as calculate the file offsets so that it would load correctly in MoO. Once that's done, each file will need to be processed because it have its own "mini-header" that depends on the file's location within LBX, then load the byte arrays for each frame as well as internal palette if any. Once that's done, it's all loaded and saved out to an LBX file. I might do that over this weekend, I'm not sure if i can do the palette thing, but I think I can do the rest of the stuff described above.
Then it's just an matter of "Export Image", modifying the images, then "Import Image" them back into, and replace the LBX file with the new one.
|