Krycztij

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

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

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.

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

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 …

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: outer left pylon outer right pylon inner left pylon inner right pylon left weapons bay right weapons bay center weapons bay; missile on the outer left center weapons bay; missile on the outer right center weapons bay; missile in the left middle center weapons bay; missile in the right middle center weapons bay; missile on the inner left center weapons bay; missile on the inner right center weapons bay, left bomb center weapons bay, right bomb

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 …

Oh I remember – it was that scary bytecode I never dared to decode! That'll keep me busy for some weeks I guess :-)

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?

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

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?

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

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

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

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

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.

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.

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

GREAT! Thank you

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 …

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

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

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 …

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.

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.