I decided to take a brief interlude from the MicroProse PIC file format we have been reverse engineering over the last while. In this post we will look at another MicroProse file format, the SPC file format and try to learn its secrets. SPC files appear to be another format used by MicroProse in Railroad Tycoon Deluxe to store graphic assets. Many of the file names correspond with PIC assets which we have already analyzed in my previous post. I suspect that these are perhaps sprites, as most of the PIC images I’ve looked at so far appear to be full screen images. Only one way to find out, let’s dig in!
Analyzing the SPC files
I chose three interesting looking SPC files to use as my guinea pigs. ARROW.SPC because it is small, in fact so small that I’ve included its entire hex dump below. CREDIT.SPC thinking that it’s game credits, so perhaps rendered text, and WANTED.SPC just because it sounds intriguing. The first thing that jumps out to me is that the data appears very regular, perhaps a 16 or 32 bit alignment. Also the data does not appear to be compressed, this one may be an easy one. the first word seems to always be 0x001 or 0x002, though have not looked at other files yet. The next word always appears to be 0x001. The next word seems to be file specific, and is 0x000 in ARROW.SPC, so not sure what to make of it just yet. Then after a long string of 00 we have what looks like it might be width and height, but not traditional values (except for the 640), but if these are sprites, that could be reasonable. The height values seem super small, but again if these are sprites, who knows. Both the candidate width and height certainly look appropriate for Arrow, which is such a tiny file.
File: ARROW.SPC [176 bytes]
Offset x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Decoded Text
0000000x: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 · · · · · · · · · · · · · · · ·
0000001x: 0A 00 14 00 01 00 00 00 80 80 80 80 01 00 00 00 · · · · · · · · · · · · · · · ·
0000002x: C0 C0 C0 C0 01 00 00 00 C0 C0 C0 C0 01 00 00 00 · · · · · · · · · · · · · · · ·
0000003x: E0 E0 A0 A0 01 00 00 00 E0 E0 A0 A0 01 00 00 00 · · · · · · · · · · · · · · · ·
0000004x: F0 F0 90 90 01 00 00 00 F0 F0 90 90 01 00 00 00 · · · · · · · · · · · · · · · ·
0000005x: F8 F8 88 88 01 00 00 00 F8 F8 88 88 01 00 00 00 · · · · · · · · · · · · · · · ·
0000006x: FC FC 84 84 01 00 00 00 FE FE 86 86 01 00 00 00 · · · · · · · · · · · · · · · ·
0000007x: F8 F8 C8 C8 01 00 00 00 B8 B8 A8 A8 01 00 00 00 · · · · · · · · · · · · · · · ·
0000008x: 1C 1C 14 14 01 00 00 00 1C 1C 14 14 01 00 00 00 · · · · · · · · · · · · · · · ·
0000009x: 1E 1E 16 16 01 00 00 00 18 18 18 18 00 00 02 00 · · · · · · · · · · · · · · · ·
000000Ax: 00 00 02 00 00 00 02 00 C7 87 38 90 01 80 8B C7 · · · · · · · · · · 8 · · · · ·
0A 00: 10 Width?
14 00: 20 Height?
File: CREDIT.SPC [21200 bytes]
Offset x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Decoded Text
0000000x: 02 00 01 00 BB 02 00 00 00 00 00 00 00 00 00 00 · · · · · · · · · · · · · · · ·
0000001x: 80 02 25 00 46 00 05 00 00 00 1F 1B 00 00 00 00 · · % · F · · · · · · · · · · ·
0000002x: 00 00 00 00 00 11 00 11 00 20 00 20 00 49 00 49 · · · · · · · · · · · I · I
0000003x: 00 49 00 49 00 24 00 24 00 00 00 00 00 00 3E 36 · I · I · $ · $ · · · · · · > 6
80 02: 640 Width?
25 00: 37 Height?
File: WANTED.SPC [55312 bytes]
Offset x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Decoded Text
0000000x: 02 00 01 00 FE 07 00 00 00 00 00 00 00 00 00 00 · · · · · · · · · · · · · · · ·
0000001x: C3 01 8D 00 39 00 00 00 00 FF FF FF 00 FF FF FF · · · · 9 · · · · · · · · · · ·
0000002x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
0000003x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
C3 01: 451 Width?
8D 00: 141 Height?What comes after the width and height Looks to be the start of the image data itself. The image data in WANTED.SPC certainly seems to suggest that each byte of the image data is one of the 4 colour planes, so 8 pixels per 4 bytes. Same as what we had with the PIC file, except the data is arranged linearly instead of in separate planes. From the pattern I don’t think we are looking at each nibble representing a pixel, unless the image contains vertical bars. Given what we learned about the PC-9801 in my last post, I think it more than likely that the data is still separated out by planes.
The next thing catching my eye is the regular occurrence of 01 00 00 00 in arrow. Not sure if this is just because of the underlying image, or if that’s some sort of marker, perhaps for lines? Though there are only 17 of them, so perhaps not. Both CREDITS.SPC and WANTED.SPC have wider widths, so we’ll need to look at a larger chunk of hem to see if they display a similar pattern. I’m going to focus on WANTED.SPC, because with the data it has, it is much easier to spot variances.
File: ARROW.SPC [176 bytes]
Offset x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Decoded Text
0000000x: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 · · · · · · · · · · · · · · · ·
0000001x: 0A 00 14 00 01 00 00 00 80 80 80 80 01 00 00 00 · · · · · · · · · · · · · · · ·
0000002x: C0 C0 C0 C0 01 00 00 00 C0 C0 C0 C0 01 00 00 00 · · · · · · · · · · · · · · · ·
0000003x: E0 E0 A0 A0 01 00 00 00 E0 E0 A0 A0 01 00 00 00 · · · · · · · · · · · · · · · ·
0000004x: F0 F0 90 90 01 00 00 00 F0 F0 90 90 01 00 00 00 · · · · · · · · · · · · · · · ·
0000005x: F8 F8 88 88 01 00 00 00 F8 F8 88 88 01 00 00 00 · · · · · · · · · · · · · · · ·
0000006x: FC FC 84 84 01 00 00 00 FE FE 86 86 01 00 00 00 · · · · · · · · · · · · · · · ·
0000007x: F8 F8 C8 C8 01 00 00 00 B8 B8 A8 A8 01 00 00 00 · · · · · · · · · · · · · · · ·
0000008x: 1C 1C 14 14 01 00 00 00 1C 1C 14 14 01 00 00 00 · · · · · · · · · · · · · · · ·
0000009x: 1E 1E 16 16 01 00 00 00 18 18 18 18 00 00 02 00 · · · · · · · · · · · · · · · ·
000000Ax: 00 00 02 00 00 00 02 00 C7 87 38 90 01 80 8B C7 · · · · · · · · · · 8 · · · · ·
01 00 00 00: 1
File: WANTED.SPC [55312 bytes]
Offset x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Decoded Text
0000000x: 02 00 01 00 FE 07 00 00 00 00 00 00 00 00 00 00 · · · · · · · · · · · · · · · ·
0000001x: C3 01 8D 00 39 00 00 00 00 FF FF FF 00 FF FF FF · · · · 9 · · · · · · · · · · ·
0000002x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
0000003x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
0000004x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
0000005x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
0000006x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
0000007x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
0000008x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
0000009x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
000000Ax: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
000000Bx: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
000000Cx: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
000000Dx: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
000000Ex: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
000000Fx: 00 FF FF FF 00 FF FF FF 00 E0 E0 E0 39 00 00 00 · · · · · · · · · · · · 9 · · ·
0000010x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
39 00 00 00: 57Now that is interesting, we do see a repeat in the pattern. even more interesting is that in WANTED.SPC there are 228 bytes between the highlighted markers. If we assume 4 bytes per pixel group, or record, that comes to 57 records, the same value as our marker record. The same holds for ARROW.SPC which has a marker value of 1, and there is 1 record between occurrences of the marker. Now I doubt that the value is being stored as a 32 bit value here, this was 1993 after all. It is more likely that the length 8 or 16 bits. Given most everything else seems to be 16 bits, except the pixel data itself, I’m going to start by assuming a 16 bit length, followed by another 16 bit unknown value. Doing this maintains the 32 bit alignment that we see in the hex dump. Now let’s see how that translates to pixels. WANTED.SPC has a value of 451 for what we believe to be the width. If we divide 451 by 8, because we have 8 pixels packed per record, we get 56.375, can’t have a partial record/byte so round that up to 57. That can’t be a coincidence, the marker must be delineating scanlines of the image. Unfortunately the math does not work out for ARROW.SPC, as we only have 1 record, so only 8 pixels of data per entry. But ARROW.SPC also has a different value in it’s first word, perhaps that is signalling a different kind of packing? Maybe ARROW.SPC only has 1 or 2 bits of image data? We’ll keep that in mind, but not going to stop because of that just yet.
Parsing the SPC file
I think we have enough to start writing some code to try and parse through the file. For starters we have a header that looks something like the following.
typedef struct {
uint16_t unk1; // 0x0001 or 0x0002
uint16_t unk2; // always 0x0001
uint16_t unk3; // appears to be file specific
uint8_t unk4[10]; // always all 0x00 (could very well be 5 16bit words)
uint16_t width; // looks to be image width
uint16_t height; // looks to be image height
} spc_hdr_t;
Then for the image scanline data we have.
typedef struct {
uint16_t len; // length of line in 32bit records
uint16_t unk1;
} spc_line_t;
Writing up a quick program to parse through the file based on what we know so far we get the following for ARROW.SPC. I’m not going to post the code for that as it’s pretty straight forward: seek, read, print; repeat.
Explorer for MicroProse SPC Files
Analyzing: 'ARROW.SPC' File Size: 176 bytes
unk1: 0001 (1)
unk2: 0001 (1)
unk3: 0000 (0)
unk4: 00 00 00 00 00 00 00 00 00 00
width: 10
height: 20
Pos: 000014 line 0: len: 1 unk1: 0000 (0)
Pos: 00001c line 1: len: 1 unk1: 0000 (0)
Pos: 000024 line 2: len: 1 unk1: 0000 (0)
Pos: 00002c line 3: len: 1 unk1: 0000 (0)
Pos: 000034 line 4: len: 1 unk1: 0000 (0)
Pos: 00003c line 5: len: 1 unk1: 0000 (0)
Pos: 000044 line 6: len: 1 unk1: 0000 (0)
Pos: 00004c line 7: len: 1 unk1: 0000 (0)
Pos: 000054 line 8: len: 1 unk1: 0000 (0)
Pos: 00005c line 9: len: 1 unk1: 0000 (0)
Pos: 000064 line 10: len: 1 unk1: 0000 (0)
Pos: 00006c line 11: len: 1 unk1: 0000 (0)
Pos: 000074 line 12: len: 1 unk1: 0000 (0)
Pos: 00007c line 13: len: 1 unk1: 0000 (0)
Pos: 000084 line 14: len: 1 unk1: 0000 (0)
Pos: 00008c line 15: len: 1 unk1: 0000 (0)
Pos: 000094 line 16: len: 1 unk1: 0000 (0)
Pos: 00009c line 17: len: 0 unk1: 0002 (2)
Pos: 0000a0 line 18: len: 0 unk1: 0002 (2)
Pos: 0000a4 line 19: len: 0 unk1: 0002 (2)
Pos: 0000a8 (168)
DoneNow that’s interesting. We get 20 records, seems that a record length of zero is valid. I guess that means that if the image exceeds the provided pixel data, the reader just pads it with 0 (or some other value)? That would solve the problem of the width of 10, but only having data for 8 pixels. Another thing that I noticed is that the unknown value in the line record switched from 0000 to 0002 when the length switched to zero. It appears that parsing ended with 8 bytes remaining in the file, as the parsing stopped at 0x0A8 while the file EOF is at 0xB0 for ARROW.SPC.
Explorer for MicroProse SPC Files
Analyzing: 'WANTED.SPC' File Size: 55312 bytes
unk1: 0002 (2)
unk2: 0001 (1)
unk3: 07fe (2046)
unk4: 00 00 00 00 00 00 00 00 00 00
width: 451
height: 141
Pos: 000014 line 0: len: 57 unk1: 0000 (0)
Pos: 0000fc line 1: len: 57 unk1: 0000 (0)
Pos: 0001e4 line 2: len: 57 unk1: 0000 (0)
Pos: 0002cc line 3: len: 57 unk1: 0000 (0)
Pos: 0003b4 line 4: len: 57 unk1: 0000 (0)
⋮ ⋮ ⋮ ⋮
Pos: 007c3c line 137: len: 57 unk1: 0000 (0)
Pos: 007d24 line 138: len: 57 unk1: 0000 (0)
Pos: 007e0c line 139: len: 57 unk1: 0000 (0)
Pos: 007ef4 line 140: len: 57 unk1: 0000 (0)
Pos: 007fdc (32732)Well that is very promising! We traversed cleanly based on the same criteria. WANTED.SPC doesn’t seem to end with zero records, that probably just means that the image doesn’t end in blank lines. We also only seem to be about half way through the file, hmm… Better take a look at what’s going on at that point. We stopped because we reached the height value.
A plural of images
File: WANTED.SPC [55312 bytes]
Offset x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF Decoded Text
00007EFx: 00 E0 E0 E0 39 00 00 00 00 FF FF FF 00 FF FF FF · · · · 9 · · · · · · · · · · ·
00007F0x: 00 FF FF FF 00 FA FD FA 00 FF 7F FF 00 C8 F7 C8 · · · · · · · · · · · · · · · ·
00007F1x: 00 40 BF 40 00 00 FF 00 80 80 7F 80 00 00 FF 00 · @ · @ · · · · · · · · · · · ·
00007F2x: 00 1C FF 1C 02 03 FD 03 10 F0 6F F0 00 00 FF 00 · · · · · · · · · · o · · · · ·
00007F3x: 02 57 A9 57 00 80 7F 80 00 00 FF 00 00 00 FF 00 · W · W · · · · · · · · · · · ·
00007F4x: 00 04 FB 04 00 1E FF 1E 00 BF 5F BF 00 FF FF FF · · · · · · · · · · _ · · · · ·
00007F5x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
00007F6x: 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · · · · · · · · · · · · · · · ·
00007F7x: 6F 90 FF FF 67 98 FF FF 38 C7 7F FF 1E E1 FF FF o · · · g · · · 8 · · · · · · ·
00007F8x: 0E F1 EF FF 1E C1 FF DF 63 98 FF FB 30 C7 FF F7 · · · · · · · · c · · · 0 · · ·
00007F9x: 00 FF FF FF F8 07 FF FF 3C 83 FF BF C3 38 FF FB · · · · · · · · < · · · · 8 · ·
00007FAx: 38 47 FF 7F 01 FE FF FF CE 31 EF FF 1E E1 FF FF 8 G · · · · · · · 1 · · · · · ·
00007FBx: 0F F0 FF FF 30 C7 7E F7 E7 18 FF FF 0D F2 ED FF · · · · 0 · ~ · · · · · · · · ·
00007FCx: C0 3F FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF · ? · · · · · · · · · · · · · ·
00007FDx: 00 FF FF FF 00 FF FF FF 00 E0 E0 E0 08 00 00 00 · · · · · · · · · · · · · · · ·
00007FEx: C3 01 8D 00 39 00 00 00 00 FF FF FF 00 FF FF FF · · n · 9 · · · · · · · · · · ·
00007FFx: 00 FF FF FF 00 FA FD FA 00 FF 7F FF 00 C8 F7 C8 · · · · · · · · · · · · · · · ·
0000800x: 00 40 BF 40 00 00 FF 00 80 80 7F 80 00 00 FF 00 · @ · @ · · · · · · · · · · · ·
39 00 00 00: Start of last line record
00 E0 E0 E0: last 32 bit record of line
08 00 00 00: Unknown data
C3 01: 451 Width
8D 00: 141 HeightWe have a second image? Interesting. I wonder if that 0001/0002 as the first word is indicating the number of images in the file. It certainly seems as if we have width and height defined again, and the sequence of bytes in the data is different, so the image data is indeed different here. We do have a few bytes of unknown data before the width and height, not sure what to make of that just yet. We also have that long block of zeros before the image width and height in the header. I’m thinking we can rearrange our structures a bit to accommodate this.
typedef struct {
uint16_t images; // possibly count of images in file
uint16_t unk2; // always 0x0001
uint16_t unk3; // appears to be file specific
uint8_t unk4[6]; // always all 0x00 (could very well be 3 16bit words)
} spc_hdr_t;
Moving the width and height plus the previous 4 bytes into their own structure.
typedef struct {
uint16_t unk1;
uint16_t unk2;
uint16_t width; // looks to be image width
uint16_t height; // looks to be image height
} spc_image_t;
Our scanline structure remains unchanged at this point. Let’s update the code to parse the file based on this new arrangement to see what we get.
Explorer for MicroProse SPC Files
Analyzing: 'WANTED.SPC' File Size: 55312 bytes
images: 2
unk2: 0001 (1)
unk3: 07fe (2046)
unk4: 00 00 00 00 00 00
Pos: 00000c (12)
Image 0
unk1: 0000 (0)
unk2: 0000 (0)
width: 451
height: 141
Pos: 000014 image: 0 line 0: len: 57 unk1: 0000 (0)
Pos: 0000fc image: 0 line 1: len: 57 unk1: 0000 (0)
Pos: 0001e4 image: 0 line 2: len: 57 unk1: 0000 (0)
Pos: 0002cc image: 0 line 3: len: 57 unk1: 0000 (0)
⋮ ⋮ ⋮ ⋮ ⋮
Pos: 007c3c image: 0 line 137: len: 57 unk1: 0000 (0)
Pos: 007d24 image: 0 line 138: len: 57 unk1: 0000 (0)
Pos: 007e0c image: 0 line 139: len: 57 unk1: 0000 (0)
Pos: 007ef4 image: 0 line 140: len: 57 unk1: 0000 (0)
Pos: 007fdc (32732)
Image 1
unk1: 0008 (8)
unk2: 0000 (0)
width: 451
height: 110
Pos: 007fe4 image: 1 line 0: len: 57 unk1: 0000 (0)
Pos: 0080cc image: 1 line 1: len: 57 unk1: 0000 (0)
Pos: 0081b4 image: 1 line 2: len: 57 unk1: 0000 (0)
Pos: 00829c image: 1 line 3: len: 57 unk1: 0000 (0)
⋮ ⋮ ⋮ ⋮ ⋮
Pos: 00c03c image: 1 line 71: len: 57 unk1: 0000 (0)
Pos: 00c124 image: 1 line 72: len: 57 unk1: 0000 (0)
Pos: 00c20c image: 1 line 73: len: 56 unk1: 0001 (1)
Pos: 00c2f0 image: 1 line 74: len: 56 unk1: 0001 (1)
Pos: 00c3d4 image: 1 line 75: len: 56 unk1: 0001 (1)
Pos: 00c4b8 image: 1 line 76: len: 54 unk1: 0003 (3)
Pos: 00c594 image: 1 line 77: len: 54 unk1: 0003 (3)
⋮ ⋮ ⋮ ⋮ ⋮
Pos: 00d770 image: 1 line 106: len: 12 unk1: 0019 (25)
Pos: 00d7a4 image: 1 line 107: len: 11 unk1: 0019 (25)
Pos: 00d7d4 image: 1 line 108: len: 11 unk1: 0019 (25)
Pos: 00d804 image: 1 line 109: len: 0 unk1: 0039 (57)
Pos: 00d808 (55304)
DoneSo far so good, and we end at 8 bytes from EOF, same as with ARROW.SPC so that’s a good sign. One odd thing is the decreasing length value for the line, interestingly the value that follows seems to increase by the same amount it goes down, at least initially. I wonder if the 2nd value doesn’t represent a offset into the scanline? And given that the value changes by the same magnitude as the length, this is again in bytes, or pixel records, not individual pixels. At the end of the file we seem to end like ARROW.SPC with a zero length line. The lines above also seem too short for the width, I wonder if this is like in ARROW.SPC again, where data is only provided for non-zero pixels. That actually fits in with the offset idea as well. Only the area of interest is provided, places where pixels are non-zero. This would provide for a little bit of image compression, by trimming off leading and trailing zero bytes. Also notice the new offset value in the final record, it starts after the line would end, just like it does with ARROW.SPC. Given what we have just deduced, this would make sense for a line of all zero bytes. (I also checked with CREDIT.SPC and we see a similar result.
Explorer for MicroProse SPC Files
Analyzing: 'CREDIT.SPC' File Size: 21200 bytes
images: 2
unk2: 0001 (1)
unk3: 02bb (699)
unk4: 00 00 00 00 00 00
Pos: 00000c (12)
Image 0
unk1: 0000 (0)
unk2: 0000 (0)
width: 640
height: 37
Pos: 000014 image: 0 line 0: len: 70 unk1: 0005 (5)
Pos: 000130 image: 0 line 1: len: 72 unk1: 0004 (4)
Pos: 000254 image: 0 line 2: len: 73 unk1: 0003 (3)
Pos: 00037c image: 0 line 3: len: 72 unk1: 0004 (4)
⋮ ⋮ ⋮ ⋮ ⋮
Pos: 0027f4 image: 0 line 33: len: 80 unk1: 0000 (0)
Pos: 002938 image: 0 line 34: len: 78 unk1: 0001 (1)
Pos: 002a74 image: 0 line 35: len: 76 unk1: 0002 (2)
Pos: 002ba8 image: 0 line 36: len: 0 unk1: 0050 (80)
Pos: 002bac (11180)
Image 1
unk1: 0000 (0)
unk2: 0000 (0)
width: 640
height: 37
Pos: 002bb4 image: 1 line 0: len: 0 unk1: 0050 (80)
Pos: 002bb8 image: 1 line 1: len: 0 unk1: 0050 (80)
Pos: 002bbc image: 1 line 2: len: 0 unk1: 0050 (80)
Pos: 002bc0 image: 1 line 3: len: 0 unk1: 0050 (80)
⋮ ⋮ ⋮ ⋮ ⋮
Pos: 004f08 image: 1 line 33: len: 80 unk1: 0000 (0)
Pos: 00504c image: 1 line 34: len: 80 unk1: 0000 (0)
Pos: 005190 image: 1 line 35: len: 78 unk1: 0001 (1)
Pos: 0052cc image: 1 line 36: len: 0 unk1: 0050 (80)
Pos: 0052d0 (21200)
DoneThis one is getting long, so I’m going to break it off here, but I think we’re at the point of finally being able to render something, so that is where we’ll pick up next time in part 2.
Ouch my eye! 
Leave a comment