Jump to content
COMBATSIM Forum
Krycztij

TAW terrain format

Recommended Posts

Ah yes, good job I asked. :)

So, ideally we would be better off with a D3D wrapper if it had all the features of dgVoodoo?

I need to go through HF's comparison document again.....

Share this post


Link to post
Share on other sites

Got a bit of a problem with the windsock (awind.3) in the viewer.

As I understand it, the windsock should move up and down with Parameter 0000, but it doesn't. The mechanism to do this is via 002d opcodes, but this is a bit more complicated than usual with some 0052 opcodes thrown in for good measure.

Might be worth looking into...

Share this post


Link to post
Share on other sites

Sorry to say there are no big updates -- I'm trying to find an order- and state-preserving representation of the data and it takes a lot of time :unsure:

Just wanted to announce a quick update regarding texture shading: There are three shading modes, used by 002F, 008E and 0088 "draw textured polygon" instructions, respectively:

  • In 002F ("solid") mode, texels are interpreted as indices to the current color palette. The index "0" will not occur; all textures are sampled without any transparency. This is used for the terrain's base.
  • In 008E ("mask") mode, texels are interpreted as indices to the current color palette. The index "0" denotes full transparency; colors of other indices are fully opaque. This is used for harbors, streets, rivers etc.
  • In 0088 ("transparent") mode, texels are interpreted as alpha values. Two kinds of alpha values will occur: transparent black for texels between 0 (fully transparent) and 31 (opaque), inclusively (used for smoke and for oil spills below ships) and transparent white for texels between 32 (fully transparent) and 63 (opaque), inclusively (used for missile trails). There may be other kinds of alpha, but I didn't find any yet.

Share this post


Link to post
Share on other sites

So, if 002f doesn't use 0 at all, then there is no difference to 008e?

The 0088 opaque colour can be set to an arbitrary 24-bit value if AGP is enabled, eg this sequence from dust.3:

0340; 00a700a200910075    ; AGP Colour: Red=162 Green=145 Blue=117

0341; 00470101000400000000008000000080008000000080    ;UV Coords: 0,0 128,0  128,128  0,128

0342; 008800040000000100020003    ; Transparency = dust

0343; 00a8    ;

...in Direct3D mode at least.

Share this post


Link to post
Share on other sites

So, if 002f doesn't use 0 at all, then there is no difference to 008e?

Not any visible one, but a technical one: If you know that no alpha blending will occur, you can probably speed up rendering because you know all pixels covered by the triangle are actually overwritten. I'm currently trjing to render the whole terrain, and the difference greatly helps me to know when to switch depth buffering on and off.

Share this post


Link to post
Share on other sites

I still have that code for that proxy d3d dll we were looking at some months ago, so with some time and effort could probably track down that moving map problem...but is there any particular reason to persevere with d3d?

As I understand it, the only big advantage with d3d is the 1024x768 patch. With dgVoodoo being able to upscale to any resolution, this doesn't seem relevant anymore.

I realise that the wrapper affects performance, but that's going to become less of an issue over time.

Actually, on my laptop I get better performance in Glide using Zeckensack's wrapper than I do with D3D straight up. Problem with Zeck is having to force 1600x1200 to get high resolution in TAW, since it will only upconvert to resolution multiples.

dgVoodoo definitely slows things down; thats the major downside of that wrapper, especially with forcing higher resolutions. However, IMHO it looks the best of the wrappers and since it doesn't work at the system/registry level, you can easily customize it for TAW. With a 9800 series (or equivalent) GPU, you don't notice the slowdown.

For a mid-grade D3D9 GPU, I would take a look at nGlide. Good performance, looks, and compatibility with forcing high resolution. Doesn't look quite as good as dgVoodoo, but still looks great.

Share this post


Link to post
Share on other sites

Wow, I hadn't noticed that, but I've only ever tried to put 9 tiles together at any one time.

This does explain entries in some terrain ssd files like 'montXX_Y.ssd' though.

Share this post


Link to post
Share on other sites

This does explain entries in some terrain ssd files like 'montXX_Y.ssd' though.

I agree and I hadn't noticed it either until now. I must say, the terrain image with Y off is a rather impressive image. It would seem imprudent to not take advantage of such a remarkable find, therefore, I have considered that this may possibly be a method which could, when applied to the cloud tiles, provide the perception of volume. I have taken the cloud file cloud1m1.ssd, added a Block 3 (previously empty) and implemented a Y axis offset, modified the header 10th byte and recompiled. Surprisingly it is accepted and I'll report back with any appreciable effect :)

Share this post


Link to post
Share on other sites

So, you seem to have an idea what's going on in the SSD. I, however, follow another trace in the .3 files: It seems like all files with Y offset begin with this pattern:

    0093 jump 4 B if ??? (true)

 >> 0062 write XYZ #0: 0 700 0

 >> 0075 ??? (0)

 >> 002D draw submesh at 4B with XYZ offset 0 700 0

    0027 jump 8 B if distance is above 6000 (false)

    007B jump 4 B if ??? (true)

    0076 jump 4 B if ??? (true)

 >> 0062 write XYZ #1: -1024 -690 -1024

 >> 0064 write XYZ #2 with X delta: -512 -690 -1024

 >> 0064 write XYZ #3 with X delta: 0 -690 -1024

 >> 0064 write XYZ #4 with X delta: 512 -690 -1024

 >> 0064 write XYZ #5 with X delta: 1024 -690 -1024

The mesh is drawn with correct positions initially, but the 002D instruction at the beginning causes the Y offset. Mike: this is why your terrain viewer rendered O.K.; it didn't know the purpose of 002D and ignored the Y offset. You weren't just lucky picking nine tiles without any offset.

I don't know what's the purpose of writing initially correct positions and drawing them with Y offset, but: As I pointed out earlier, 0075 is a marker for relevant points on the model (like where to place pylons etc). Seems like every misplaced model has a 0075 with the correct offset at the beginning, so I assume it's the coordinate origin here. I'll do the following: If there is a 0075 instruction before any polygons are drawn, I'll treat it as a displacement. If this breaks existing models, I'll try ignoring the very first 002D in every file.

Share this post


Link to post
Share on other sites

Great success! "if nothing has been rendered before the first 0075 appears, use the given vertex as offset" works:

tileson.jpg

(There are still a few tiles missing, but that's a problem with how I list lights)

I have not seen any no-terrain models break.

Share this post


Link to post
Share on other sites

Well done!...and yes, I ignored the 002d and probably every 0062 with a positive Y value....it was a few years ago.

We don't have much idea what's going on in the ssd, but we do know something about its structure. What we call 'Block 3' holds offsets for each model. In the case of 'mont1c_1.ssd' there is only one:

;Block3 Starts 110 Length.6


0000a8fd0000;    X=0    	Y=-600    	Z=0
This matches the first 0062 in 'mont1c_1.3':
0000; 00930004    ; If 0093 flag set, jump to line 2

0001; 0000    ;

0002; 00620000000002580000    ; Vertex :0  X=0  Y=-600  Z=0

0003; 00750000    ;

0004; 002d00000004    ; Vertex Test 0 , jump to line 6

0005; 0000    ;

0006; 002717700008    ; If Distance >6000 then jump to line 9

0007; 007b0004    ; If 007b flag set, jump to line 9

0008; 0000    ;

0009; 00760004    ; If 0076 flag set, jump to line 11

0010; 0000    ;

0011; 00620001fc00ff65fc00    ; Vertex :1  X=-1024  Y=155  Z=-1024

0012; 00640400    ; Vertex :2  X=0  Y=155  Z=-1024

0013; 00640400    ; Vertex :3  X=1024  Y=155  Z=-1024

0014; 00660400    ; Vertex :4  X=1024  Y=155  Z=0

.

.

I should really update my parser comments.....but it looks like it's going to be completely redundant soon. :)

Share this post


Link to post
Share on other sites
This matches the first 0062 in 'mont1c_1.3'
To say it out straight: I don't think 0062 has anything to do with the displacement -- in jeddah_j.3, for example, the first 0062 writes -1024/0/-1024, which would yield completely incorrect results if taken as the base offset. The difference between jeddah_j.3 and mont1c_1.3 is, jeddah_j does not define a 0075 vertex before any content is drawn, but mont1c_1 does. So jeddah_j is drawn at the default position and mont1c_1 is elevated to 0/-600/0.

But I think there is more sense in using the SSD's block 3: Three or four models (, dams always,) are drawn with a displacement off by a few meters :/

This block 3 is really interesting. I could probably get the whole terrain engine up and running ... very seductive! But I must control myself, there are still too many bugs in the .3 viewer which need to be handled before they can be drawn at arbitrary positions :(

I should really update my parser comments.....but it looks like it's going to be completely redundant soon. :)
;) I'll see if I can upload the current list of understood opcodes this afternoon. My shadow experiments made it a little messy; I need to tidy it up.

Share this post


Link to post
Share on other sites

Mostly or fully understood:

// 0000

// Return to caller.


// 0001 <color> <position0> <position1>

// Draw a flat-shaded line of the color at palette index <color> between the <position0>'th and

//	<position1>'th position.


// 0002 <color> <position0> <position1> <position2>

// Draw a flat-shaded triangle with the color at palette index <color>. The indices of its vertices'

//	positions are given in clockwise order by <position0>, <position1> and <position2>.


// 0003 <color> <position0> <position1> <position2> <position3>

// 007D <color> <position0> <position1> <position2> <position3>

// Draw a flat-shaded quad with the color at palette index <color>. The indices of its vertices'

//	positions are given in clockwise order.


// 0004 <color> <vertices> <position>[<vertices>]

// Draw a flat-shaded <vertices>-sided polygon with the color at palette index <color>. It consists of

//	at least three vertices; its position indices are given in clockwise order.


// 0008 <offset>

// Call the subroutine at <offset> - 2 bytes offset from the instruction's end.


// 0015 <position0> <position1> <position2> <offset>

// If the triangle of the vertices at the given positions (clockwise) faces away from the viewer,

//	jump <offset> - 2 bytes relative to the end of the instruction.


// 0020 <reference> <offset>

// If the currently active parameter is below <reference>, jump <offset> - 2 bytes.


// 0021 <reference> <offset>

// If the currently active parameter equals <reference>, jump <offset> - 2 bytes.


// 0022 <reference> <offset>

// If the currently active parameter is above <reference>, jump <offset> - 2 bytes.


// 0027 <threshold> <offset>

// If the object's distance from the viewer is above <threshold>, jump <offset> - 2 bytes.


// 002D <translation> <offset>

// A translation to the <translation>'th position is pushed onto the stack and the subroutine at

//	<offset> - 2 B is called. The transformation is popped when the subroutine returns.


// 002E <texture> <number> for each <number>[<u> <v>]

// 0047 <texture> <number> for each <number>[<u> <v>]

// Write <number> texture coordinates of a polygon. The 002E instruction precedes the 002F instruction

//	only, so we know the next polygon will be drawn in 'solid' texture mode.


// 002F <vertices> for each <vertices>[<index>]

// Draw a textured <vertices>-sided polygon with the last set of texture coordinates. It consists of

//	at least three vertices; its position indices are given in clockwise order. The texture's bytes are

//	interpreted as indices to the current color palette; no transparency is applied.


// 0030 <unit length>

// Scale the model by 1 / <unit length>.


// 0033 <color> <position>

// Draw a signal light of the color at palette index <color> at the <position>'th position. Signal

//	lights are used on runways and on planes.


// 0034 <color> <position>

// Draw a light of the color at palette index <color> at the <position>'th position. Mostly used for

//	towns; runways and planes use signal lights instead.


// 0039 <pairs> <color> <position0> <position1>

// Draw <pairs> pairs of street lights of the color at palette index <color> between the <position0>'th

//	and <position1>'th position.


// 0048 <index>

// Choose parameter <index> as the current active parameter for 0020, 0021 and 0022 instructions.


// 0049 <xRotation> <yRotation> <zRotation> <0> <0> <0> <0> <0> <0> <translation> <offset>

// A transformation is pushed onto the stack and the subroutine at <offset> - 2 B is called. The

//	transformation is popped when the subroutine returns. It consists of (in that order):

//	— a rotation around the z axe by <zRotation> ÷ 65536 × 2pi

//	— a rotation around the x axe by <xRotation> ÷ 65536 × 2pi

//	— a rotation around the y axe by 2pi - <yRotation> ÷ 65536 × 2pi

//	— a translation to the <translation>'th position.


// 004C <color0, color1> <zero, color2>

// Fetch three one-byte color indices for the next Gouraud-shaded triangle. Consider endianness!


// 004E <color0, color1> <color3, color2>

// Fetch four one-byte color indices for the next Gouraud-shaded quad. Consider endianness!


// 004F <position0> <position1> <position2> <position3>

// 0081 <position0> <position1> <position2> <position3>

// Draw a Gouraud-shaded quad with the last four color palette indices. The indices of its vertices'

//	positions are given in clockwise order by <position0>, <position1>, <position2> and <position3>.

I notice as I write this: The difference between both could be the texture mode; 'solid' vs. 'masked'.


// 0053 <number> <base index> (<x> <y> <z>)[<number>]

// Write <number> 3D positions starting at <base index>.


// 0062 <index> <x> <y> <z>

// Write the given 3D position to the given index.


// 0063 <x> <y> <z>

// Write the next 3D position with the given delta to the last one.


// 0064 <x>

// Write the next 3D position with the given delta to the last one.


// 0065 <y>

// Write the next 3D position with the given delta to the last one.


// 0066 <z>

// Write the next 3D position with the given delta to the last one.


// 0067 <x> <y>

// Write the next 3D position with the given delta to the last one.


// 0068 <x> <z>

// Write the next 3D position with the given delta to the last one.


// 0069 <y> <z>

// Write the next 3D position with the given delta to the last one.


// 006A <x> <y> <z> <index>

// Write the 3D position at the given index with the given delta to the last one.


// 006B <x> <index>

// Write the 3D position at the given index with the given delta to the last one.


// 006C <y> <index>

// Write the 3D position at the given index with the given delta to the last one.


// 006D <z> <index>

// Write the 3D position at the given index with the given delta to the last one.


// 006E <x> <y> <index>

// Write the 3D position at the given index with the given delta to the last one.


// 006F <x> <z> <index>

// Write the 3D position at the given index with the given delta to the last one.


// 0070 <y> <z> <index>

// Write the 3D position at the given index with the given delta to the last one.


// 0071 <position0> <position1> <position2>

// Draw a flat-shaded triangle from the positions at the given indices (clockwise) with the same color

//	as the previous one.


// 0072 <position0> <position1> <position2> <position3>

// Draw a flat-shaded quad from the positions at the given indices (clockwise) with the same color as

//	the previous one.


// 0073 <vertices> (<position>)[<vertices>]

// Draw a flat-shaded <vertices>-sided polygon with the same color as the previous flat-shaded

//	primitive. It consists of at least three vertices; its position indices are given in clockwise

//	order.


// 0080 <position0> <position1> <position2>

// Draw a Gouraud-shaded triangle with the last three color palette indices. The indices of its

//	vertices' positions are given in clockwise order by <position0>, <position1> and <position2>.


// 0088 <vertices> for each <vertices>[<index>]

// Draw a textured <vertices>-sided polygon with the last set of texture coordinates. It consists of

//	at least three vertices; its position indices are given in clockwise order. The texture's bytes are

//	interpreted as tranculency information:

//	— transparent (0) to opaque (31) black (used for oil spills)

//	— transparent (32) to opaque (63) white (used for missile trails)


// 008E <vertices> for each <vertices>[<index>]

// Draw a textured <vertices>-sided polygon with the last set of texture coordinates. It consists of

//	at least three vertices; its position indices are given in clockwise order. The texture's bytes are

//	interpreted as indices to the current color palette, except for color 0, which is fully transparent.


// 00A3 <offset>

// If AGP is available, jump <offset> - 2 bytes.


// FFFF

// End of LOD. Should not be reached; break execution and call the debugger.
Uncertain or only partly understood — and also instructions we've understood but are not fully implemented in the viewer yet:
// 0007 <offset>

// If ???, jump <offset> - 2 bytes.


// 001A <unknown> <color> <position0> <position1> <position2>

// Draw a flat-shaded triangle with the color at palette index <color>. The indices of its vertices'

//	positions are given in clockwise order by <position0>, <position1> and <position2>.

// !TODO! find purpose and difference to other "draw triangle"'s.


// 001B <unknown> <color> <position0> <position1> <position2> <position3>

// 003E <unknown> <color> <position0> <position1> <position2> <position3>

// 007E <unknown> <color> <position0> <position1> <position2> <position3>

// Draw a flat-shaded quad with the color at palette index <color>. The indices of its vertices' positions

//	are given in clockwise order by <position0>, <position1>, <position2> and <position3>.

// !TODO! find purpose and differences.


// 0024 <reference> <offset>

// 707.3 >= ???


// 0025 <reference> <offset>

// 707.3 <= ???


// 0026 <reference> <offset>

// avengr.3 Distance= ???


// 0038 <color> <position0> <position1> <position2> <position3>

// 00A2 <color> <position0> <position1> <position2> <position3>

// Draw a flat-shaded quad with the color at palette index <color>. The indices of its vertices'

//	positions are given in clockwise order.

// The exact purpose of these instructions is unknown — they seem to be useful for shadow rendering

//	only; the polygons they render are not visible in the actual game.

just-in-time note: 00A3 is a jump on AGP, so 00A2 could mean "draw an AGP-textured quad". This would

explain why 00A2 draws black quads at the tires: <color> would be the index of the AGP tire texture then

(if such a texture exists, it´s really just a spontaneous idea).


// 003F <unknown> <offset>

// If the lights are on, jump <offset> - 2 bytes.


// 0040 <unknown> <offset>

// a101.3 Same form as 003f, Is the only test value 128 ???


// 0041 <unknown> <offset>

// barracks.3 Same form as 003f, Is the only test value 128 ???


// 0042 <unknown> <offset>

// air_hq.3 Same form as 003f, Is the only test value 4 ???


// 0043 <time of day> <offset>


// 0045 <unknown>[2]

// fact90.3 Same form as 003f, Is the only test value 128 ???


// 004B <unknown> <offset>

// a101.3 Same form as 003f, Is the only test value 3 ???


// 005C <color> <position> <radius>

// anglo.3 sphere ???


// 0061 <number> <offset>


// 0075 <position>

// Mark the position at index <position>, e.g. to place a pylon.


// 0076 <offset>

// abtw_1ra.3 (assume true)


// 007B <offset>

// If ???, jump <offset> - 2 bytes.

// abtw_1ra.3 (assume true)


// 007C <offset>

// If ???, jump <offset> - 2 bytes.

// f22egypt.3 (assume true)


// 0087 <offset>

// If ???, jump <offset> - 2 bytes.

// a101.3 (assume true)


// 0093 <offset>

// If ???, jump <offset> - 2 bytes.

// abtw_1ra.3 (assume true)


// 0095 <unknown> <color> <position>

// 707.3 Light, maybe off, associated with 0033 ???


// 0098 <unknown>

// Transparency level


// 009D <position0> <position1> <position2> <position3>

// Draw a quad. The indices of its vertices' positions are given in clockwise order by <position0>,

//	<position1>, <position2> and <position3>. If texture shading is set in the options menu, the

//	triangle is drawn texture-shaded with the current surface material in "red****.ini". Otherwise, the

//	triangle is drawn Gouraud-shaded with the last four colors.


// 009F <unknown> <surface> <type> <color0> ... <colorN>

// Fetch the surface texture index and the color indices (needed if textures are disabled in the options

//	menu) of a polygon. The number of colors depends on <type>:

//	— 0103: one color for a flat-shaded quad.

//	— 0301: three colors for a Gouraud-shaded triangle.

//	— 0401: four colors for a Gouraud-shaded quad.

//	— 0900: !TODO!
Unknown / not implemented at all:
// 0031 <unknown>[6]


// 0037 <unknown>

// a50.3 Some action like 0030 ??? Should be safe to ignore to see what happens.


// 004A <unknown>


// 004D <unknown>[3]

// OK


// 0051 <unknown>[2]


// 0052 <unknown>[3]

// aswan_j.3 Separate scale in XYZ ???


// 0054

// newhoriz.3 Found at start of certain files. Ignore unless it expects a terminator.


// 005D <unknown>[4]

// contrail.3 sphere ???


// 005D <number> (<unknown0> <unknown1> <unknown2>)[<number>]


// 0060 <number> (<unknown0> <unknown1> <unknown2> <unknown3>)[<number>]

// car.3 Used for parachutes ???


// 0077 <unknown>[9]

// car.3 Used for parachutes ???


// 007F <unknown>[6]


// 0083 <unknown>[4]

// aihq_180.3  No idea, terminated by 0084 ???


// 0084

// (terminates 0083)


// 0086 <unknown>[2]

// f22egypt.3 Similar to 002d, related to parameter 0003 in F22 ???


// 0086 <unknown>[4]

// awc_ef20.3 OK


// 0094 <unknown>[2]

// awc_f14.3 May need to move to unknown jumps section ???


// 0096 <unknown>[3]

// 707.3 Light, maybe off, associated with 0034 ???


// 00A7 <unknown>[3]

// atgtrail.3 Sets AGP 24 bit colour


// 00A8

// (terminates 00a7)

Sum: 50 mostly or fully implemented, 49 not. I'll see that I implement sphere rendering, so this finally comes to something like 53:46 :)

Again, I want to thank you for your help. This is certainly an enormeous knowledge base already! :thumbsup:

Share this post


Link to post
Share on other sites

...and thank you for your help. We've certainly jumped forward in the last few weeks. :thumbsup:

We're only at the 50% point though? Ouch.

I haven't been able to connect 00a2 with AGP, despite it being in the middle of similiarly numbered opcodes. There is a option called 'F22 Shadows' which it may be something to do with.

Share this post


Link to post
Share on other sites

We're only at the 50% point though? Ouch.

Well, you are certainly farther :) It's just that I don't count instructions until they're in the viewer and definitely working; the BUILD_TEXTURES instructions are an example of this. We know how they work, but I couldn't verify that yet.

I had to disable my "first 0075 is base offset" hack as there were weird problems with para.3 and some planes. It's a pity; but well, sooner or later I'll have to write the SSD parser anyway.

I just implemented these three:

// 001A <unknown> <color> <position0> <position1> <position2>

// Draw a flat-shaded, semi-transparent triangle with the color at palette index <color>. The indices of

//	its vertices' positions are given in clockwise order by <position0>, <position1> and <position2>.
Since we have no actual glide screenshots of the effect, I had to guess it's semi-transparent. It does, however, look alright. The transparency requires anti-aliasing being enabled, though.
// 005C <color> <position> <radius>

// Draw a flat-shaded sphere of the color at palette index <color> and a radius of <radius> at the

//	<position>'th position.


// 005F <number> (<color> <position> <radius>)[<number>]

// Draw <number> flat-shaded spheres, each with of the color at palette index <color> and a radius of

//	<radius> at the <position>'th position.

They work well on ships and para.3.

So it's 53:46 now :) Here's the patch:

http://www.mediafire.com/?xejbqnx6kgdieje

Share this post


Link to post
Share on other sites

Great, thanks.

I've been looking at 0024 and 0025 and not really getting anywhere. They are mostly used on planes, but the only visible change in the viewer is with the awc_xx.3 files, like this extract from awc_c747.3:

0054; 002400000016    ;  Comparison with (0), Jump to line 59

0055; 002400010628    ;  Comparison with (1), Jump to line 253

0056; 00240002092e    ;  Comparison with (2), Jump to line 350

0057; 002500020310    ;  Comparison with (2), Jump to line 156

0058; 0000    ;
which changes the colour of the model. I can't remember what these models are used for, although I guess it's something to do with AWACS mode. In this case it would seem that 0024 means '=' and 0025 '>', but this sequence from a101.3 tends to dispute that:
0052; 00480000    ;

0053; 002400040040    ;  Comparison with (4), Jump to line 66

0054; 00240005003a    ;  Comparison with (5), Jump to line 66

0055; 00480000    ;

0056; 00240004000a    ;  Comparison with (4), Jump to line 59

0057; 002400050004    ;  Comparison with (5), Jump to line 59

0058; 0000    ;

0059; 003f00800010    ;  If 003f (Time??) test(128), Jump to line 63

0060; 0033000b002b    ; Light (Long range): Palette:11  Vertex: 43

0061; 00330002002c    ; Light (Long range): Palette:2  Vertex: 44

0062; 0000    ;

0063; 00950005000b002b    ;

0064; 009500050002002c    ;

0065; 0000    ;

0066; 003f00800010    ;  If 003f (Time??) test(128), Jump to line 70

0067; 0033000b0022    ; Light (Long range): Palette:11  Vertex: 34

0068; 0033000b0021    ; Light (Long range): Palette:11  Vertex: 33

0069; 0000    ;

0070; 00950005000b0022    ;

0071; 00950005000b0021    ;

0072; 0000    ;

This would appear to have something to do with lights, and as parameter 0000 deals with the landing gear, it may be landing light related. I haven't got a clue what's being compared though.

0025 occurs on a few buildings eg ammobild.3 , and doesn't seem to be associated with any 0048 line.

Share this post


Link to post
Share on other sites

I think these models are used for plane symbols in AWAC mode, indeed.

I see another problem with the awc_* files: If you open awc_767.3, you will notice that adjusting parameter 0 has an effect on color even though it is marked 'idle'. Further investigating, I found this:

0040; 002100000010    ; If Parameter NONE = 0 then jump to line 44

0041; 002100010246    ; If Parameter NONE = 1 then jump to line 115

0042; 00220001047c    ; If Parameter NONE > 1 then jump to line 186

One of the parameters is set by default (without any preceding 0048), and adjusting it causes the same color change that adjusting 0024 causes in awc_c747.3. Could it be possible that these two are linked or even check for the same parameter in different ways?

Even if not: We need to find out what parameter is set by default, because your script doesn't register changes with it and may therefore have skipped a few parameter effects.

Share this post


Link to post
Share on other sites

Ah, you've noticed where the 'Parameter' theory breaks down slightly. <_<

This is why I suggested that you default the 0048 index to zero, so at least we can see what happens.

I notice that awc_767 doesn't contain any 0024 opcodes, but the 0021s seem to do the same job which supports your theory. Not sure it works for the other models like a101 though.

Share this post


Link to post
Share on other sites

Just a quick update on the viewer:

I merged vertex transformation with program logic (it was done on the GPU before) and now the visibility tests have significandly improved, i.e.: there are no more glitches, neither in the rotated "90" and "180" models nor when models are viewed from very close distance.

I also tried to implement 0052, of which we suspected it was a separate scale factor for each axis. Well, it looks a little more complicated — here's aswan_j.3 with a nonzero 0007 parameter:

scaleg.png

The polygons change their tiles when you change the point of view. I couldn't find any sense in that :(

Also, we're still missing vertices. Some models (pomornk.3, tornado.3 with open canopy) reference vertices which are not in my buffers. This has some strange effects, e.g. flickering or stripes through the mesh.

I know I can find the total number of vertices at the beginning of each LOD, but I'm afraid if I implement an out-of-bounds check then many models will stop working. We'll have to work this out; there's gotta be more geometry opcodes. What about the "repeat previous instruction" opcode I've read on in the TAW Wiki?

Finally: Has anyone tried to load EF2000 .3 files in the viewer? I don't own EF2000, so I could never try it.

Share this post


Link to post
Share on other sites

The polygons change their tiles when you change the point of view. I couldn't find any sense in that :(

Also, we're still missing vertices. Some models (pomornk.3, tornado.3 with open canopy) reference vertices which are not in my buffers. This has some strange effects, e.g. flickering or stripes through the mesh.

I know I can find the total number of vertices at the beginning of each LOD, but I'm afraid if I implement an out-of-bounds check then many models will stop working. We'll have to work this out; there's gotta be more geometry opcodes. What about the "repeat previous instruction" opcode I've read on in the TAW Wiki?

Oh my :o

The "repeat previous instruction" opcode you read on the TAW Wiki would be 0071 which draws a flat-shaded triangle from the positions at the given indices using the same color index as the previous one, however, I thought you were comfortable with that and had already included it in the viewer?

The only thought I came up with on explaining the P.O.V. transformation and 0052 is considering the possibility this is related to the implementation of head tracking/Virtual 3D, using equipment like Union Reality head gear. D.I.D. promoted this feature in TAW and included a separate executable. :unsure:

Share this post


Link to post
Share on other sites

EF2000 files range from rendering fine to crashing the viewer. I would say that,of the files I've looked at, the majority have problems.

While TAW's opcodes can be regarded as a superset of the earlier games, there are a few differences which are having a bad effect on the viewer.

If I get time today I'll look into 0052. Unfortunately, I have to do other things first. :(

Share this post


Link to post
Share on other sites

AGP textures :)

agp.png

I consider the 00A7 and 00A8 instructions fully implemented:

// 00A7 <r> <g> <b>

// Enables blending of 'transparent' textures with the given 8-bpc sRGB color. Available in AGP mode

//	only; usually followed by a 00A8 terminator.


// 00A8

// Disables 00A7.

55:44 ;)

P.S.: I noticed, the 004B flags enables and disables transparent smoke. Could there be any other options related? Would be nice if we could solve this flag's meaning.

Share this post


Link to post
Share on other sites

Nice!

I've done a quick scan for 0052 and it's present in 60 or so files, but can't see any real pattern. The 0052 is immediately followed by 3 words which range in value from 0x0009 to 0x0010.

Probably need to change some values to see what happens in-game.

Share this post


Link to post
Share on other sites

P.S.: I noticed, the 004B flags enables and disables transparent smoke. Could there be any other options related? Would be nice if we could solve this flag's meaning.

There's a bunch of these, which have the opcode, some mask value, then a jump:

003f;707.3        Lights on/off, Test for values, 128,64,4 (j707 contains both 128 & 64) 

0040;a101.3       Same form as 003f, Test for value 128 only 

0041;barracks.3   Same form as 003f, Test for value 128 only 

0042;air_hq.3     Same form as 003f, Test for values 0,4,128 

0045;fact90.3     Same form as 003f, Test for value 128 only 

004b;a101.3       Same form as 003f, Test for values 2,3 

EDIT

...and 0043 which has to do with time of day.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...