no prob.

Just a quick note on the 00 A3 Opcode. If you look at the file dust.3 you will find the following:


header;FFFC3E80000000007FFF00000000000000000000
header;0002000300030000000000000083000700040005
header;000600000000000000200000002000000020000000040030001E
0000;007B0004
0001;0000
0002;00080008
0003;0008056A
0004;0000
0005;00A30D16
0006;002700320334
0007;00480000
>>>>>
0238;0000
0239;0001000200030000
0240;00A30338
0241;004B00030004
0242;0000

Could this be a jump to the second 00 A3 opcode?

I also noticed that the Header for dust.3 is different on the AGP PC than on the PCI/Glide PC:

header;FFFC05DC000000007FFF00000000000000000000
header;0002000300030000000000000083000700040005
header;000600000000000000200000002000000020000000040030001E

ie, 8000 vs 16000, maximum visible distance? D3D half that in 3DFx/Glide ?


There are some interesting findings in this file.

0372;00A700A200910075
0373;00470101000400000000008000000080008000000080
0374;008800040000000100020003
0375;00A8
0376;0000

Considering the opcodes 00 A3, 00 A7 and 00 A8, it appears as if their is a seperate set of Opcodes for specific AGP file system.

I modified the dust.3 files code related to the 00 A7 opcodes: 00A700A200910075
Simply changing the color determinant from 00A2 to 0103 changed the texture color for dust.raw from gold/brown to bright green. In TAW the dust plumes from ground vehicles are now visible as green dust, this is the same code in the .3 files responsible for the colored missile trails, explosions, etc.. I ported the modified dust.3 file to my 3DFx-Glide/PCI PC and the AGP opcodes are not recognized, the dust plumes appear as white 3d objects complete with ground shadows which are not present with the AGP/.raw textures system implementation. It is not yet clear what the 008A opcode does however it could be the AGP system equivalent of 00 00 used to terminate the AGP related blocks of code. The AGP flag determines which block is utilized?

00470101... calls 257h + 1; 258=dust (.raw)

Typical! you pick one of the most complicated files.
The dust and smoke files were some of the hardest to make sense of when trying to find out how to split them up into opcode lines, and they haven't necessarily been converted correctly.
Line 0239 is a bit suspicious:
0239;0001000200030000
This is the opcode for drawing a line, but seems out of place here, particularly with its following parameters. So, the chances are I've misinterpreted something a few lines earlier.
I'll try and look at this later and update the Parse_3 program if necessary.

Did you run run Krus's extractor on both machines? This is worrying if different 3 files are produced on different machines.

Seems to be for 00A3. If you go into TAW options, there are buttons for a whole bunch of things like building textures, aircraft shadows etc. It would seem logical that there are opcode combinations to handle these settings.

At least that stacks up.

The colour stuff is interesting, but 0102 is not a palette colour since the size of the palette is only 00FF bytes. It may wrap round to 0002 though.
Maybe those lines could be interpreted instead as:
00A7
00A200910075
.
.
00A8

Anyway, a thought provoking post, DKD.

Now, this is really bugging me. I think we need to find a copy of Krus's first version of the extractor, ie the one where you had to play the game, in order to ensure (or otherwise) that the .3 files output are the same if different graphics options are selected in 'TAW Options'.

That's what friends are for sue me



It's been a couple years since I did the most recent extractions and I had to reconstruct my entire Glide/PCI system after a recent meltdown. IIRC the program files on the Glide/PCI PC were ported over from the same extraction used on the D3D/AGP PC, but I'll have to confirm that.

I've just run dust.3 through the parser and there seems to be a 003E opcode that I haven't identified before:
0135;003E
0136;0000
0137;00B0
0138;0000
0139;0001000200030000
....which should probably be treated as one line, with maybe a terminating 0000:
003E000000B00000000100020003
0000

The 0000000100020003 are probably vertex indices (since this block follows vertex descriptions), but I have no clue as to the rest.

I have identified basic colors, green and what I would consider 2 shades of red, could the .raw textures palette be limited to 4bit color?

Haven't been able to crack the 00A7 color code yet, busy chasing my tail on the [Loadsetupsupershape] project. Was able to harvest a list of the 00A7 codes from the "heavenly.3" file and a number of the weapons files.

The code lines were hex edited into the dust.3 file and the color of the dust plume in the game was noted:

00A700FB009700FF: Pink/White
00A700FF00BF00D3: Pink
00A700FF00DB00C3: Pink/Amber
00A700FF00E300D7: Light Amber
00A700FF00EF00EB: Amber
00A700FF00DF0093: Gold
00A700FF00CF0053: Bright Gold
00A700FF00CD0049: Yellow Gold

00A700FF00970017: Bright Orange

00A700D600AF0051: Bright Yellow/Gold

00A700C100790031: Orange

00A7009B00600020: Orange/Gold

00A700A7003E002F: Orange/Pink

00A7009300DE00FF: Pink

00A7003900EB006B: Lime Green

00A700BD00390028: Red

00A70078001F0018: Bright Red

If we take the 00A7 line eg:
00A700FB009700FF
and then treat the 3 numbers after the 00A7 as RGB colours, so R=00FB, G=0097 and B=00FF, then repeat for all 17 of the examples above......we get this:



Apart from the 4th to last, the colours come out pretty much as DKD describes.
....and you can also see that I can't count.

Okay, very good. So, if I contrast this with the sea.3 files process of color acquisition, is it correct to say the sea.3 calls the Tex4.tm texture map which contains an index to the first 16 positions in the palette (.col) file which determine the color of the .TM texture by using the TAW 6 bit RGB hex codes contained within the .col palette file?
In contrast, the dust.3 file, on an AGP activated PC, will determine the color of its (dust).RAW texture using the TAW 6 bit RGB hex codes directly from the .3 file itself?