Jump to content
COMBATSIM Forum
Krycztij

TAW terrain format

Recommended Posts

Oh yes, I forgot they all test for flags m[

This is interesting indeed. Another thing I found out: The pilot heads in airplanes are not drawn without 004b. Smoke and pilot heads have in common that they're both sprites, so the mask oooo11o could be responsible for sprite rendering.

One thing I'll immediately look at is, how these sprites are drawn. I have a bad feeling this could mean another major cut in the transformation pipeline, so I want to get it done as quick as possible.

Also, I'm glad the "repeat previous" instruction in the wiki is just a false guess. I really don't have an idea how I would have implemented it :)

Edit: This is a desaster. The tagged lines draw the pilot (taken from harrier.3 and f15.3):

	0008 call 242 B

	0062 write XYZ #232: 0 -90 372

	0075 mark important position 0 -90 372

	002D draw submesh at 4B with XYZ offset 0 -90 372

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

>>	0062 write XYZ #216: 12 -12 0

>>	0064 write XYZ #217 with X delta: -12 -12 0

>>	006C write XYZ #219 with Y delta: -12 18 0

>>	006B write XYZ #218 with X delta: 12 18 0

>>	0061 ??? (216/2)

>>	0075 mark important position -12 18 0

>>	0075 mark important position 12 18 0

>>	0047 write polygon UV: texture 5; 177/191 121/191 121/125 177/125

>>	008E draw textured polygon: 218-219-217-216

	0000 return

	0000 return

There is nothing special whatsoever — the 008E instruction is used for many masked polygons. 0061 just updates the buffers and 0075 is used everywhere throughout the file. I have no clue how the engine works out that this exact polygon has to face the viewer. I would have guessed that when a 004B evaluates true, the renderer is set to "sprite mode" … but there is no terminator and no additional return instruction which would cause a reset to the normal mode.

Share this post


Link to post
Share on other sites

Got it!

004B is not a jump, it's a call (just like 002D draw displaced submesh and 0049 draw transformed submesh). It pushes a new rotation onto the transformation stack, which causes the negative Z axis to always face the viewer, and calls a submesh. The rest is just like with 0008, 002D and 0049 — the transformation is popped upon the next 0000 return instruction. The above snippet gets another 0000 return instruction then (it was just our luck that it worked with a jump instead of a call).

I'll try to implement it; you'll get screenshots then.

Share this post


Link to post
Share on other sites

It works. Here's a nice little smoke puff:

smokeu.png

And this pjlot articulates his joy by directly looking at us:

pilot.png

Although we don't know yet what exactly the global flags at bits #2 and #3 mean, I consider this instruction decoded:

// 004B <mask> <offset>

// If a bitwise AND of <mask> with the global flags evaluates nonzero, then a transformation is pushed

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

//	left 3×3 elements of the world and view matrix to identity, which causes the submesh to always face

//	the viewer. It is popped when the subroutine returns.

// This instruction is used to check if sprites are enabled and, if so, to render them.

56:43.

Share this post


Link to post
Share on other sites

Good to see someone is having some success!

I've been looking at 0052 and the file f22_39.3 which has a couple of 0052 opcodes in it. This is the port upper engine nozzle of the F22, which makes it convenient to experiment on.

Anyway, I can change this line:

0052000e000c000e to 0052000000000000 or 0052ffffffffffff and it makes absolutely no visible difference in software or Glide mode.

So, on this evidence, 0052 does nothing in TAW.

So, maybe we should just ignore it for now?

Share this post


Link to post
Share on other sites

So, maybe we should just ignore it for now?

I'm okay with that!

I tested making a call out of 003F, too. I do indeed have less errors and flickering now. I also think it's the difference between lights (like streetlights) and normal geometry (like the parachute): 003F sets the renderer to some kind of "lighting" mode which is left with the next 0000 return instruction.

I'll have to go through all 003F-like instruction and see if they are calls, too. This should fix a lot of problems with missing vertices I still have.

Share this post


Link to post
Share on other sites

Tried changing the vertex value of the 004a opcode, with no effect seen in the game. So we can ignore this as well for the time being.

Moving on to 0077, I don't have access to the game right now, but have listed where this opcode occurs:

aswan_j.3 2807; 0077000000000000000000000000000000000000

dam_1.3 3433; 0077000000000000000000000000000000000000

dam_2.3 3385; 0077000000000000000000000000000000000000

ferry.3 2245; 0077000000000000000000000000000000000000

hopital.3 1868; 0077000000000000000000000000000000000000

ib_spray.3 0137; 0077000000000000000000000000000000000000

kuzntsov.3 3090; 0077000000000000000000000000000000000000

spytrawl.3 0989; 0077000000000000000000000000000000000000

trawler.3 0901; 0077000000000000000000000000000000000000

type23.3 2607; 0077000000000000000000000000000000000000

udaloy.3 2975; 0077000000000000000000000000000000000000

usa_oilb.3 1625; 0077000000000000000000000000000000000000

usa_oils.3 1574; 0077000000000000000000000000000000000000

So, we have some dams and some ships, with the only obvious common factor being some sort of water effect from the ship or broken dam.

I had thought maybe those zeros are a placeholder for some parameters coming in from outside (as I assumed for the middle section of 0049), but that's now unlikely.

I'd like to put this on the ignore list, but really need to do some in-game experiments first.

Share this post


Link to post
Share on other sites

0031 occurs just once and I feel that this is some sort of aberration.

It's in the file ses.3:

2086; 0031000500c400ba00c400c400c4    ;

2087; 008100830016004a0082    ; Gouroud Shaded Quad, Palette:180,189,195,185  Vertices: 131,22,74,130

2088; 004ebac3c3ba    ; Quad Vertex Colours:186,195,195,186

2089; 0081001500830082004b    ; Gouroud Shaded Quad, Palette:186,195,195,186  Vertices: 21,131,130,75

I've always assumed that a 0081 quad is always preceded by 004e which sets the colours, but in this case, the 0031 is taking it's place.

0031 seems to define 5 colours, which doesn't make sense for a quad.

The only consequence I can see is that the quad at line 2087 might not be drawn with the correct colours. My parser seems to give this quad some colours from previously encountered 004e.

Share this post


Link to post
Share on other sites

First of all: With the other 003F-like instructions being treated not as jumps but as calls, we see a lot more geometry in some places, although the artifacts and vertex misses have not reduced. But, for instance, building shadows are rendered now :)

Tried changing the vertex value of the 004a opcode, with no effect seen in the game. So we can ignore this as well for the time being.

Alright.

Moving on to 0077 […] I'd like to put this on the ignore list, but really need to do some in-game experiments first.

O.K. — from looking at the listing, I have no idea what it does either. It is the same number of padding words as in the draw transformed submesh instruction, so this could well mean a special transformation being applied.

0031 occurs just once and I feel that this is some sort of aberration.

It's in the file ses.3:

2086; 0031000500c400ba00c400c400c4    ;

2087; 008100830016004a0082    ; Gouroud Shaded Quad, Palette:180,189,195,185  Vertices: 131,22,74,130

2088; 004ebac3c3ba    ; Quad Vertex Colours:186,195,195,186

2089; 0081001500830082004b    ; Gouroud Shaded Quad, Palette:186,195,195,186  Vertices: 21,131,130,75

I've always assumed that a 0081 quad is always preceded by 004e which sets the colours, but in this case, the 0031 is taking it's place.

0031 seems to define 5 colours, which doesn't make sense for a quad.

The only consequence I can see is that the quad at line 2087 might not be drawn with the correct colours. My parser seems to give this quad some colours from previously encountered 004e.

Now, this is a great find :thumbsup:

Here are some views on ses.3:

  • 0031's last four values interpreted as quad colors
  • 0031 ignored and previous quad colors recycled
  • in-game with dgVoodoo glide wrapper (software doesn't work here)

ses.png

This absolutely looks to me like the engine just ignores 0031. Even more: It does not recycle the previous four quad colors, it just uses black to fill the missing colors. This could be the proof that TAW doesn't write vertex colors and texture coordinates to an infinite array, but instead pushes them onto a stack and pops them when they're read – and if the stack underruns, black is used to fill in.

Does your TAW run in software mode? If so, could you please take a screenshot of the destroyed SES? Because if the quad is black there, too, this is the ultimate proof that I'm correct with my assumption on how TAW stores vertex colors (and texture coordinates) and I could finally rewrite this part :) (My software mode just produces very colorful garbage :( )

Share this post


Link to post
Share on other sites

OK, I'll do that when I get home.

Now looking at 0051, and there may be geometry implications here, eg f22usa1:

4005; 0062027ffd800044fe70    ; Vertex :639  X=-640  Y=-68  Z=-400

4006; 0075027f    ;

4007; 0051027f0000    ;

4008; 0000    ;

4009; 0062028002800044fe70    ; Vertex :640  X=640  Y=-68  Z=-400

4010; 00750280    ;

4011; 005102800002    ;

4012; 0000    ;

4013; 00620281fe700044fee8    ; Vertex :641  X=-400  Y=-68  Z=-280

4014; 00750281    ;

4015; 005102810004    ;

4016; 0000    ;

..

..

We start with a 0062 to define a vertex. Then we have a 0075 opcode for the same vertex, then a 0051 which applies 'something' to the vertex.

This opcode is used a lot, but only on planes....and could explain some of your missing vertices.

May be related to canopies, but needs further investigation.

Share this post


Link to post
Share on other sites
We start with a 0062 to define a vertex. Then we have a 0075 opcode for the same vertex, then a 0051 which applies 'something' to the vertex.

Actually, it applies pylon models. Just dropped green lights at the 0051 vertices:

py1.png

py2k.png

So, it's very similar to 0075. I think 0075 marks spawn positions of flying weapons, chaff, smoke puffs, etc and 0051 marks base positions of pylon models. Let's postpone both until SSDs are decoded (I'm sure the SSD binds actions to individual 0075 and 0051 markers).

Share this post


Link to post
Share on other sites

It sure helps being able to visualize stuff so quickly. :thumbsup:

Could you do the same exercise for opcode 0086? This is only used on the highest LOD F22 models and is of the same form as 0051.

Share this post


Link to post
Share on other sites

Thank you! That explains a lot.

Could the one marked '???' be the origin of the canopy? That assumes the dot can be seen through the fuselage

Share this post


Link to post
Share on other sites

Could the one marked '???' be the origin of the canopy? That assumes the dot can be seen through the fuselage

No, it is on both sides just above the AIM-9 weapon bays. I thought it could be the origins of the vapor vortex above the wings, but the points disappear when seen from above :/

Any other instructions to test?

By the way: There's only 14 instructions left of which we don't have a clue at all. :thumbsup:

Share this post


Link to post
Share on other sites

Heh, we're fast running out of instructions. <_<

Looking at 0094, but have no idea what it does. This bit of f22usa1 shows it in action:

4315; 00070010    ; If 0007 flag set, jump to line 4318

4316; 002f0004021f02200221021e    ; Texture = cam3_9

4317; 0000    ;

4318; 0094001effee    ;

4319; 0000    ;

Possible interpretations:

1. "If some option is set then call the 0094 at line 4318, then return and draw the polygon at line 4316"

2. "If option is true then do the 0094, if false then draw the 002f"

3. Something else

Share this post


Link to post
Share on other sites

Well: I have modified 0007 to a call instead of a jump and it does not crash. This could mean that it indeed is a call (because if it wasn't, we'd have less 0000 return instructions than calls and the processor would run into the FFFF end of LOD instruction sooner or later). But there are no visible enhancements (nothing more visible than before). And now, para.3 and crate.3 show strange symptoms:

paray.png

I guess it's the following: 0007 is a jump and treating it as a call does not run into the end of LOD markers because there is another, yet unknown call mistreated as a jump (so we still have enough accidential 0000 returns left before reaching FFFF). It does, however, run us into states within the same LOD which were not meant to be reached.

While looking for 0007's effects, I also found zaim120r.3 with nonzero parameters 5 & 6 is rendered in strange colors:

texcol.png

Any idea on that? As seen on the previous page, AGP texture colors do work well on F-22 position and landing lights :(

Share this post


Link to post
Share on other sites

Opcode 0037 only occurs at one place in two files:

a50.3 0448; 0037001c    ;

awc_a50.3 0448; 0037001c    ;
As these files are identical, that's only one occurrence. It's at the end of the vertex descriptors for the rotating radome. Any ideas?
0429; 006200800011ffe7001d    ; Vertex :128  X=17  Y=25  Z=29

0430; 0066ffc6    ; Vertex :129  X=17  Y=25  Z=-29

0431; 0064ffde    ; Vertex :130  X=-17  Y=25  Z=-29

0432; 0066003a    ; Vertex :131  X=-17  Y=25  Z=29

0433; 0068002efff4    ; Vertex :132  X=29  Y=25  Z=17

0434; 0066ffde    ; Vertex :133  X=29  Y=25  Z=-17

0435; 0064ffc6    ; Vertex :134  X=-29  Y=25  Z=-17

0436; 00660022    ; Vertex :135  X=-29  Y=25  Z=17

0437; 0068001d0011    ; Vertex :136  X=0  Y=25  Z=34

0438; 0066ffbc    ; Vertex :137  X=0  Y=25  Z=-34

0439; 006900040022    ; Vertex :138  X=0  Y=21  Z=0

0440; 0065fff8    ; Vertex :139  X=0  Y=29  Z=0

0441; 0067ffde0004    ; Vertex :140  X=-34  Y=25  Z=0

0442; 00640044    ; Vertex :141  X=34  Y=25  Z=0

0443; 0063ffe3fffdfffa    ; Vertex :142  X=5  Y=28  Z=-6

0444; 00650006    ; Vertex :143  X=5  Y=22  Z=-6

0445; 0068fff6000b    ; Vertex :144  X=-5  Y=22  Z=5

0446; 0065fffa    ; Vertex :145  X=-5  Y=28  Z=5

0447; 006100120080    ;

0448; 0037001c    ; <-------------------------------------------

0449; 004cbabac000    ; Triangle Vertex Colours:186,186,192

0450; 008000800088008a    ; Gouroud Shaded Triangle, Palette:186,186,192  Vertices: 128,136,138

Share this post


Link to post
Share on other sites

I've looked through the parsed zaim120r but not sure what's happening with the colours. Maybe that blue halo is only meant to be seen for a very short time, like immediately after launch for example.

Share this post


Link to post
Share on other sites

Well, I'm really shocked by 0037.

This is the A50 with 0037 FF1C:

a502.png

And now with the vanilla 0037 001C:

a501.png

What the …?!?

Can you reproduce that? Did I accidentially fix something?! It renders wrong with the original 001C, but correct with FF1C?!

Could it be, my 'extracted' files are not only extracted, but someone already modded them?

Also, you are right with the AMRAAM. The green flash is just visible at the start; the cruise glare is controlled via parameter #14 and is the same color as the trail — blue. Looks better, but I still think green and blue are strange here.

Share this post


Link to post
Share on other sites

I modified sea.3 by overwriting one of the 0008 call instructions with 0037 001C. This, of course, caused less polygons to be rendered because a call was missing, but half of the tile was still there (I verified it in 3View). Then I fired up a sea-based mission and this is the result:

fogag.jpg

I can definitely say: 0037 controls fog. It might be some coefficient for the distance, or just the index of the fog color, or something more complicated. But it definitely has to do with fogging, at least in the glide version.

Share this post


Link to post
Share on other sites

Some quick observations:

In software mode, that polygon in the dead SES is black like your third picture.

I can also confirm your A-50 results. At first I didn't see a problem, but then I realised I had fog disabled in the Glide wrapper. Strange....

Share this post


Link to post
Share on other sites

Got it: The 0037 parameter is a divisor for the fog distance (or a multiplicator for a vertex's fog coefficient, if you want to look at it the other way).

The usage is the following: If the fog distance is 6000 units, and you want a small object like a missile appear from fog at a distance of 60 units right before you, you set the 0037 parameter to 6000 / 60 = 100. You must also take care that the object is not drawn if it is farther than 60 units away from the viewer, because the vertex fog is not clamped and will repeat itself un-fogged at 61 units, become fogged again at 120, etc.

The parameter must not be set to zero, or a "division overflow" will occur.

Proof with 0037 0001:

62332034.th.jpg

0002:

35358674.th.jpg

0003:

60657629.th.jpg

0004:

74435806.th.jpg

0010:

25696062.th.jpg

I consider it solved but not implemented. If this instruction is indeed nowhere used but in the A-50 files, we can safely ignore it. On the other hand, if we want to mimic TAW's engine as close as possible, we should implement it (maybe EF2000 or F-22 ADF make heavy use of it?) …

Share this post


Link to post
Share on other sites

If this instruction is indeed nowhere used but in the A-50 files, we can safely ignore it. I consider it solved.

Good work! Yes, it only occurs in the A-50.

I just went back to a unmodded/unextracted install and the issue is still there. So, we can fix an original bug. :thumbsup:

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...