December 16th, 2012, 23:04
Posts: 61
Threads: 10
Joined: Dec 2012
Hi everybody. I found Master of Orion several years ago and have been playing it off and on, and recently got into it again.
Looking around on the 'net, people have generally knocked MoO for having inferior graphics, despite its quality gameplay.
My question is, have people made any attempts at modifying the graphics? I *assume* (though I haven't really looked into it) that the graphics are stored in the .lbx files, so it would be a matter of deciphering the files and figuring out what goes where, to then potentially allow for user-created images to be inserted.
Although I doubt there could be major changes, this would raise the possibility of for example making customized ship icon designs the way the user wants them, as opposed to the preset designs based on color and size. It would still be the same ships (until you change the .lbx files again) but then people could make up whatever ship theme they might want.
I looked around but haven't really found anything along this vein, such as a graphics editor, although I did find this.
Has anyone taken a look at this part of MoO?
December 20th, 2012, 20:36
(This post was last modified: December 20th, 2012, 23:06 by Vanshilar.)
Posts: 61
Threads: 10
Joined: Dec 2012
I've figured out how to extract most of the ship image files from ships.lbx and ships2.lbx. There are 6 ships for each of the 6 colors and each of the 4 sizes, so there are 144 ships overall, plus 3 more monster ships (crystal, amoeba, and guardian) making a total of 147 ships.
The only ships that weren't extracted were purple huge ships 5 and 6, because those are not stored in ships.lbx nor ships2.lbx at all. I'll have to look around to see just where their images are saved.
Below are all the player-usable ships (i.e. excluding the monster ships). These were taken directly from the .lbx files, except purple huge 6 (lower right corner) and purple huge 5 (above purple huge 6) which were added to this image manually.
Since the palette distinguishes between transparent (palette entry 0) and black (palette entry 1), the following is with the background (i.e. transparent) set to be green. The reason why this color was chosen is that there are no palette entries close to green (0 255 0), nor cyan (0 255 255), nor magenta (255 0 255), so I used green, though I could use any other color. Again, this was all taken directly from the .lbx files, except for purple huge 5 and purple huge 6 which were added manually afterwards.
The next step is to add an encoder to automatically convert a given image file to a .lbx entry, and then use it to replace the existing ships with ships of arbitrary design. I was thinking of starting with the ships from Star Control 2, but I'll have to see how it goes.
December 27th, 2012, 17:23
Posts: 151
Threads: 10
Joined: Nov 2010
(December 16th, 2012, 23:04)Vanshilar Wrote: My question is, have people made any attempts at modifying the graphics? I *assume* (though I haven't really looked into it) that the graphics are stored in the .lbx files, so it would be a matter of deciphering the files and figuring out what goes where, to then potentially allow for user-created images to be inserted.
You must have not followed Kyrub's patch thread. In it he looked for a way to change from 1.3 to 1.4 for version number in the main menu, and I decided to give it a try a year ago.
I wrote an LBX extractor program for MoO 1 graphics. I even started creating a process where it'd package the bitmaps back into an LBX, but there were some issues with the process and at the time I had other things on my plate at the time so I gave up on it. You can see my program in action in another thread: http://realmsbeyond.net/forums/showthrea...#pid181790
The latest version, which also includes the source code, can be downloaded from here (It contains my attempts at creating the "Import" which creates a new LBX file):
http://realmsbeyond.net/forums/showthrea...#pid183954
If you can fix the "Import" function so that it works correctly, let me know and share your fix so I can update the utility!
December 27th, 2012, 17:36
Posts: 151
Threads: 10
Joined: Nov 2010
Using the LBX tool, I found the missing purple ships. One is found in PLANETS.LBX (third to last file) and the last one is found in SCREENS.LBX, 8th file.
Not sure why they're placed in those files, I guess the LBX files are limited in size and file count?
December 28th, 2012, 00:21
(This post was last modified: December 28th, 2012, 00:32 by Vanshilar.)
Posts: 61
Threads: 10
Joined: Dec 2012
Yeah I briefly skimmed through that monster thread a while back, but haven't gone through it in detail yet. I'm sure there's plenty of stuff that I've missed like strategies and game mechanics. I should go through it sometime.
I've written an LBX extractor and an LBX encoder for the ship sprites. The ship I encoded is the Slylandro Probe from Star Control 2. The sprites are:
This is each of the 5 frames, separated by a single white line. The encoder will take this and convert it into LBX code. I then deleted the last ship from SHIPS.LBX (the 6th yellow huge ship) and copy-pasted the output of the encoder into SHIPS.LBX in its place manually.
It works, but it turns out that palette 0 is transparent during battle, but not when you're looking at the ships flying through space (for example, in the fleet screen); they're simply black in that case. So unfortunately it does have the effect of the ship "eating" up the stars, in this case as the ship rotates, if you're looking at the fleet screen. So it's not perfect, but I think the problem here is of how MoO draws the sprites rather than the data (i.e. LBX).
I wrote it in Matlab, since it's the only programming language I'm familiar with. The encoder uses just the sprite file above as well as MoO's palette (from FONTS.LBX) as inputs and will automatically generate the LBX code from there. I only used the "standard" coding scheme though (header byte 0) and didn't use the "compressed" coding scheme (header byte 128), where colors are encoded in "(# repeats) (color)" format when there are repeats.
I'll take a look at the LBX extractor program, I'm not familiar with C# though so it may take some poking around to see what the bugs are that you mentioned. What are the functions that the bugs may be in (i.e. which functions should I pay particular attention to)?
I can't seem to attach .lbx files here, but the Slylandro ship code is below. To insert it into SHIPS.LBX, the steps are:
1. Open up SHIPS.LBX using a hex editor
2. Delete everything from byte B7CB onward (it should start with "20 00 18 00 00 00 05")
3. Copy-paste the below code at the end of SHIPS.LBX
In theory, you should also change bytes 128-129 (in hex) from "8E BB" to "EA BE", but I haven't found any problems yet with not doing this.
This will replace the 6th yellow huge ship with the Slylandro Probe from Star Control 2. I have the Ur-Quan Dreadnought and the Chenjesu Broodhome encoded as well, but they're not as visually "interesting" as the Probe.
Code: 20
00
18
00
00
00
05
00
00
00
00
00
00
00
00
00
00
00
2A
00
00
00
4E
01
00
00
BF
02
00
00
3E
04
00
00
A8
05
00
00
1F
07
00
00
01
FF
FF
FF
FF
00
04
02
08
C1
C1
00
08
06
06
C0
C1
C3
C3
C1
C0
00
0A
08
05
C0
C2
C1
C1
C1
C1
C2
C0
00
0A
08
05
C1
C1
25
41
41
25
C1
C1
00
0C
0A
04
C1
C3
C0
43
44
43
41
C0
C3
C1
00
0C
0A
04
C1
C4
C1
45
8D
4D
42
C1
C4
C1
00
0C
0A
04
C0
C2
C0
46
86
06
43
C0
C2
C0
00
0A
08
05
C1
C1
25
46
44
25
C1
C1
00
0C
0A
05
C0
C2
C1
C1
C1
06
C2
C1
C1
C1
00
0C
0A
06
C0
C1
C3
C3
C1
04
C1
45
42
C1
00
0B
02
08
C1
C1
05
01
06
C1
86
45
C1
00
08
06
09
C1
C1
02
C1
C1
C1
00
0C
05
08
C1
3F
25
C1
06
03
01
C1
C1
C1
00
0C
0A
08
C1
41
3F
C1
C0
04
C3
C3
C1
C0
00
0C
0A
09
C1
C1
C0
C2
06
C1
C1
C1
C2
C0
00
0A
08
0B
C1
C1
25
03
41
25
C1
C1
00
0D
0B
09
C1
C1
C3
C0
43
06
43
41
C0
C3
C1
00
0C
0A
0A
C1
C4
C1
45
8D
4D
42
C1
C4
C1
00
0C
0A
0A
C0
C2
C0
46
86
46
43
C0
C2
C0
00
0A
08
0B
C1
C1
25
46
44
25
C1
C1
00
0A
08
0B
C0
C2
C1
C1
C1
C1
C2
C0
00
08
06
0C
C0
C1
C3
C3
C1
C0
00
04
02
0E
C1
C1
FF
FF
FF
FF
FF
00
FF
FF
FF
FF
00
04
02
08
00
00
00
08
06
06
00
00
00
00
00
00
00
0A
08
05
00
00
00
00
00
00
00
00
00
08
06
07
00
00
00
00
00
00
00
0D
01
03
C0
08
02
C3
C1
C0
00
00
00
00
00
00
10
02
02
C0
C2
01
01
C1
07
01
C1
C2
C0
00
00
00
00
00
0E
0C
02
C1
C1
25
41
41
25
C1
C1
00
00
C1
C1
00
12
0A
01
C1
C3
C0
43
44
43
41
C0
C3
00
04
01
42
3F
C1
C1
00
10
07
01
C1
C4
C1
45
8D
4D
42
05
01
C4
00
C1
43
42
00
14
0B
01
C0
C2
C0
46
86
46
06
04
C2
00
00
05
01
C1
00
00
C1
C1
00
16
06
02
C1
C1
25
46
44
25
06
01
06
04
02
00
00
00
04
01
C3
C3
C1
C0
00
14
12
03
C2
C1
C1
C1
C1
C2
00
00
05
04
C0
C2
C1
C1
C1
C1
C2
C0
00
14
12
03
C0
C1
C3
C3
C1
C0
00
02
00
00
06
04
25
41
41
25
C1
C1
00
14
02
05
C1
C1
0E
01
00
C1
C1
00
C1
C3
C0
06
04
43
41
C0
C3
C1
00
11
06
08
C1
44
42
C1
C1
C4
07
01
45
FB
06
42
C1
C4
C1
00
11
03
08
C1
8D
44
0A
01
C0
C2
C0
46
86
46
43
C0
C2
C0
00
0D
08
0B
00
00
C1
C1
25
46
44
25
01
01
C1
00
0D
07
0A
00
00
00
00
C2
C1
C1
02
01
C1
C2
00
0B
09
0A
00
00
00
00
C0
C1
C3
C3
C1
00
0B
06
0B
00
00
00
00
00
C1
01
01
00
00
0A
08
0B
00
00
00
00
00
00
00
00
00
08
06
0C
00
00
00
00
00
00
00
04
02
0E
00
00
FF
FF
FF
FF
FF
00
FF
FF
FF
FF
FF
FF
FF
00
04
02
05
00
00
00
0C
06
03
00
00
00
00
00
00
02
08
C1
C1
00
14
0A
02
00
00
00
00
00
00
00
00
C1
C1
06
03
C0
C1
C3
C3
C1
C0
00
18
07
02
00
00
00
00
00
00
00
02
01
43
41
09
01
00
C0
C2
C1
C1
C1
C1
C2
C0
00
17
0D
01
00
00
00
00
00
00
00
00
C1
46
43
C1
00
06
02
25
41
41
25
C1
C1
00
19
0A
01
00
00
00
00
C1
C1
00
00
00
C1
0B
01
00
C1
C3
C0
43
44
43
41
C0
C3
C1
00
1B
02
01
00
00
06
01
C1
C3
C3
C1
C0
C1
02
01
02
00
09
01
C4
C1
45
8D
46
42
C1
C4
C1
00
17
09
02
C0
C2
C1
C1
C1
C1
C2
C0
C1
0A
02
C0
C2
C0
06
06
4D
43
C0
C2
C0
00
17
08
02
C1
C1
25
41
41
25
C1
C1
0B
01
00
03
06
06
04
25
46
44
25
C1
C1
00
18
02
01
C1
C3
0F
01
43
44
43
41
03
06
06
04
02
00
00
C2
C1
C1
C1
01
01
C2
00
17
09
01
C1
C4
C1
45
8D
06
06
C1
C4
0A
02
02
00
00
C0
C1
C3
C3
C1
C0
00
00
18
0B
01
C0
C2
C0
46
86
46
43
C0
C2
C0
00
09
01
C1
00
00
00
C1
C1
00
00
00
00
18
06
02
C1
C1
25
46
44
25
02
01
C1
00
0A
01
43
41
C1
00
00
00
00
00
00
00
00
15
0B
03
C2
C1
C1
C1
C1
C2
00
00
C1
46
43
06
01
00
00
00
00
00
00
00
14
08
03
C0
C1
C3
C3
C1
C0
C1
C1
08
01
C1
C1
00
00
00
00
00
00
00
0C
02
05
C1
C1
06
07
00
00
00
00
00
00
00
04
02
10
00
00
FF
FF
FF
FF
FF
FF
FF
FF
00
FF
FF
FF
FF
FF
00
04
02
0F
C1
C1
00
08
06
0D
C0
C1
C3
C3
C1
C0
00
0A
08
0C
C0
C2
C1
C1
C1
C1
C2
C0
00
0B
06
0C
C1
C1
25
41
41
25
01
01
C1
00
0E
01
0A
00
09
01
C3
C0
43
44
43
41
C0
C3
C1
00
10
09
09
00
00
C1
C4
C1
45
8D
4D
42
03
01
C4
C1
00
00
0F
0D
09
00
00
C0
C2
C0
46
06
46
43
C0
C2
C0
00
00
14
02
05
00
00
03
03
00
00
C1
09
01
05
46
44
25
C1
C1
00
00
00
00
18
07
03
00
00
00
00
00
00
00
04
01
C1
C1
03
04
07
01
C1
C1
C2
C0
00
00
00
00
18
08
02
00
00
00
00
00
00
00
00
0C
01
45
42
FA
C1
C3
C3
C1
C0
00
00
00
00
00
17
06
02
00
00
00
00
00
C1
0D
01
00
C1
86
45
C1
00
C1
C1
00
00
00
00
00
00
16
14
01
00
00
00
00
C0
C1
C3
C3
C1
C1
C1
C1
C1
C1
00
00
00
00
00
00
00
17
07
01
00
00
00
C0
C2
C1
C1
0C
01
C1
03
03
3F
25
C1
00
00
00
00
00
00
00
12
0C
01
00
00
00
C1
C1
25
41
41
25
04
C1
25
02
04
00
00
00
10
01
02
00
0B
01
C3
C0
43
44
43
06
C0
C3
C1
00
00
00
0F
02
03
C1
C4
09
01
45
8D
FB
42
C1
C4
C1
00
00
00
0C
0A
04
C2
C0
46
86
46
43
C0
C2
C0
00
00
0B
01
04
C1
06
01
25
46
44
25
C1
C1
00
0A
08
04
C0
C2
C1
C1
C1
C1
C2
C0
00
08
06
05
C0
C1
C3
C3
C1
C0
00
04
02
07
C1
C1
FF
FF
FF
FF
FF
FF
00
FF
FF
FF
00
04
02
0C
C1
C1
00
08
06
0A
C0
C1
C3
C3
C1
C0
00
0A
08
09
C0
C2
C1
C1
C1
C1
C2
C0
00
0C
0A
09
C1
C1
25
41
41
25
C1
C1
00
00
00
0F
09
08
C1
C3
C0
43
44
43
41
C0
C3
02
01
00
00
00
0E
0C
08
C1
C4
C1
45
8D
4D
42
C1
C4
C1
00
00
00
10
06
08
C0
C2
C0
46
86
46
06
01
C0
C2
C0
00
00
00
00
0E
0C
09
C1
C1
25
FA
44
25
C1
C1
00
00
00
00
00
0E
0C
09
C0
C2
C1
06
C1
C1
C2
C0
00
00
00
00
00
0C
0A
0A
C0
C1
06
C3
C1
C0
00
00
00
00
00
10
02
07
C1
C1
04
02
00
06
C1
C1
04
01
00
00
00
00
00
0F
0D
06
C1
43
41
C1
00
00
06
00
00
00
C1
00
00
00
0A
08
06
C1
46
43
C1
02
02
06
00
00
10
09
05
00
00
C1
C1
00
00
00
03
02
03
01
43
41
C1
00
12
03
04
00
00
00
06
01
00
00
C1
06
00
00
03
01
46
43
C1
00
10
0A
04
00
00
00
00
C0
C1
C3
06
C1
C0
02
01
C1
C1
00
0F
09
03
00
00
00
00
C0
C2
C1
C1
06
02
01
C2
C0
00
0E
0C
03
00
00
00
00
C1
C1
25
41
06
25
C1
C1
00
10
06
03
00
00
00
C1
C3
C0
06
01
44
06
41
C0
C3
C1
00
0E
0C
04
00
00
C1
C4
C1
45
8D
06
42
C1
C4
C1
00
0E
0C
04
00
00
C0
C2
C0
46
86
46
43
C0
C2
C0
00
0C
0A
05
00
00
C1
C1
25
46
44
25
C1
C1
00
0A
08
07
C0
C2
C1
C1
C1
C1
C2
C0
00
08
06
08
C0
C1
C3
C3
C1
C0
00
04
02
0A
C1
C1
FF
FF
FF
FF
December 28th, 2012, 13:12
Posts: 151
Threads: 10
Joined: Nov 2010
(December 28th, 2012, 00:21)Vanshilar Wrote: Yeah I briefly skimmed through that monster thread a while back, but haven't gone through it in detail yet. I'm sure there's plenty of stuff that I've missed like strategies and game mechanics. I should go through it sometime.
I've written an LBX extractor and an LBX encoder for the ship sprites. The ship I encoded is the Slylandro Probe from Star Control 2. The sprites are:
This is each of the 5 frames, separated by a single white line. The encoder will take this and convert it into LBX code. I then deleted the last ship from SHIPS.LBX (the 6th yellow huge ship) and copy-pasted the output of the encoder into SHIPS.LBX in its place manually.
It works, but it turns out that palette 0 is transparent during battle, but not when you're looking at the ships flying through space (for example, in the fleet screen); they're simply black in that case. So unfortunately it does have the effect of the ship "eating" up the stars, in this case as the ship rotates, if you're looking at the fleet screen. So it's not perfect, but I think the problem here is of how MoO draws the sprites rather than the data (i.e. LBX).
I wrote it in Matlab, since it's the only programming language I'm familiar with. The encoder uses just the sprite file above as well as MoO's palette (from FONTS.LBX) as inputs and will automatically generate the LBX code from there. I only used the "standard" coding scheme though (header byte 0) and didn't use the "compressed" coding scheme (header byte 128), where colors are encoded in "(# repeats) (color)" format when there are repeats.
I'll take a look at the LBX extractor program, I'm not familiar with C# though so it may take some poking around to see what the bugs are that you mentioned. What are the functions that the bugs may be in (i.e. which functions should I pay particular attention to)?
I can't seem to attach .lbx files here, but the Slylandro ship code is below. To insert it into SHIPS.LBX, the steps are:
1. Open up SHIPS.LBX using a hex editor
2. Delete everything from byte B7CB onward (it should start with "20 00 18 00 00 00 05")
3. Copy-paste the below code at the end of SHIPS.LBX
In theory, you should also change bytes 128-129 (in hex) from "8E BB" to "EA BE", but I haven't found any problems yet with not doing this.
This will replace the 6th yellow huge ship with the Slylandro Probe from Star Control 2. I have the Ur-Quan Dreadnought and the Chenjesu Broodhome encoded as well, but they're not as visually "interesting" as the Probe.
You're lucky that it worked! When I investigated the LBX format, in the header section it specifies each file's starting byte and length, so if you alter that (either smaller or bigger) for any previous files, it'd corrupt the rest of the images (in theory, I haven't tested it). If you replace a file, you'd need to make sure it's the same byte length, or update all of the header's file references so that they're updated to the correct sizes and locations.
As for the transparency issue, I noticed that for ship drawing, it relies on the fact that the screen is NOT refreshed (i.e. setting everything to black before drawing), and the frames are drawn on top of previous frames. So let's take the yellow huge ship 6 as an example, the first frame have the entire bitmap drawn, but the next frame only have the bitmap for the engine exhaust, everything else is transparent. So it's drawn on top of the first frame, making it look animated. So if you want to see the last frame, you'd have to draw all the frames in order. You can see that I compensated for this in my tool by having each frame put into memory by drawing all previous frames in order, then the current one is drawn on top, then the final result is stored in memory. There are some sprites that don't use this method, and my tool messes those up. Examples include LANDING.LBX with "WALKXXX" ones, and in WINLOSE.LBX with FLAGXX, COFFINX, MARCHX, and WINSHIPS files
This is why I'm having difficulties with my LBX compressor. To import all images, I need to take the first frame, compare it against the second frame and make all identical pixels transparent in second frame. Then I need to repeat the process for every frame. However, it has to be done backwards (last frame is compared against second to last frame, then the last frame is compressed)
Then after every frame is compressed, I have to calculate their byte length and set the "file" with correct header, then for the final LBX file, I have to calculate all files' length and locations, and add color palettes if necessary.
For my tool, apparently the comparision process basically compresses all frames but first into 0 bytes, and I'm not sure why. Hope this help you understand how things are done in LBX!
December 29th, 2012, 00:56
Posts: 61
Threads: 10
Joined: Dec 2012
Yeah the header stores the starting location for each file, and presumably the end location is one byte before the following file's starting byte (presumably that's why the final entry is there). So I purposely replaced the last ship so that I wouldn't have to bother with changing the header entries whenever I was trying out a new ship. For whatever reason though it still works fine when the final entry in the header area doesn't match up with the actual final location of the last file, which just makes it one less thing I have to do each time I test out a ship. For any other entry yes the game crashes when trying to load the ship image.
For transparency, each frame after the first relies on the previous frame already being present; however, during battle, the palette entry 0 tells it to be transparent (i.e. use the underlying layer, i.e. starfield, for the color), rather than just being black. This effect is noticeable with the cursor, where it has a black outline which has a palette entry of 1 (whose color, like palette entry 0, is (0 0 0) or pure black) while the other entries are 0. This doesn't seem to work for when the ship is moving through space though (from the fleet screen), so it only becomes transparent on every frame 1 when the whole thing is redrawn. Instead, it will simply be black, thus obscuring the moving starfield behind it.
This (having palette color 0) is somewhat different from the renderer skipping which pixels to draw, i.e. the byte right before the color pixel data. So it's not really being transparent per se, but simply not being updated -- which is something different than palette color 0 which basically says "use the layer below (i.e. the starfield) for the color". For my Slylandro Probe, on successive frames I do have it set the palette to 0 for the pixels that the Probe are not longer at, but the fleet screen renders them as black rather than as transparent. The battle screen will render them as transparent and use the underlying starfield.
For my encoder, I basically draw the first frame using the skipping thing, so any pixels that are black (0 0 0) are skipped. For each successive frame, I basically have a "difference" image that is 0 if no change and 1 if that pixel changes for every pixel, and repeat the same code using it (and the new colors in the new frame when applying the 1's). So yeah to render the last frame you do need to render every frame before it. However, any pixels that don't change are not rendered at all but skipped (i.e. such as using 255 if the entire column is being skipped); I only apply 0 (transparency) if there were a color there previously but not in the new frame.
Yeah I don't know why the last two purple ships are stored separately. It doesn't seem like it was because they were out of space in the entries part of the file, since there's space for them, just that the space in the header is blank (0's). I don't know if a size issue makes sense either, since some of the other lbx files are a lot larger. Perhaps it had something to do with which developer was in charge of what? Dunno.
Changing the loading screen text ("program version 1.3" etc.) seems trickier. I don't see that text (such as "SIMTEX" or "imtex" or "IMTEX") anywhere, so it may be generated algorithmically or directly drawn as an image. It's easy enough to narrow down the files that it may be in (CONFIG.MOO, ORION.EXE, RESEARCH.LBX, V11.LBX, MUSIC.LBX, FONTS.LBX, INTRO.LBX, INTROSND.LBX, SOUNDFX.LBX, VORTEX.LBX) since those are the files that are used to get to that screen, but that's still over 3 MB of stuff to comb through. My bet is that it's generated somewhere in ORION.EXE, but I don't have much experience in looking inside executable files (such as seeing what parts of the executable are being used at what parts, or how it's using the memory, etc.). Conceivably though maybe the memory could be searched to see if it has "imtex" or "IMTEX" anywhere at the loading screen to at least narrow down if it is generated algorithmically or if it's an image.
December 29th, 2012, 03:54
Posts: 61
Threads: 10
Joined: Dec 2012
Hmm looking through the monster thread, Kyrub says the version number is stored in graphic format here. Has anyone found where? If it's found, it (hopefully) shouldn't be too hard to figure out how to change it.
December 29th, 2012, 10:00
Posts: 61
Threads: 10
Joined: Dec 2012
By the way: can you provide an example of any support files needed for your LBX Manager? When I try to import something (specifically, the Slylandro Probe bitmaps) it says it can't find LBXHEADER.TXT. I'm sure I could go through the code and slowly figure out what's supposed to be in there, but it might be faster just to ask
December 29th, 2012, 10:56
(This post was last modified: December 29th, 2012, 12:19 by Vanshilar.)
Posts: 61
Threads: 10
Joined: Dec 2012
Duh: The program version text at the bottom of the loading screen is stored as part of STARLORD (the first file) in V11.LBX. So if you want to modify it, that's where you would go. If Kyrub wants to modify it to fit the next unofficial patch, it should be fairly straightforward to change.
The only thing that might be slightly odd is that it uses a different palette than the default palette. However, it basically uses just 4 colors (for the bottom text):
245 for (48 48 48) (basically, most of the text)
15 for (24 24 24) (most of the darkened parts, like in the first "R" and in the "M" and "W")
10 for (16 16 20) (some of the darkened parts, like the top of the first "A")
5 for (20 8 8) (the lower right part of the "3" in "1993")
So it should be a simple matter to just change the encoding around to update the text. In fact, because there is ample space at the bottom of the screen, it can even be modified to be something like the current text, then something like "current version 1.5 by Kyrub" as a separate line below that, and possibly even direct the user to realmsbeyond.net (presumably this is the primary forums for Kyrub), potential legal issues notwithstanding. Because it uses 128-type compression (i.e. 80 in hex as the header byte for each column when there are pixels to draw), the size will increase somewhat, but I don't think that is an issue with current computers; just that V11.LBX will need to be modified since STARLORD is the first file within it.
|