Jump to content
COMBATSIM Forum

Recommended Posts

Hmmn. :unsure:

Here's all the occcurences were that word isn't 0003 or 0004:

ian_0.3 0767; 0047000f000200d0007b00ff00aa0097005b001e    ;

ian_0.3 0820; 0047000f000200d0007b00ff00aa0097005b001e    ;

ian_0.3 0873; 0047000f000200d0007b00ff00aa0097005b0019    ;

ian_0.3 0926; 0047000f000200d0007b00ff00aa0097005b0019    ;

ian_0.3 1223; 0047000f000200d0004a00ff00780097005b001e    ;

ian_0.3 1276; 0047000f000200d0004a00ff00780097005b001e    ;

ian_1.3 0926; 0047000f000200d0007b00ff00aa0097005b001e    ;

ian_1.3 0980; 0047000f000200d0007b00ff00aa0097005b001e    ;

ian_1.3 1034; 0047000f000200d0007b00ff00aa0097005b0019    ;

ian_1.3 1088; 0047000f000200d0007b00ff00aa0097005b0019    ;

ian_1.3 1386; 0047000f000200d0004a00ff00780097005b001e    ;

ian_1.3 1440; 0047000f000200d0004a00ff00780097005b001e    ;

ian_2.3 0750; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_2.3 0804; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_2.3 0858; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_2.3 0912; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_2.3 1210; 0047000f000200d0004a00ff00780097005a001e    ;

ian_2.3 1264; 0047000f000200d0004a00ff00780097005a001e    ;

ian_3.3 0750; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_3.3 0804; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_3.3 0858; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_3.3 0912; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_3.3 1210; 0047000f000200d0004a00ff00780097005a001e    ;

ian_3.3 1264; 0047000f000200d0004a00ff00780097005a001e    ;

ian_4.3 0756; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_4.3 0810; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_4.3 0864; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_4.3 0918; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_4.3 1216; 0047000f000200d0004a00ff00780097005a001e    ;

ian_4.3 1270; 0047000f000200d0004a00ff00780097005a001e    ;

ian_5.3 0756; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_5.3 0810; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_5.3 0864; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_5.3 0918; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_5.3 1216; 0047000f000200d0004a00ff00780097005a001e    ;

ian_5.3 1270; 0047000f000200d0004a00ff00780097005a001e    ;

ian_6.3 0756; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_6.3 0810; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_6.3 0864; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_6.3 0918; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_6.3 1216; 0047000f000200d0004a00ff00780097005a001e    ;

ian_6.3 1270; 0047000f000200d0004a00ff00780097005a001e    ;

ian_7.3 0742; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_7.3 0795; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_7.3 0848; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_7.3 0901; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_7.3 1196; 0047000f000200d0004a00ff00780097005a001e    ;

ian_7.3 1249; 0047000f000200d0004a00ff00780097005a001e    ;

ian_8.3 0742; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_8.3 0795; 0047000f000200d0007b00ff00aa0097005a001e    ;

ian_8.3 0848; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_8.3 0901; 0047000f000200d0007b00ff00aa0097005a0019    ;

ian_8.3 1196; 0047000f000200d0004a00ff00780097005a001e    ;

ian_8.3 1249; 0047000f000200d0004a00ff00780097005a001e    ;

neil_10.3 0879; 0047000f000200d0007b00ff00aa0097005e001e    ;

neil_10.3 0932; 0047000f000200d0007b00ff00aa0097005e001e    ;

neil_10.3 0985; 0047000f000200d0007b00ff00aa0097005e0019    ;

neil_10.3 1038; 0047000f000200d0007b00ff00aa0097005e0019    ;

neil_10.3 1333; 0047000f000200d0004a00ff00780097005e001e    ;

neil_10.3 1386; 0047000f000200d0004a00ff00780097005e001e    ;

So, the only other alternative is 0002.

I suppose this could be a 2 dimensional texture, or textured line. We could then split this to produce a new 0097 opcode to define the vertices:

0047000f000200d0007b00ff00aa

0097005b001e

...or something like that?

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

I'm okay with that — it's a "clean" decision which will keep 0047 consistent. It's also apparent that 0097 does not have a texture position in its first operand (the number is too large). I'll set up everything, visualize the indices in the operand and see what it means.

I've also looked into 0026, but it's still a mystery to me …

First of all, I don't think it's "if distance equals". Distance is very volatile, and it's never an even number either. Such a check would evaluate true on 0.00001 % at most.

Then, I don't think it's "if distance is below" either: You could already model such a check with 0027:

0000 0027 if distance > x jump to 0003

0001 (whatever requires distance being below or equal to x here)

0002 0000 return

0003 (whatever requires distance being above x here)

0004 0000 return

I've also tried to use it as a call instead of a jump, but that just caused many models being drawn twice.

The viewer cannot play the smoke*.3 and ex_***.3 files currently because of nonexistent textures, so it's rather difficult to find a meaning. In many vehicle files (and f22simp2.3), however, it jumps to the same position which is chosen if the LOD distance is exceeded, i.e. to a 0000 return which effectively quits drawing. So I see three possibilities:

  • Treat it in the same way as 0027. From what I see, this did not change any model's visual appearance. This would draw it completely redundant, but treating it as "jump if distance below", on the other hand, would cause nothing to be drawn any more.
  • Ignore it.
  • Change it in the game files and see what's the effect. This would be hard and annoying because we have no scale of object-space distance in the game, and we'd have to guess the values by chance.

?

Link to post
Share on other sites

0026 is not used very often. Here's the files where it appears:

avengr.3 0049; 002600230002    ;  Comparison with (35), Jump to line 50

bmp_3.3 0005; 002600c80002    ;  Comparison with (200), Jump to line 6

car.3 0677; 00260032032e    ;  Comparison with (50), Jump to line 760

chaparal.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

crate.3 0608; 00260019032e    ;  Comparison with (25), Jump to line 691

explane1.3 0023; 0026000a6d82    ;  Comparison with (10), Jump to line 3489

explanew.3 0049; 0026000a6d82    ;  Comparison with (10), Jump to line 3515

ex_plane.3 0023; 0026000a738a    ;  Comparison with (10), Jump to line 3469

f22s1egy.3 0003; 002600192ede    ;  Comparison with (25), Jump to line 1328

f22s1sau.3 0003; 002600192ee4    ;  Comparison with (25), Jump to line 1329

f22s1us1.3 0003; 002600192edc    ;  Comparison with (25), Jump to line 1328

f22s1us2.3 0003; 002600192ee4    ;  Comparison with (25), Jump to line 1329

f22simp2.3 0008; 002600641b82    ;  Comparison with (100), Jump to line 1131

gtatrail.3 0003; 00260032001e    ;  Comparison with (50), Jump to line 8

lux_h_90.3 0005; 002602bc000a    ;  Comparison with (700), Jump to line 8

lux_h_90.3 0006; 002609600d18    ;  Comparison with (2400), Jump to line 405

lux_t180.3 0018; 00260258088e    ;  Comparison with (600), Jump to line 319

lux_t90.3 0018; 0026025806cc    ;  Comparison with (600), Jump to line 276

m1.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

m109.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

m163_vul.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

mlrs.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

para.3 0603; 0026004b032e    ;  Comparison with (75), Jump to line 686

patriot1.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

patriot2.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

ref_3.3 0686; 002601f4014a    ;  Comparison with (500), Jump to line 753

roland.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

sa17.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

sa_11.3 0005; 002600640002    ;  Comparison with (100), Jump to line 6

smoke1.3 0022; 0026000a6d82    ;  Comparison with (10), Jump to line 3488

smokew.3 0022; 0026000a6d82    ;  Comparison with (10), Jump to line 3488

warrior.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2

zsu_23_4.3 0001; 002600640002    ;  Comparison with (100), Jump to line 2
....and there are weird sequences like this from chaparal.3 which is hard to interpret:
0000; 00300041    ; Scale Factor 65

0001; 002600640002    ;  Comparison with (100), Jump to line 2

0002; 0027006428e0    ; If Distance >100 then jump to line 1466

0003; 00620000ffce0000005a    ; Vertex :0  X=-50  Y=0  Z=90

0004; 00640064    ; Vertex :1  X=50  Y=0  Z=90

..

..

EDIT:

oh, and which textures are 'nonexistent'?

Link to post
Share on other sites

....and there are weird sequences like this from chaparal.3 which is hard to interpret:

0000; 00300041    ; Scale Factor 65

0001; 002600640002    ;  Comparison with (100), Jump to line 2

0002; 0027006428e0    ; If Distance >100 then jump to line 1466

0003; 00620000ffce0000005a    ; Vertex :0  X=-50  Y=0  Z=90

0004; 00640064    ; Vertex :1  X=50  Y=0  Z=90

..

..

That's how it's used at the beginning of every vehicle file where it appears. I'm especially irritated by "jump 2 B", which effectively means: "No matter if it evaluates true or false, do the same". Treating it as a subroutine would cause everything being executed twice in exactly the same way. The only files where it does make a difference are the parachute files, but I don't see a sense there either (in crate.3, it tests for a distance of 25 — but the instruction is only reached when the distance is already below 25, so the test is completely redundant).

EDIT:

oh, and which textures are 'nonexistent'?

I didn't check yet, but it seems like the hard-coded texture file name is missing. I still need to check that against your script's output, though.

By the way: All UV positions are always in the range of [0, 255]/[0, 191] — except for radar.3, where V is in the range of [0, 192] :rolleyes:

Link to post
Share on other sites

Most textures are 256x192 and a few years ago we tried to increase the texture size to 256x256 and change the appropriate V coordinates. IIRC the program ran quite happily, but just displayed a white area if the V coordinate was greater than 191.

Link to post
Share on other sites

The first operand in 0097 is indeed the index of the (transformed) position where the limb is attached. The second one, however, has a different meaning, so interpreting the instruction as a line is a dead end:

ianga.png

It's not a jump or call, that's all I know at this point. TAW draws the limbs as four-sided "pipes" with a texture on them. I wonder where it gets the direction, i.e. the second point, from.

Link to post
Share on other sites

I don't know, but that line always (at least in ian_0.3) is associated with this sort of construct:

1242; 00620001fff40000001c    ; Vertex :1  X=-12  Y=0  Z=28

1243; 006b00180003    ; Vertex :3  X=12  Y=0  Z=28

1244; 0066ffc8    ; Vertex :4  X=12  Y=0  Z=-28

1245; 006bffe80006    ; Vertex :6  X=-12  Y=0  Z=-28

1246; 006f002800280002    ; Vertex :2  X=28  Y=0  Z=12

1247; 006dffe80005    ; Vertex :5  X=28  Y=0  Z=-12

1248; 006bffc80057    ; Vertex :87  X=-28  Y=0  Z=-12

1249; 006d0018006d    ; Vertex :109  X=-28  Y=0  Z=12

1250; 006f001cfff4005b    ; Vertex :91  X=0  Y=0  Z=0

1251; 006a000a00a000190064    ; Vertex :100  X=10  Y=-160  Z=25

1252; 006dffce0063    ; Vertex :99  X=10  Y=-160  Z=-25

1253; 006bffec0059    ; Vertex :89  X=-10  Y=-160  Z=-25

1254; 00660032    ; Vertex :90  X=-10  Y=-160  Z=25

1255; 006f0023ffdd0058    ; Vertex :88  X=25  Y=-160  Z=-10

1256; 006bffce0069    ; Vertex :105  X=-25  Y=-160  Z=-10

1257; 006d00140060    ; Vertex :96  X=-25  Y=-160  Z=10

1258; 006b00320056    ; Vertex :86  X=25  Y=-160  Z=10

1259; 00750001    ;

1260; 006100020003    ;

1261; 00750006    ;

1262; 00750002    ;

1263; 00750005    ;

1264; 00750057    ;

1265; 0075006d    ;

1266; 0075005b    ;

1267; 00750064    ;

1268; 00750063    ;

1269; 006100020059    ;

1270; 00750058    ;

1271; 00750069    ;

1272; 00750060    ;

1273; 00750056    ;

1274; 0004003300090001000300020005000400060057006d0001    ;

1275; 00730009005a0060006900590063005800560064005a    ;

1276; 0047000f000200d0004a00ff00780097005b001e    ;

1277; 0000    ;

Maybe there's some clue there...

Link to post
Share on other sites
Option Setting: Build_Texture=1

hut-n1-orig-tex1.jpg

Option Setting: Build_Texture=0

hut-n1-orig.jpg

Option Setting: Build_Texture=0

All 009f0018xxxx0900 modified to 009f0018xxxx0901

hut-n1-0901.jpg

Here's my implementation:

hut.png

I am, however, not yet satisfied with it. It requires 009F to set a flag when the 0900 type is encountered. Then, FFFF and four UV coordinates follow. The next 009E instruction needs to draw a textured quad if the flag is set, and a Gouraud-shaded quad otherwise. The flag is then cleared again. Somehow weird. But it's weird that the hut looks better without building textures anyway.

Link to post
Share on other sites

Yes, it seems even finer when considering that I can use it to control BUILD_TEXTURES in the UV instruction, not in the rendering instruction.

Upon analyzing why ref_*.3 look so different than in the game (no transparency if lights are off etc), I found out: 0042 controls whether the refinery is drawn transparent or opaque. 0041 does something similar, but I couldn't work out what. Finally, their conditions must evaluate false for some parts of the refinery not to be overdrawn (drawn twice in the same place).

Link to post
Share on other sites

Update on daytimes in 0043:

  • oooooooo ooooooo1 is used at 08:00
  • oooooooo oooooo11 is used at 10:00
  • oooooooo ooooo111 is used at 12:00
  • oooooooo oooo1111 is used at 14:00
  • oooooooo ooo11111 is used at 16:00
  • oooooooo oo111111 is used at 18:00
  • oooooooo o1111111 is used at 20:00–04:00 in full moon nights
  • oooooooo 11111111 is used at 20:00–04:00 in moonless nights (I guess, couldn't test it)
  • ooooooo1 11111111 is used at 06:00

So, a bit test for 128 effectively tells whether it's night. Oh no, that should be 64. Even more confusing.

I just don't understand the effect of 0040, 0041 and 0042 :(

Link to post
Share on other sites

Not easy...

Here's the possible values that are used for the check in 0040,0041,0042:

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 

This is a typical 0043 block:
0187; 004301ff002e    ; If Time of Day = 511 then jump to line 196

0188; 004301ff0028    ; If Time of Day = 511 then jump to line 196

0189; 0043003f0172    ; If Time of Day = 63 then jump to line 232

0190; 0043001f0134    ; If Time of Day = 31 then jump to line 226

0191; 0043000f00f6    ; If Time of Day = 15 then jump to line 220

0192; 0043000700b8    ; If Time of Day = 7 then jump to line 214

0193; 00430003007a    ; If Time of Day = 3 then jump to line 208

0194; 00430001003c    ; If Time of Day = 1 then jump to line 202

Lines 187 & 188 say the same thing, so I assume that I'm missing something.

Sorry, no answers I'm afraid. :(

Link to post
Share on other sites

I have an update on the elusive 009f/0900 Opcode/Type and I must apologize for the inordinate amount of enjoyment this little complex process has afforded me thus far.

hut_n1.3/ 1st LOD

009F0018001A0900FFFF004000B5005000B5005000BD004000BD009E000D001000110014

009F001800140900FFFF005E009A007E009A007E00A2005E00A2009E000E000D00140013

009F001800160900FFFF0080003F0090003F0090004700800047009E000F000E00130012

009F000E0027040100C600C800C700C4009E0010000D000E000F

0000

009F001800140900FFFF005E009A007E009A007E00A2005E00A2009E0005000400070006

009F001800180900FFFF005E009A007E009A007E00A2005E00A2009E000B000A00090008

009F0018001A0900FFFF004000B5005000B5005000BD004000BD009E0004000B00080007

009F001800160900FFFF0080003F0090003F0090004700800047009E000A000500060009

009F000E0027040100C600C400C300C4009E00040005000A000B
I am amazed at the breadth of possible functioning of the 009F Opcode, and it is certainly a curious unit in that, on the surface at least, there would be the suggestion that only 2 states should exist based on BUILD_TEXTURE options being limited to 0 or 1. Although "1" activates the optimal texture fetching/rendering process, the real fun exists in the configuring of "0" for what would appear to be an anticipated color shaded process. As you have previously determined, it is simply not that simple. By recent analysis it appears that a part of the functioning has been disabled using the specific 4th operand word (FFFF). That 2 byte word gives the index number for accessing textures via the [globaltextures] section of the red****.ini file. The 009F/0900 type can access textures via the red****.ini files [surface] textures section, the [globaltextures] section or by using the hard-coded texture and the UV coordinates contained within the operand. The curious thing is that two of the three methods are only attainable when BUILD_TEXTURES=0. I am working on a theory that the 0900 type was originally designed to provide a model surface mapping treatment (COLR) which, for some reason, was essentially disabled. The executable lists 4 building surface treatments: 1. txtr 2. colr 3. gour 4. flat
DGROUP:0064C318                 unicode 0, <?>,0

DGROUP:0064C31C aTxtr           db 'txtr',0             ; DATA XREF: DGROUP:off_6DB864 o

DGROUP:0064C321                 align 4

DGROUP:0064C324 aColr           db 'colr',0             ; DATA XREF: DGROUP:006DB868 o

DGROUP:0064C329                 align 4

DGROUP:0064C32C aGour           db 'gour',0             ; DATA XREF: DGROUP:006DB86C o

DGROUP:0064C331                 align 4

DGROUP:0064C334 aFlat           db 'flat',0             ; DATA XREF: DGROUP:006DB870 o

DGROUP:0064C339                 align 4

These can be implemented manually by a modification of the [surface] section of the red****.ini, as follows:

0=txtr 4,(0,0),(31,0),(31,31),(0,31)

1=txtr 4,(32,0),(63,0),(63,31),(32,31)

2=txtr 4,(64,0),(95,0),(95,31),(64,31)

3=txtr 4,(96,0),(127,0),(127,31),(96,31)

4=colr 4,3,2,1

5=gour 4,3,2,1

6=flat 4

The rendered treatments for "Colr" and "Gour" are identical, however, a couple years ago I found a block in the executable which suggested the [surface] Colr calls had been remapped to provide Gouraud Shading as opposed to a unique and seperate "Colr" treatment. I suspect that Colr is a hybrid texture-color-shaded treatment and what we have seen with, what I consider, the best quality hut_1n.3 rendering, using the 009F/0900 type with BUILD_TEXTURE=0, is actually that hybrid. It's a shame they did not extensively implement that surface treatment in the game. :(

I should add that when either the hard-coded texture or the [globaltextures] texture are used the UV coordinates in the operand are used to map the texture. It appears that "FFFF" determines that the hard-coded header texture is to be used :popcornsmilie:

Edited by DrKevDog
Link to post
Share on other sites

So, if I get it right: red****.ini offers the ability to make 009D/009E-drawn triangles or quads either textured, colored, Gouraud-shaded or flat-shaded. 009F with its different types offers the same ability, just hard-coded instead of adjustable via red****.ini? I've implemented it that way.

Here's the current build (you can adjust daytime via F/V for now, but it's still very beta):

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

Source code is included (if any C++ programmers are present). You need Visual C++ 2010 and the current DirectX SDK to build it (just include them into an empty console application project). Better don't look at the renderer, it's a big miss :rolleyes: All the "magic" and relevant information can be found in TAW_3_Processor.hpp and at the beginning of main.cpp.

By the way: All UV positions are always in the range of [0, 255]/[0, 191] — except for radar.3, where V is in the range of [0, 192] :rolleyes:

Got to revise this. It was my fault truncating values before actually checking their range :banghead: Both coordinates, U as well as V, are in the range of [0, 256]. A good example is ctyb_180.3, where coordinates of 256 are used to render many tiled windows. Will be fixed in the next build.
Link to post
Share on other sites

Did you notice explosion debris being people? In debris14.3, they're even painted red …

Anyway, I must correct my texture coordinate statement for the third time :rolleyes:

The highest F-22 LODs use texture coordinates of 258 in their U and V coordinates; to duplicate the texture of the pilot's finger, I guess.

Link to post
Share on other sites

So, if I get it right: red****.ini offers the ability to make 009D/009E-drawn triangles or quads either textured, colored, Gouraud-shaded or flat-shaded. 009F with its different types offers the same ability, just hard-coded instead of adjustable via red****.ini? I've implemented it that way.

That's correct and although I know this is nothing particularly useful in implementing 009F in the viewer, since we have it out for discussion, my interest revolves around the fact that 009F is so surprisingly robust it might possibly be modifiable in such a way as to also make drawn triangles or quads 24 or 32 bit (AGP) textured? That would be quite an advance considering the current game limits on the use of AGP textures.

:)

Link to post
Share on other sites

In my opinion, the problem with 24- and 32-bit textures (btw, the 24-bit-Textures are blendet additively, so they cannot be used for ordinary texture mapping) is not that the instructions are missing, but that TAW will never ever execute one of them until it's in the 'AGP available' mode. I doubt there is any sense in attempting to execute 32-bit draw instructions until this mode is actually available with a glide wrapper.

Link to post
Share on other sites

In my opinion, the problem with 24- and 32-bit textures (btw, the 24-bit-Textures are blendet additively, so they cannot be used for ordinary texture mapping) is not that the instructions are missing, but that TAW will never ever execute one of them until it's in the 'AGP available' mode. I doubt there is any sense in attempting to execute 32-bit draw instructions until this mode is actually available with a glide wrapper.

Thanks and please allow me to take further advantage of your knowledge, when you say 'the 24-bit-Textures are blended additively, so they cannot be used for ordinary texture mapping', how does that effect the rendered images of 24-bit textures using an AGP card in TAW, i.e. what would you anticipate for an abnormal effect and do you know of a solution (eg. manipulation of environmental colors?)?

Link to post
Share on other sites
Thanks and please allow me to take further advantage of your knowledge, when you say 'the 24-bit-Textures are blended additively, so they cannot be used for ordinary texture mapping', how does that effect the rendered images of 24-bit textures using an AGP card in TAW, i.e. what would you anticipate for an abnormal effect and do you know of a solution (eg. manipulation of environmental colors?)?
Well, you can see the effect quite well here, with "normal" blending in the first and additive blending in the second image. A TAW mesh rendered with additive texture blending would look somehow like this:

adden.png

This ghostly effect is well-desired for lense flare, glare and all the other effects TAW uses 24-bit color textures for.

Keep in mind that this is true only for 24-bit textures, i.e. the 48 KiB huge 128×128 pixel RAW files in the agp\ folder. The 16 KiB 64×64 RAW files in the same folder with 32 bits color depth are rendered just the 'normal' way everyone expects them to.

The sidelength is another caveat: Instead of getting 256×192 textures with 256 colors, we would get 64×64 textures in true color. So technically we just change resolution for color quality.

Consider that this is pure speculation at this point. I have yet to understand how TAW manages the colors of 24- and 32-bit textures — for example, zsam.3 currently looks like this:

zsam3.png

(These are two 24-bit textures in action. I remember missiles having blue and red trails with the Direct3D version, but I highly doubt it looked like this :( I always suspect this is a problem with linear color space and gamma correction, but I've proven my gamma pipeline correct multiple times … and it looks O.K. on many models, e.g. F-22's position lights …) So, there's still a long way to go and there's still lots of code to understand and write before we can discuss such things in detail …

… but that's just my opinion. Mike has done great studies on TAW's internals, and maybe he has more information :)

Link to post
Share on other sites

I don't have access to my TAW files right now, but DrKevDog, do you remember those noname files with the newhoriz.3 and large 24 bit colour textures that we were looking at a couple of years ago?

if so, could you remind me which ones were involved?

Might be time to revisit them....

Link to post
Share on other sites

I don't have access to my TAW files right now, but DrKevDog, do you remember those noname files with the newhoriz.3 and large 24 bit colour textures that we were looking at a couple of years ago?

if so, could you remind me which ones were involved?

Might be time to revisit them....

Well yes: 3986 is the AGP newhoriz.3 file and the 24bit 384 x 256 T.O.D. textures are 1317, 3042, 4472, 4530, 4963, 5026, 5398, 5911, 5993, 6450 and 6513.

I believe he is limited to the visible AGP slots and IIRC, the attributes, such as blend mode, are coded to the index slots.

Link to post
Share on other sites

Well yes: 3986 is the AGP newhoriz.3 file and the 24bit 384 x 256 T.O.D. textures are 1317, 3042, 4472, 4530, 4963, 5026, 5398, 5911, 5993, 6450 and 6513.

I believe he is limited to the visible AGP slots and IIRC, the attributes, such as blend mode, are coded to the index slots.

:o 384×256 24-bit? T.O.D. means Time Of Day? Are these encoded in the same way as 128×128 RGB?

Any more stuff like that? The earlier I know, the less code needs to be changed when I eventually have to implement it …

Link to post
Share on other sites

I guess we're all annoyed by these always same-looking screenshots, so I quickly wrote an SSD prototype:

ssdh.png

This is aden_c.3. But as you can see, the object's XYZ positions are still wrong … (scale factors, rotation and Z order isn't implemented either). I wonder how to work that out. But anyway, it's a proof that the renderer can handle multiple files with multiple positions, and that's a step forward.

Also: Sorry for these permanent questions, DKD … you've written an excellent article on how TAW handles the red****.ini files in the TAW Wiki; I should just have rtfm :rolleyes: I just re-discovered it when looking for information on SSDs.

Link to post
Share on other sites

I guess we're all annoyed by these always same-looking screenshots, so I quickly wrote an SSD prototype:

This is aden_c.3. But as you can see, the object's XYZ positions are still wrong … (scale factors, rotation and Z order isn't implemented either). I wonder how to work that out. But anyway, it's a proof that the renderer can handle multiple files with multiple positions, and that's a step forward.

Also: Sorry for these permanent questions, DKD … you've written an excellent article on how TAW handles the red****.ini files in the TAW Wiki; I should just have rtfm :rolleyes: I just re-discovered it when looking for information on SSDs.

Nice pic, I can't wait to get the viewer up and running. Crazy busy now, I'm hoping this week I'll get some time to complete the new build and get on with it :)

Thanks for the compliment, as you stated previously, much remains to be completed ;)

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