Jump to content
COMBATSIM Forum

Recommended Posts

Nice!

There is only one texture folder, but there are many palettes for day and night with various weather.

I haven't looked into the EF files in much detail, but the pd_cr.txt etc, files in the 'lev' folder may help determine when each palette is used.

Actually, there are corresponding texture folders for different blocks of time per day. In default TAW it is red0200 and red2200 for nighttime (0200:no moon while 2200:moon), and for daytime there are the following texture folders: red0600, red1000, red1400, red1800. That said, texture differences are minimal, with all (or just about all) of the changes being a shift from bright orange/red to grey for twilight/night times. In the original TAW, there are also differences in shading with the depression/incline textures accounting for TOD, but that isn't a player for the 3D objects.

Link to post
Share on other sites
  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Here's some EF2000 .3 files with textures and color palettes:

Anyone wants to try a carrier landing?

carrgt.png

Or sit inside a F-117?

f17v.png

There's still LOT of bugs …

cob.png

Red October approaching! Get Jack Ryan quick! ;)

redoc.png

This rotor bug (3 blades at another position than the other) is particularly intersting, because it also occurs in TAW's APACHE.3 (though less remarkable) and I have no clue what's going wrong:

apach.png

Landscape:

cliff.png

Here's the current build:

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

Just replace the EXE you used before. If you open a .3 file in EF2000's \3 directory, it should automatically use EF2000's \TM and \COLOURS directory. Use F2 to change the color palette; I just picked the first eight or nine palettes I found. Could not test it for bugs with TAW, I'm too short on time. So use it at your own risk.

I hate mentioning problems with the viewer since it comes across as ungrateful
Please report them; a bug-clean viewer is for our common good :)

I'll have too much to do this week to proceed, but I hope to have time next weekend again. If anyone wants to investigate the new EF2000 bugs already, just use F12 to dump the execution log to the console.

Link to post
Share on other sites

@Krycztij

Haha I really enjoyed seeing that sports car model. Never really flew EF2000, but really cool that it's there!

But man would it be cool to see one of those in TAW... just cruising around... in the middle of the red sea desert area... and then just find a batch of these belonging to some rich oil baron... and then blowing them up ^^

EDIT:

Oh and man, I dream of having HUDs for other aircraft.. I think the F-117, like alot of other non F22 planes in TAW, is flyable - just not really practical with no HUD and nothing like that..

Maybe, one day.....

But I shouldn't keep talking about more work and stuff to-do since I'm not the one doing anything for TAW right now, so yeah...

I really appreciate all the work, and everybody with their own pace at which they contribute.

:icon_bow::icon_salute3::thumbsup:

Edited by Eagle_Flight
Link to post
Share on other sites

@Krycztij,

I realize that this is somewhat a moot point, but I was unable to find the extracted ADF-specific DID.dat. I'll keep looking, but just so you know I didn't forget.

I did extract the ADF files, although without their proper names.

It was a long time ago, but I believe I created a script to at least categorize the files into .3, .ssd etc.

I'll check later....

It might be an idea to have another look at the did.dat file structure to see if it's possible to extract all the files (with names!) using a standalone tool. I'll start a thread on the subject after I've gathered some information.

Link to post
Share on other sites
@Krycztij, it looks awesome!

Thank you! I hope to get the whole EF2000 terrain drawn sooner or later in the same way I did with TAW's.

@Krycztij

Haha I really enjoyed seeing that sports car model. Never really flew EF2000, but really cool that it's there!

Yes, there are even more strange models — spaceships, for example (and their level of detail is very high for EF2000). Very weird.

But I shouldn't keep talking about more work and stuff to-do since I'm not the one doing anything for TAW right now, so yeah...
It's such hopes and dreams that keep us going :)

@Krycztij,

I realize that this is somewhat a moot point, but I was unable to find the extracted ADF-specific DID.dat. I'll keep looking, but just so you know I didn't forget.

Alright; there's no rush as I'm currently buzy with EF2000. Just, ADF compatibility would be a very-nice-to-have feature :)

I did extract the ADF files, although without their proper names.

It was a long time ago, but I believe I created a script to at least categorize the files into .3, .ssd etc.

I'll check later....

It might be an idea to have another look at the did.dat file structure to see if it's possible to extract all the files (with names!) using a standalone tool. I'll start a thread on the subject after I've gathered some information.

It would be VERY helpful not only for me but for EVERY mod project if we could extract all files with their proper names. I encourage this work! :thumbsup:

EF2000? Pah! What we really want is TFX..... :)
:D I guess I will actually take care of TFX when EF2000 compatibility is complete. The good thing is, TAW has the most complex .3 file structure, and it gets easier the more we go back in time. Well, at least I hope so ;)
Link to post
Share on other sites

Here's my guess on the meaning of .3 file types:

  • 0000: TFX 2 entity; also used in TFX 3 for runways, AWACS and some buildings
  • 0004: TFX 2 sub-entity — is always bound to a 0000-type entity (e.g. a 0004-type pylon weapon object is always bound to the 0000-type aircraft object carrying it, but for the weapon when being fired, a 0000-type object is used because it's a distinct object then; other occurances are the movable rudders of the player Typhoon model)
  • 0020: TFX 3 terrain without LOD (used rarely for high-detail terrain, like Aswan dams)
  • 0083: TFX 3 entity, replaces TFX 2's 0000
  • 0087: TFX 3 sub-entity, replaces TFX 2's 0004
  • 00A3: TFX 3 terrain with LOD (used for most terrain tiles)

(TFX 2 is EF2000; TFX 3 is F-22: Air Dominance Fighter and Total Air War. I don't have TFX' extracted files, so I couldn't consider it.)

I'd like to hear if you agree so far.

Link to post
Share on other sites

Sounds good to me. I think DKD has been deeper into this.

I isolated the TFX .3 files just yesterday, although without names. I haven't done anything with them yet since I'm more interested in the extraction process.

Link to post
Share on other sites

Glad to hear you're working on it!

0038 is finally decoded. It does the same as 007D (drawing a disc from two lines), just 1 ÷ sqrt(2) smaller:

0038o.png

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

// Draw a flat-shaded disc with the color at palette index <color> which is enclosed in a quad. The

//	indices of the quad vertices' (transformed) positions are given in clockwise order.

While 007D is used to draw the tires of ground vehicles entirely, 0038 is used to draw the backsides of tires of airplanes. I guess that's because DID tried to recycle the vertex positions they needed for the sprites at the tire's outsides already.

Link to post
Share on other sites

Well, the TAW (and most other) did.dat files are of this form:

The first 4 bytes are pointer to to the index section at the end of the file.

In the case of TAW's this is 0x03cc22ae which gets us to this point:

didhex1.jpg

At this point are 4 16-bit numbers:

0x312c=12588 The number of files in the archive

0x0069=105 Number of path specifiers

0x0047=71 Number of file extensions

0x06e1=1761 Number of bytes until the start of the index (ie to the point after the paths and extensions) are listed:

didhex2.jpg

Now we have the list proper and there are 12 bytes for each of the 12588 files:

The first 4 bytes are a mysterious index, then 4 bytes for the offset in did.dat, finally 4 bytes for the file size.

In this case we have:

Index=0x8006c719, Offset=0x02bd558a, Size=0x00000068

The hope would be that this 'index' is a compressed version of the filename, but hope is fading...

These 'index' numbers increment in a strange way, the differences don't correspond to the compressed or uncompressed sizes of the files they relate to.

This index is of TFX's 3460 files, but you get the idea. I've left the index as hex, but converted the offsets and sizes to decimal:

0 80117f36 1572576 415

1 8020f12b 1714256 421

2 802fc869 3142886 40

3 80310755 1706269 432

4 80416965 1068735 206

5 8045e661 3154385 240

6 80487169 1397285 587

7 8052fd69 1248725 526

8 805fc74a 2916069 940

9 80624825 3132188 40

10 806d494a 1881578 1702

11 8075a665 3155401 267

12 8078b479 3117002 40

13 807b5549 1708292 536

14 8080b759 1371479 859

15 80861761 1068095 437

16 80897c35 3169674 152

17 808b6635 3171708 152

18 808d6835 3173492 152

19 808dcb35 1571740 836

20 808fdb50 3274013 4610

21 80903553 2814718 607

22 80910579 1227034 346

23 80913f53 2819051 156

24 80923953 2819948 156

25 809c1532 1674678 122

26 80a31f35 1583159 196

27 80a38c23 3162430 183

28 80a51935 1585754 308

29 80ab154d 1712500 655

30 80b93c35 3171252 152

31 80bb2635 3173120 124

32 80bd2835 3176176 152

....

2857 afcfa293 10413207 169

2858 afd60c8a 2541536 5756

2859 afd7a493 10376338 214

2860 afd8a291 10378145 246

2861 afda332b 1715744 1156

2862 afdaa5d4 1939414 141

2863 afdfaaa8 3213531 82

2864 afe9ffd9 1594625 302

2865 aff993a9 1885281 130

2866 affbb7a0 1961241 552

2867 30209303 1511452 565

2868 30db9c02 1981640 15589

2869 3210a202 3159339 30

2870 3966dc01 333934 5678

2871 3c168102 3496343 133

2872 3e3cb702 1840737 204

2873 3f3eb502 1895112 1830

2874 40060605 1043223 4895

2875 40ba5904 1640423 5796

2876 41080405 1048118 3733

.....

3445 7f095d29 2809104 603

3446 7f31fc35 3156283 40

3447 7f3f522e 2265448 140

3448 7f498535 1502889 431

3449 7f4d9d35 1503320 412

3450 7f632629 7075180 6017

3451 7f845429 3194679 40

3452 7f87912d 1656202 756

3453 7fb41429 3194919 40

3454 7fccf939 1222871 565

3455 7fd5d638 3390152 8639

3456 7fd9282a 2092604 198

3457 7fe9a529 1918678 113

3458 7feadc2c 3196081 50

3459 7ff3e635 4247747 120866

Link to post
Share on other sites

Interesting :popcornsmilie: Obviously, the lookup table is sorted by the unknown indices' values, which have been interpreted as signed integers (80000000, which corresponds to -2,147,483,648 decimally, first; 7FFFFFFF, which corresponds to +2,147,483,647 decimally, last). Could also be Huffman coding. No, that's not efficient enough.

How did you assemble the names of the already known files? Did you find them in F22.DAT?

Link to post
Share on other sites

No, the names are obtained by running the game inside a debugger and setting a breakpoint in the function where the files are read in. At a certain point, the offset and size can be read from the EAX and EBX registers while ESP points to the filename which 'magically' appears on the stack.

This only works for files used in the game, so we don't have names for the 2000 or so of the 12588 files in did.dat.

Today, I've been trying to find out where the name comes from, but it's a thankless task...

Link to post
Share on other sites

And I guess I'm having a nervous breakdown :(

Remember that the rotor blades of TAW's APACHE1.3 are misplaced?

apache1.png

Well, here's the corresponding code:

0711; 006cffc500e1    ; Vertex :225  X=0  Y=59  Z=0

// ...

0713; 007500e1    ;

// ...

0726; 002d00e10074    ; call line 737 to draw the 1st blade without rotation at vertex 00e1's (225 decimally) position

0727; 004900004000000000000000000000000000000000e1005c    ; call line 737 to draw the 2nd blade rotated at vertex 00e1's position

0728; 004900008000000000000000000000000000000000e10044    ; 3rd blade

0729; 00490000c000000000000000000000000000000000e1002c    ; 4th blade


// ...


// Routine to draw a single blade:

0737; 006200e1000000000000    ; Vertex :225  X=0  Y=0  Z=0 WHY PLEASE TELL ME WHY DO YOU OVERWRITE VERTEX 00e1

0738; 006dfd7400ef    ; Vertex :239  X=0  Y=0  Z=-652

0739; 0068019f0094    ; Vertex :240  X=415  Y=0  Z=-504

0740; 007500e1    ;

0741; 0061000200ef    ;

0742; 00480002    ;

0743; 00210000003c    ; If Parameter 0002 = 0 then jump to line 749

0744; 00470005000300b1002700b1000400ed0027    ;UV Coords: 177,39 177,4  237,39

0745; 0088000300f000ef00e1    ; Transparency = mob_5

0746; 00470005000300b1002700ed002700b10004    ;UV Coords: 177,39 237,39  177,4

0747; 0088000300f000e100ef    ; Transparency = mob_5

0748; 0000    ;

Vertex 00e1 holds the base position of the rotor blades, which is 0/59/0 when the first blade is reched, but it's overwritten to 0/0/0 when drawing the other blades. I cannot find any sense in that. I'm scared that it means every subroutine has its own vertex coordinates; that would be a desaster for my implementation …

Edit: On the other hand, 00e1 is repeatedly used in a 0075 instruction. To this point, we thought that 0075 marks a spawn position for attaching 0087-type models; but now it's possible that it means a position is pushed into a special register and restored from there … :unsure:

Link to post
Share on other sites

I'm not convinced that there is anything special about the 0075 opcode. It seems to be a an instruction to load a single vertex into something, while for multiple vertices with contigious indices, the 0061 opcode is used.

Even a simple model, like this part of tent_2.3 uses 0075 and 0061:

0047; 00620007000bfffdfff8    ; Vertex :7  X=11  Y=3  Z=-8

0048; 0064ffea    ; Vertex :8  X=-11  Y=3  Z=-8

0049; 00660010    ; Vertex :9  X=-11  Y=3  Z=8

0050; 006b00160006    ; Vertex :6  X=11  Y=3  Z=8

0051; 006a00010003ffef0002    ; Vertex :2  X=12  Y=0  Z=-9

0052; 006d00120005    ; Vertex :5  X=12  Y=0  Z=9

0053; 006bffe80004    ; Vertex :4  X=-12  Y=0  Z=9

0054; 006dffee0003    ; Vertex :3  X=-12  Y=0  Z=-9

0055; 006100030007    ;

0056; 00750006    ;

0057; 00750002    ;

0058; 00750005    ;

0059; 00750004    ;

0060; 00750003    ;

0061; 009f00080038010300cc009e0009000800030004    ;

0062; 009f00080036010300ca009e0008000700020003    ;

0063; 009f00080032010300ca009e0006000900040005    ;

0064; 009f00080034010300c8009e0007000600050002    ;

0065; 009f00080035010300ce009e0008000900060007    ;

0066; 0000    ;

I can't explain what's up with the Apache though....

Link to post
Share on other sites

Yes, 0075 and 0061 have in common that they take one or many vertices and apply the current transformation matrix to them before storing them in another buffer.

But there HAS TO BE a difference. If you look at the code you posted of tent_2.3, you see that 0075 transforms vertex #2–6 and 0061 transforms vertex 7–9. Why isn't there just a single 0061 0008 0002 (transform vertices 2–9) instruction then? It would be easier and faster. But they don't do it, and there has to be a reason for it.

0061 is very likely just a flushing instruction, but 0075 is a mystery to me. I just implemented a green point light whenever 0075 is executed on a position index. This is the result:

0075i.png

As you can see, 0075 does not only mark visible vertices -- it also marks the middle of decals and some other points I don't understand.

I am, however, sure that 0075 has an ENORMOUS importance. It marks all important points on a model: The weapon pylons, the position of the pilot's head, the position of the afterburner etc pp. Whatever you need to know to spawn weapons or otherwise let the model interact with its environment: It is marked by 0075.

ef0075.png

Also, there's another problem: I'm drawing everything twice. I played with the 0062 instruction, accidjentially added some offset, and this was the result:

burger.png

Some jump must be mistaken for a call. This is not much of a visual problem (except for transparent parts, which are double as opaque), but I don't like that I'm processing twice as much as is necessary and that something is still mistaken.

Edit: Solved; that was just some old debugging code I forgot after having tested tranformation issues.

Link to post
Share on other sites

No, not at all :( I'm currently looking for simpler cases where 0075 is used to control submesh offsets.

Oh, and I've also been trying to find information on DID.DAT. I found something on the RA compression used for individual files in there, but nothing on file names :(

Link to post
Share on other sites

Getting better all the time!

Not so good news from the filename front. :( I think the names come from various places depending on the type, with some being explicitly defined in f22.dat.

Still need to work out how the name is linked to a particular file in did.dat though, so there's still hope.

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