yes, I found all the 384kb textures (SKY0800-2200). Still searching for SKY0000 and SKYNVG which are other than 384kb's. The AGP sky texture appears coarse in the game and yet I'm fairly certain It is partly a function of the fact that I do not have all the variables ironed out.

I tried a quick manipulation of the textures in TAW by altering the .ini file. When I subed "Material" at position 322 I get a ERROR : Unable to find .\agp\material.raw.
version 5.191 by on Nov 16 1998.
When I sub flare1.raw, a 16kb .raw file, I get: ERROR : File .\agp\flare1.raw size does not match expectated size.
Substituting the SKY1000 for SKY0800 at the 322 position I get: "fadetab: invalid fade table 12" so the fade tables must be compatible or TAW crashes.

If my figures are correct, the 12 textured rectangles described in the expanded newhoriz.3 file are roughly: 512x2(3), 512x150(3), 512x50(3) and 512x55(3).

Seeing that all of the 0047 opcodes in the file give only the 0142 (322h=sky0800) textures, there must be a mechanism to advance with T.O.D. to the appropriate texture index position. (?)

Doesn't seem to be, but you could just put the appropriate 'skyXXXX.raw' file in slot 322 for each of the corresponding 'redXXXX.ini' files.

I had a look at some of those 384kb files and they definitely look like sky, when opened as 24 bit colour with size 512x256. If zoomed in, the colour gradient isn't smooth, which is maybe why it looks course in the game.



DKD, you've made a great find here.

Mikew,

I am grateful for the knowledge you share regarding this project, it makes this TAW puzzle more fun to discover

I don't believe I have the SKY.raw files exactly matched up with their correct T.O.D. in the AGP folder so some of the sky textures don't match the horizon band of color... that said, I do get different sky textures based on the T.O.D. so I am wondering, since there is only one newhoriz.3 file with only 322 position references, if there is an algorithm (somewhere in the process) that selects for the correct redXXXX.ini index position?

I tried substituting the SKY1000.raw for SKY0800.raw at the 322 position I get: "fadetab: invalid fade table 12". Apparently the fade tables must be compatible with the Sky texture used or TAW crashes. IIRC the fade tables are related to the sky as visualized in the AWACS 3D window. I did find a number of unused "noname" fade tables in the Multiex extracted files.


Thanks for posting the pics of the raw files, for some reason my photoshop and irfanview pics were less well defined.


I did some comparison last night with the AGP-sky at 2200 vs the non-AGP-sky on my PCI/Glide PC and the textured sky at night is far superior

I am not sure I communicated my point on the T.O.D. issue very well, so I'll try expanding it. The information that motivated me to consider the utilization of .ini positions 322-329 was obtained from a noname .ini type file that begins with:

[dir]
TM=hardware.tm

tha section of current interest is listed:

322=sky0800
323=sky1000
324=sky1200
325=sky1400
326=sky1600
327=sky1800
328=sky2000
329=sky2200
310=sky0000
311=skynvg

What you say regarding the lone 322 position seems logical, and I'll plan to do some further testing this evening, however, I am interested in finding out if the above .ini file is a clue to how the AGP-SKY textures are used in general or if their is seperate special TAW application which utilizes only the above .ini file

I'm sure it was me that misunderstood, but I can't see a mechanism to change TOD in the newhoriz.3 file...even the one you found.

There may be a way around this though. For the building .3 files, there is a decision point based on TOD which is used to draw the shadows. It may be possible to use the same process to select different skyXXXX.raw files.

I really need to get the textured sky working on my machine, as I am still not sure what is going on here. Is it really possible to use textures of 512x256 and colours which are not from a palette???? Sounds too good to be true.

Gents,

This might be something huge. Being that hexidecimal is not my strength (too long looking at it and my head explodes), I apologize if I ask questions that may have already been answered.

1) Are you saying that the skyxxxx gradients are actually being used in extracted TAW (D3D renderer), or that files are called which are still unnamed (which explains the coarse gradient)?

2) If the gradients are in use in D3D, I understand that they must be matched to the palette. Does this mean they also must be matched to the time of day? (a way to find out might be to swap the names of two palettes, then swap the names of sky files or swap addressses of sky files in the noname.ini)?

Just thinking out loud, this discovery might be the key to fix my NVG mod in D3D by swapping the rednvg and redmoon/rednomo palettes without having to deal with the green gradient that isn't swapped. See this thread for further details.

Thanks,

HF, I'm having problems understanding what's going on as well.

I thought I'd take it step by step and just swap the original newhoriz.3 file with the one DKD found. I was expecting a crash but instead, the game ran as normal.
The particular PC I tried this on has a hardware problem in that even though an AGP graphics card is fitted, the AGP capability is not recognised by the video driver or DirectX. So, this may prove that the 00A3 opcode is related to AGP since then the newhoriz.3 'code' will select the coloured polygons instead.

DKD, is this a correct assumption?

Mike,

Feel free to send me any files. I can test them on an agp platform.

Yes, that is the working hypothesis. I believe opcode 00A3 is related to AGP. Over the years I have modified many aspects of my TAW files and so there are many potential confounding variables in this equation, that said, I am now in the process of reinstalling and rebuilding TAW from it's default configuration and adding the extracted components, progressively and incrementally until the AGP Sky appears. Hopefully I can get a read on how this is implemented.
I should be back with some results momentarily.

I believe the series of tests confirm my hypothesis and the results are reproducable. I started with a new TAW install, converted it to a virgin extracted files program and added components until I arrived at the point of viewing a non-palette derived textured sky.

The necessary components are:

1. AGP Graphics card/ Extracted TAW running in hardware mode
2. Collection of 384kb SKYXXXX.raw textures placed in the AGP directory
3. The extracted noname newhoriz.3 with expanded AGP code
4. modified redXXXX.ini files to include:

322=sky0800
323=sky1000
324=sky1200
325=sky1400
326=sky1600
327=sky1800
328=sky2000
329=sky2200
;310=sky0000
;311=skynvg

One of the curious observances on this trial was the fact that placing only the "322=SKYXXXX" line, as opposed to the entire block, in the redXXXX.ini file resulted in the entire sky (minus the lower horizon band) being black