I have been working on multiple TAW upgrade projects, however, there are two which are considered major projects. I will discuss one of them, the Surface Texture Solution Project, here.

This project started out as a simple desire to solve one of the problems of TAW, visual target acquisition and to upgrade the graphics, at least temporarily until we can get some more permanent model upgrades.
In an effort to define the problem some of you were having with the difficult target acquisitions issue, I identified one major obstacle to obtaining improved targets was the muted default textures which are often difficult to see, especially against the background of the bright new terrain colors in 2.0.

In order to accommodate for that problem I attempted to modify the code in the .3D object files but was frustrated by the inflexibility of the coding. Therefore I discovered a method to exploit the channels used for texture mapping.

In general, the .3 file determines the texture or the color of the specific object as Mikew previously explained:




In TAW Texture mapping of building textures is switched on or off in Game.cfg using the key “BUILD_TEXTURE =1” or 0. If the textures are off (0), then the indexed texture is not used, in this case, the program uses the color determinants for the vertex indices which are given after the palette index in that string. If the texture is off in options the executable will only use the colors coded. Until now, these were the only options a player was priviledged to use. Now that has changed and a great many new options are going to be made available as I have determined that, if the Textures are ON the executable calls the time appropriate Redxxxx,ini file [surface] section which is where I found a way to intercept and manipulate the process for graphically improved targets. The [surface] section will accommodate, and defaults to, texture mapping. It will now also however accommodate a total of four types of surface treatments:

1.) Textures: txtr
2.) Colors: colr
3.) Flat Shading: flat
4.) Gourard Shading: gour

I have developed a number of full Templates to facilitate the efficient import of texture shader transitions into the redxxxx.ini files. Below I have given the first few lines of several of my basic Templates.

Examples:
TAW DEFAULT TEMPLATE
[surface]
0=txtr 4,(0,0),(31,0),(31,31),(0,31);N CONCRETE
1=txtr 4,(32,0),(63,0),(63,31),(32,31) ;NE CONCRETE
2=txtr 4,(64,0),(95,0),(95,31),(64,31) ;E CONCRETE

GOURAUD SHADER TEMPLATE
[surface]
0=gour ;N CONCRETE
1=gour ;NE CONCRETE
2=gour ;E CONCRETE

COLOR TEMPLATE
[surface]
0=colr ;N CONCRETE
1=colr ;NE CONCRETE
2=colr ;E CONCRETE

FLAT SHADER TEMPLATE
[surface]
0=flat ;N CONCRETE
1=flat ;NE CONCRETE
2=flat;E CONCRETE



The colors and shades of the individual polygon (tris and quads) vertices can be individually and specifically implemented and controlled by describing the desired index value.

Example:

[surface]
0=flat 6,7,8,9 ;N CONCRETE

ie. Flat shading of polygons progressing from the palettes Dark red (index=6) to Bright light red (index=9).

Assigning vertex shading values can control the Lighting conditions within the graphics environment using the directional assignment keys (;N, NE:, etc). This is a marvelous way to simulate time of day conditions, sun, moon effects. (It must be kept in mind, however that 3D object rotational variations must be considered for proper lighting effects outcomes). Flat shading, while one of the earlier shading techniques, works well and can be advantageous for TAW because of its significant improvement when used in the modeling of boxy objects.

Example:

[surface]
0=flat 0,0,0,6 ;N CONCRETE
1=flat 0,0,0,6 ;NE CONCRETE
2=flat 0,0,0,7 ;E CONCRETE
3=flat 0,0,0,7 ;SE CONCRETE
4=flat 0,0,0,8 ;S CONCRETE
5=flat 0,0,0,8 ;SW CONCRETE
6=flat 0,0,0,9 ;W CONCRETE
7=flat 0,0,0,9 ;NW CONCRETE
8=flat 0,0,0,0 ;BOT CONCRETE
9=flat 0,0,0,0 ;TOP CONCRETE

The Gouraud Shader is the smoothest and most advanced of the shaders in this application. The volatility of the color transitions was initially difficult for me to control. Mostly as a result of the shaders color interpolations of the 3D models specular highlights. Because TAW surface objects have large polygons with low counts, Gouraud interpolates the specular highlights at the vertices and then produces the progression of the highlight across neighboring polygons with a “fade-in”, “fade-out” pattern that, with any rotation of the object or the viewers perspective, gives off an intense color barrage. I have been able to better control that volatile interpolation pattern but still working on a best solution.


Digital Image Design continues to impress (especially that Steve Hunt guy), with each discovery, the talent, skill and dedication they placed in this simulation. For reasons of their choosing, DID determined to use textures exclusively for their surface object solution. It was, apparently, the simplest practical solution to implement in 1997, given the state of PC power and graphics at the time.
It is important to note that truly good power resides within the TAW palette, as the colors have true functional affective capacity and can dictate events in the game experience. A part of the ongoing challenge is to discover the functional impact of all given colors, textures and shaders.

It would seem logical that a significant enhancement to TAW can now be had by implementing a hybrid solution upgrade. That is, using a combination of textures, colors and shaders.

I now submit to you the Power of the Palette…(textures colors and shaders included)

Any Questions?

Great stuff, DKD.

I noticed that the Gouraud shader uses the palette ever since I tweaked with the 4th row of the palettes for 2.0 and noticed that some of the ground targets looked kind of funny. I since move the colors that are not part of the original gradient to the top end of the row to minimize the effect on the graphical anomaly, but I was wondering if it was possible to limit the number of palette slots used in the gradient (i.e. using slots 48-56 instead of slots 48-63).

Can certainly work on a method to reduce the gradient slots. The colors you wish to eliminate are primarily for terrain textures so I'm a bit unsure of what you are refering to as "ground targets". Are you refering to ground mobiles or static targets? Are you saying that the code for those objects automatically applies the shader to the polygon colors? Do you recall which objects were effected?

for ground targets, I'm referring to mobile targets such as the M1, the T80, the trucks, as well as some of the aircraft (cargo birds come to mind).

Just go to the custom mission menu and tab through the ground and air targets to see what I mean. When they use a desert pattern, they use the full row 4 for the gradient.

Very impressive DKD, any chance of some screen shots showing this in action?

Yes, just replace the 63 with 56 in the appropriate lines.

In this example of the shaded triangle:
004CBABAC000
0080000500060004 two of the vertices have a colour of BA(186) and the other C0(192).

This can be visualised by stretching the palette into two dimensions and plotting the palette positions of the colours:

Nice. Might give this a look for 2.03 or later.

These are early trials and are designed to find a scheme that is complimentary to the 2.0 terrain. This set includes a combination of Gouraud shading and Flat shading mixed with conventional TAW Textures and weighted toward Gauraud. The addition of the Gauraud component is not well appreciated by the viewer outside of the game environment.

Wow, DKD. Great find, and these enhancements can certainly spruce up the look in TAW 2.0.

If you're interested in conforming to the 2.0 look, you can probably just as easily make them work for legacy TAW. Using the 1200 palette a base, I made major changes to the sky colors (row 9, 2nd half of row 2), water colors( row 8), and the upper half of the sand colors in row 4. Sure, I made differences in the palettes based off the 1200 palette, but the colors were adjusted in something of a linear fashion.

In other words, what you make work for 2.0 is likely to work for 1.0 as well.

Realizing that you are using the greens and blacks to illustrate your changes (rather than use them as final colors), I have some recommendations for color selection:

For Concrete/Buildings, use row 13 (colors 192-207). Row 12 can be used if necessary, since these colors are often directly related to buildings.

For ocean colors (row 8), limit yourself to colors 118-124.

For Tans, limit yourself to row 3 and row 4 only up to color 56. If you wish to use the tans in rows 12/13, have at it!

For Greens, have at it. No restrictions.


One thing also to note: with Glide there are two palettes (east/west) for sunrise and sunset timeframes (0600, 0800, 1800, 2000). In these timeframes the terrain colors or water have not changed. However, the sky colors and the colors in rows 12/13 differ between palettes in order to show sun glare. These colors are brighter on the darker sky palette, showing the sun shining on the direction you are looking if you look away from the sun.

For example, at 1800 you will see a bright orange as you look west, where the sun is setting. In this direction, the buildings will appear "normal" because you are looking at the shadow side of them. If you look east at 1800, you will see a darker sky, but the buildings will have an orange hue because you're looking at the side of the building receiving the setting sun.

I mention this because you will want to test your settings in glide and make sure the buildings look OK from both directions.

The behavior of the "colr" type seems similar if not identical to the "gour" type. That seems redundant and illogical. The switch statements for the different surface types are: txtr, colr, gour and fade. The code uses a jump table to direct the 4 switch statements:

align 10h
; jump table for switch statement


AUTO:00574F60 off_574F60......dd offset loc_575002
AUTO:00574F60......................dd offset loc_5750A3
AUTO:00574F60......................dd offset loc_5750A3
AUTO:00574F60......................dd offset loc_5750E8
AUTO:00574F70


If I am interpreting this correctly, It appears that 2 of the types jump to the same subroutine. Even so there could be some distinguishing differences.

Could someone take a look at the code in the executable and see what you come up with?

Thanks

Okay, so lets GO ARMY!

(Army green that is)















The shading for light affects is correct but better appreciated in game. These are Gouraud shaded with paletted textures. Kept it very basic, as you requested

Feedback?