[Eurofighter Typhoon]

Yep. It's laying around somewhere at home, and I played only twice or thrice. Hunt himself talks a lot about how amazing it was to write TAW's dynamic campaign in only nine months. IIRC, he also wrote ACME. If I were rich, I'd hire him for TFXplorer

[Eurofighter Typhoon]

Nice. Someone tell all the guys writing "this needs a remake" about EF2000 Reloaded!

[TAW terrain format]

Okay, so I fixed the shock diamonds, and it didn't have to do with 0052. It was the scale factor in the renderer that had to be carried over for all sub-shapes (just the transformation matrix is not enough). But of course it's just for sub-shapes, supershapes always initialize it to 1, no matter what scale factor they use. And I now always zero the Z axis once 004B is encountered.

So, 0052 does not affect the shock diamonds but only the afterburner mesh. I don't know why one would want that for now, afterburners look alright with my code, but I'm sure I'll find out about bizarre reasons once my code breaks in a subtle way

Gotta go to bed. At least, TFXplorer has nice sprites and afterburners now.

[TAW terrain format]

I'm waist deep wading into TAW static mesh creations and can't afford to overlook opcode 0052. Transformation bounding box determinants or perhaps shear mapping transformations on the mesh...

It's not clear to me yet, how the displacements are calculated, any suggestions and I'm all ears

Same here. I've noticed considerable graphics errors with the shock diamonds on the F-22 model in TFXplorer, and I think they have to do with 0052.

0052 in some way alters the transformation matrix, and I'm not sure how. My thoughts:

1. It's a bit mask. It is NOT a number. (Same in the unknown 004B parameter.) I think this because of the high number of bits set (values are often 3, 14, 15 – 11, 1110, 1111 binary).
2. I guess it's masks for the transformation matrix. There's 16 bits, and the 4×4 matrices commonly used in 3D graphics have 16 entries.

One very strong indication is the 004B (stare into the camera) opcode which seems to also have a bit mask. I see the value 0003, i.e. 0…00011 binary. Now if I leave columns [0] and [1] of my matrix the way they are (bits [0] and [1] are set), and set column [2] to zero (bit [2] is zero), the rendering becomes much better than it was.

Still, the scaling is wrong, and that's where I think 0052 comes into play. Seems like it scales the model down, but it scales the distance from the viewer in just the same way. It looks the same on the screen, but it'll change Z buffering entirely.

And that's an important point for horizon files: First thing I noticed after implementing Z buffer was, the horizon occluded all my precious terrain. I suspect they used 0052 to make it be close, look infinitely far away, but behave very different in terms of Z buffering.

I'll report back with my progress.

[TAW terrain format]

Great find!

But no idea how to implement it in 3view yet. I mean – when I encounter it, I'll have to switch to glossy material. Alright. But when stop and switch back to normal material? When the specified number of bytes has been interpreted? That'll be an additional comparison on each opcode, and the impact might be in 5–10 % frame rate drop for TFXplorer … just for the canopy

I gotta think about that. Oh if I only knew how complicated DID's source codes were in the end …

[TAW terrain format]

Just found out: The 0051 opcode is basically the same as 0086, except that it will only index slots 0–22. These are the slots with weapon models. For example, slot [7] is the F-22's outer weapon pylons (left and right); slot [8] is the inner pylons. I'm going to populate the plane with weapons now

Edit: Oh no there IS a difference: Values in 0086 are multiples of four; values in 0051 are multiples of two … so, [14–17] are the pylons.

I just found some decoy drones on my plane

I see 14 pylons for the F-22:

1. outer left pylon
2. outer right pylon
3. inner left pylon
4. inner right pylon
5. left weapons bay
6. right weapons bay
7. center weapons bay; missile on the outer left
8. center weapons bay; missile on the outer right
9. center weapons bay; missile in the left middle
10. center weapons bay; missile in the right middle
11. center weapons bay; missile on the inner left
12. center weapons bay; missile on the inner right
13. center weapons bay, left bomb
14. center weapons bay, right bomb

[TAW terrain format]

Great help, thanks!

Adding tipjoins and lerx's, I notice the textures being wrong, because the shapes use another default texture than the major F-22 shape.

Naturally I need to add two new parameters to all my rendering functions because the texture must be swapped right in the middle of executing shape bytecode, and must be swapped back later. No chance to write clean code

But at least it'll look great when it's done, I hope …

[TAW terrain format]

Oh I remember – it was that scary bytecode I never dared to decode!

That'll keep me busy for some weeks I guess :-)

[TAW terrain format]

Great! I also had a quick look at 008D (draws afterburners) and it seems to me like the 3rd point of the triangle is always the one far away from the engine. So I did some cosmetics to my code:

I've also parsed the COLLISION_BOXES block of SSDs (just parsed it, didn't interpret anything). Any ideas on how the data is encoded?

[TAW terrain format]

OK, so … the format is

0086 <position> <index>

with <position> being the index of a point on the stack. Seems unused, at least it renders fine for me without that. Use this point as origin for the new transformation (but keep the rotation); otherwise, nozzles won't render properly.

<index> is more complicated. There is a set of shape references, an array of ~50 for the player F-22. Many entries are shapes to render (e.g. rudders, elevators, etc.), but not all entries are used. <index> must be divided by four (in the original implementation, it might have been an offset into an array of 4-byte pointer values).

For convenience, the array is easy to populate for the F-22: f22_23.3 goes to position [23], f22_24.3 goes to [24], and so on. I don't know if other models are similar, the list might come from the SSDs as well …

(I forgot to set shape parameter #10 to the correct camouflage.)

[TAW terrain format]

I now understand the 0086 opcode in the shapes: It's "draw another shape with the current transformation". It will make my renderer even more messy

Mike, is there a list of all files with this opcode occuring?

[TAW terrain format]

Unsure until I see it in motion. Looks like an offset to the W coordinate; probably to adjust depth buffering of the model …

[TAW-3D]

Well Direct3D with pixel shader 2 has pretty limited capabilities regarding inter-polygon dependencies, but I'll think about how I get this working.

[TAW-3D]

Are you sure it's displacement? Looks like a height map for hardware bump mapping ("dot3") to me … impressive nontheless

[TAW terrain format]

This looks so awesome, DKD. Very well done. I wish I had time to try it out :-(

[Bridge Too Far]

Similar to 0020?

If the currently active parameter is below <reference>

Great, got it!

I'll try to upload an updated build to the box for you. Sorry DKD, no luck. My girlfriend's system does not have Visual Studio 2010 installed, so I can't build the XP-compatible 32-bit version. The Vista-and-above 64-bit version is all I can give you until I'm back at my system in a few weeks … Also there is no TFXplorer update because I screwed up flight physics pretty bad.

[Bridge Too Far]

I can't find "noname11132.3"; maybe my files are outdated (I don't have the tools with me right now). I tried to load "noname11131.3" and it shows the same characteristics (TFX 2 shape, unknown instruction). It was pretty stupid of me to not include information about WHICH unknown instruction was encountered WHERE, but in 11131, it is the "0023" opcode at the 1934th word (3868 B ) into the file.

Any ideas on 0023? I'm sure Mike had it parsed before, but I don't have his scripts with me.

[Bridge Too Far]

IIRC, even 3View doesn't yet handle the 0024/0025 instruction set the way it's used in that object file, although I am now anticipating a revision .

In case the current 3View build does not handle that correctly, just leave a note here and I'll check. What was the bridge file's name? #11132?

(0024/0025 are implemented as calls in 3View, and in the source code that is commented as tested.)

[Bridge Too Far]

GREAT! Thank you

[TAW terrain format]

The default TAW engine imposes a great number of limits on the program which had to be overcome. For example, airbases are limited to a total of 102, ROAD and RAIL activations are limited to 29 each, per NATION, Border geographic and political points are limited to 40, and SAM Points are limited to 100 (see the 63h in the below image). I have greatly expanded most those limits.

Below is an example of the method I used to access the limiting data:

I'm surprised (in a positive way) that TAW doesn't crash then. I'll have to consider this in TFXplorer …

Like HF said, you're not posting to yourself. I'm just very busy with my family …

[ALT + TAB can be fatal ....]

The correct process is PAUSE (&lt;p&gt;) .... Options Menu (&lt;SHF&gt; + &lt;O&gt;) .... and &lt;ALT&gt; + &lt;TAB&gt; to the desktop.

Isn't NUMPAD DEL, ALT+TAB easier? That's what I use :-)

[TAW terrain format]

Me too. I'm too busy right now to implement good stuff, but what you write here is invaluable!

[TAW terrain format]

I don't see how 2Bxx could work. As far as I can see, ctclfc_1.3 and ctclfc_4.3 have identical 2Bxx blocks, but are rotated differently …

[TAW terrain format]

I have a number of those to contend with in the new world I just completed, I assumed these were transformation errors.

Hardware project update: corrections and clarifications

2BXX, is a transformation process using the [transtxtr] texture transformation matrix index, found in the initialization file: hardware.ini.

The flag has not yet been found, therefore I performed the transformations manually on the recently discovered hardware.tm textures, exclusively and created a completely new implementation for texturing the worlds.

I'll use dunesi_4.3 as the example:

Header section: 215445585F3131002B5209080B0A02030001000000

The normally used header texture is designated (ASCII) as tex_11, and maps the lower left quadrant:

If 2BXX is activated it skips the header texture and uses:

002B5209080B0A02030001

The texture is 52 which points to the global textures index # 82 in hardware.ini:

82=tex_3

hardware.tm/ tex_3.tm:

09080B0A02030001:

09080B0A is the Texture Destination.

02030001 is the texture Source.

Using the byte order and the [transtxtr] index we can determine the texture transformations requested.

[transtxtr] index in a visual quad format:

The source transformation = 02030001: Horiz-flp + Vert flp

Then the Translation from upper L quad (0123) to lower L quad (89AB)

The destination transformation = 09080B0A: Horiz-flp

Now we have gone from the original hardware.tm/ tex_3.tm (above), to:

One of the advantages of 2BXX is that it reduces the number of textures necessary to tile the world terrain by at least half.

Take, for example, the textures used for simple desert and dunes:

Considering each (96 x 96) texture quadrant on a given TAW texture map, the hardware (transformation) process uses one texture (tex_3/ quadrant A) compared to ten textures used in the standard mapping process.

It appears this offloads much of the task from software to hardware.

The texture outcome of the manual transformations/ hardware.tm application in the smaller seaworld model delivered a very nice result which is similar in some ways to the seaworld with standard textures. There are some significant differences. Also, I did notice a minor number of annoyances, like the one Krycztij posted above, hopefully those are easily corrected. I will continue to update as this project makes progress , and see if I can understand the reason for that gap anomaly.

I don't think this is for the visuals only. I guess it's the way TAW differs between types of ground:

If you crash in the top-left corner of a tile, then you also crash in the top-left corner of the tile's texture (TFX3 never rotates a tile, though TFX2 does). You look up the color index in the pixel at that position. If the index is 112–128, show a splash. Else, show an explosion.

But now there's a problem: There's not one texture in a TM file but four. How do you know which one to use?

And here's where 28xx comes into play: It says, for example, "This terrain tile may use in tex_11.tm, but to be exact, it's in the lower right 96×96 pixels!"

I'm going to have a tough weekend, but if I find some time I'll try that. It still doesn't explain the splashes on rivers, though.

[TAW terrain format]

Quick update on the oil refinery glitches in TFXplorer: Those bogus polygons appear only at certain times of day (12:00–14:00). If you look closely, you can see that the oil refineries look different at that time (they are not transparent any more but solid dark).

Therefore I guess we're on the wrong track with one of the time of day opcodes: One of them doesn't have to do anything with time of day but rather with level of detail or distance or who knows.

The same happens for EF2000 shapes. When you look at them in 3View, and switch the time of day, suddenly new features become visible or disappear (very apparent in the EF2000 cockpit). One huge problem I had with TFXplorer in EF2000 mode was that at certain times of day the entire landscape would be draw twice: You would not see a difference but the polygon count doubled and the performance halved.

Now here's the twist: The time of day opcodes work perfectly for TAW, and I've verified them at least a dozen times. It looks like they have a different meaning in EF2000 and, for some reason, also in TAW's refinery shapes.

Reminder for my future self: Look up the time of day opcodes in the refinery files, look up the time of day opcodes in EF2000 files, and find out why they are treated differently.