Project Perfect Mod Forums
:: Home :: Get Hosted :: PPM FAQ :: Forum FAQ :: Privacy Policy :: Search :: Memberlist :: Usergroups :: Register :: Profile :: Log in to check your private messages :: Log in ::


The time now is Thu Mar 28, 2024 7:17 pm
All times are UTC + 0
TMP File Format (has damaged art)
Moderators: Community Tools Developpers
Post new topic   Reply to topic Page 1 of 1 [33 Posts] Mark the topic unread ::  View previous topic :: View next topic
Author Message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Mon May 02, 2016 6:45 am    Post subject:  TMP File Format (has damaged art) Reply with quote  Mark this post and the followings unread

Does anyone know how this works? I thought it would be only a simple boolean switch (one bit being either 0 or 1), but noticed there are some complex numbers involved.

A TMP has a main header and a header for each tile.
This is the header for each tile that i got from the XCC code IIRC
{
   __int32 x;                          // position
   __int32 y;
   __int32 unknown1[3];
   __int32 x_extra;                    // position of extra graphics
   __int32 y_extra;
   __int32 cx_extra;                   // size of extra graphics
   __int32 cy_extra;
   __int32 unknown2[4];
};

unknown2[4] seems to be the one defining HasDamagedArt

I compared what TMP Studio writes in this. It writes
2 for no damaged art
6 for damaged art

however, when i checked original TS files, i got values like
-842150449
and
-842150450
on different tiles (see isotemp.mix/ovrps01.tem)

While this is a value set separately on each tile in a TMP, TMP Studio writes it to all frames, not only the currently selected tile.
So i'm not sure if TMP Studio got the implementation correct in the first place.

e.g. on ovrps01, TMP Studio says that it has damaged art, yet there are different values set on individual tiles.


P.S. any infos about unknown1[3] would be nice too.

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Mon May 02, 2016 10:43 am    Post subject: Reply with quote  Mark this post and the followings unread

HasDamagedArt works on a per cell basis, so TMP Studio's implementation is incorrect. However because of the limited way the logic works there isn't much need to use it per cell. So technically TMP Studio's implementation is more efficient XD

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Mon May 02, 2016 10:52 am    Post subject: Reply with quote  Mark this post and the followings unread

I'd assume the per tile base of the setting is to make sure some tiles auto-LAT to adjacent tiles, while others don't.

I think I'll make TMP Shop in a way so the user can decide how and what kind of values he wanna set (for experimentation with other values/settings).

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Mon May 02, 2016 11:01 am    Post subject: Reply with quote  Mark this post and the followings unread

AFAIK HasDamagedArt has nothing to do with the LAT system?

Random question; I can't remember if TMP Shop has a batch pal conversion option?

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
tomsons26lv
Cyborg Artillery


Joined: 30 Dec 2009
Location: Latvia

PostPosted: Mon May 02, 2016 11:12 am    Post subject: Reply with quote  Mark this post and the followings unread

wat
What xcc source are you looking at

struct t_tmp_image_header
{
__int32 x;
__int32 y;
__int32 extra_ofs;
__int32 z_ofs;
__int32 extra_z_ofs;
__int32 x_extra;
__int32 y_extra;
__int32 cx_extra;
__int32 cy_extra;
unsigned int has_extra_data: 1;
unsigned int has_z_data: 1;
unsigned int has_damaged_data: 1;
__int8 height;
__int8 terrain_type;
__int8 ramp_type;
unsigned __int8 radar_red_left;
unsigned __int8 radar_green_left;
unsigned __int8 radar_blue_left;
unsigned __int8 radar_red_right;
unsigned __int8 radar_green_right;
unsigned __int8 radar_blue_right;
__int8 pad[3];

https://github.com/OlafvdSpek/xcc/blob/master/misc/cc_structures.h#L368

Knowing Olaf's laziness of actually doing any research but instead copy pasting stuff other people found, that pad ain't no padding but actual data too.

_________________
Tiberian Dawn, Red Alert, Tiberian Sun ,Red Alert 2,Renegade, Command & Conquer 3,Tiberium and Tiberium Wars and Westwood related image & video archive
https://picasaweb.google.com/113361105083292812413?noredirect=1

Skype live:tomsons26
Don't forget to state who are you otherwise i'll ignore the invite

Last edited by tomsons26lv on Mon Feb 12, 2018 1:38 pm; edited 1 time in total

Back to top
View user's profile Send private message Visit poster's website
E1 Elite
General


Joined: 28 May 2013

PostPosted: Mon May 02, 2016 12:00 pm    Post subject: Reply with quote  Mark this post and the followings unread

Just compared, looks like it is one more if there is extra data.

XCC, vanilla / TMP Studio

No damaged art with no extra data - CA CD CD CD / 02 00 00 00
No damaged art with extra data - CB CD CD CD / 03 00 00 00
Damaged art with no extra data - CE CD CD CD / 06 00 00 00
Damaged art with extra data - CF CD CD CD / 07 00 00 00

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Mon May 02, 2016 12:18 pm    Post subject: Reply with quote  Mark this post and the followings unread

@tomsons:
it's an old txt file from Olaf. It says copyright 2000. Wink

thanks for the updated header.

@E1 Elite:
wow, why did WW made that so complex o.O
Any insight why the difference between with and without extra graphic?

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Mon May 02, 2016 2:58 pm    Post subject: Reply with quote  Mark this post and the followings unread

hmm, there seems to be something missing.

tomsons26lv wrote:

struct t_tmp_image_header
{
__int32 x;
__int32 y;
__int32 extra_ofs;
__int32 z_ofs;
__int32 extra_z_ofs;
__int32 x_extra;
__int32 y_extra;
__int32 cx_extra;
__int32 cy_extra;
unsigned int has_extra_data: 1;
unsigned int has_z_data: 1;
unsigned int has_damaged_data: 1;
__int8 height;
__int8 terrain_type;
__int8 ramp_type;
unsigned __int8 radar_red_left;
unsigned __int8 radar_green_left;
unsigned __int8 radar_blue_left;
unsigned __int8 radar_red_right;
unsigned __int8 radar_green_right;
unsigned __int8 radar_blue_right;
__int8 pad[3];

those marked variables are only 3 (*)  byte long, but in the file between cy_extra and height are 4 byte.
So whats the 4th byte?

Is there a 4th unsigned int missing?

(*)or actually 6 byte, since isn't unsigned int in c++ a 2byte value? How can these 3 unsigned int 2 byte values work on only a 4 byte long range in the tmp?



I would expect something like this
__int32 cx_extra;
__int32 cy_extra;
__int8 has_extra_data;
__int8 has_z_data;
__int8 has_damaged_data;
__int8 unknown;
__int8 height;
__int8 terrain_type;


Quote:
unsigned int has_extra_data: 1;

What's the : 1 standing for? Is this some strange c++ range restriction setting to make unsigned int only 1 byte long, or just a default value?

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
Crimsonum
Seth


Joined: 14 Jul 2005
Location: Fineland

PostPosted: Mon May 02, 2016 5:57 pm    Post subject: Reply with quote  Mark this post and the followings unread

Lin Kuei Ominae wrote:
Quote:
unsigned int has_extra_data: 1;

What's the : 1 standing for? Is this some strange c++ range restriction setting to make unsigned int only 1 byte long, or just a default value?


Looks like a boolean, i.e. "Has extra data: true". Booleans are often represented by int in C. So yes, it would be a default value.

_________________


Back to top
View user's profile Send private message
E1 Elite
General


Joined: 28 May 2013

PostPosted: Tue May 03, 2016 7:00 pm    Post subject: Reply with quote  Mark this post and the followings unread

On
unsigned int has_extra_data: 1;
unsigned int has_z_data: 1;
unsigned int has_damaged_data: 1;

Only 3 bits from the same byte(s) is used for extra data, z data and damaged art check. So,  
low nibble (least significant) can have values from 0 to F. 4 bits in it are used as - ? D Z X
where D = Has damaged art, Z = Has z data, X = Has extra data

0 0 0 0 = 0 = D0 Z0 X0
0 0 0 1 = 1 = D0 Z0 X1
0 0 1 0 = 2 = D0 Z1 X0
0 0 1 1 = 3 = D0 Z1 X1
0 1 0 0 = 4 = D1 Z0 X0
0 1 0 1 = 5 = D1 Z0 X1
0 1 1 0 = 6 = D1 Z1 X0
0 1 1 1 = 7 = D1 Z1 X1
1 0 0 0 = 8 = D0 Z0 X0
1 0 0 1 = 9 = D0 Z0 X1
1 0 1 0 = A = D0 Z1 X0
1 0 1 1 = B = D0 Z1 X1
1 1 0 0 = C = D1 Z0 X0
1 1 0 1 = D = D1 Z0 X1
1 1 1 0 = E = D1 Z1 X0
1 1 1 1 = F = D1 Z1 X1

Back to top
View user's profile Send private message
CCHyper
Defense Minister


Joined: 07 Apr 2005

PostPosted: Wed May 04, 2016 12:02 am    Post subject: Reply with quote  Mark this post and the followings unread

How certain is the "HasDamagedArt" flag? From what I see, that flag has something to do with if the tile is randomized or not...

Back to top
View user's profile Send private message
RP
Commander


Joined: 12 Jul 2012
Location: Mapping God Heaven

PostPosted: Wed May 04, 2016 7:09 am    Post subject: Reply with quote  Mark this post and the followings unread

I always thought that 'damaged art' was nothing more than hardcoded behaviour for bridge heads which used randomized tiles for damaged art.

I have never seen anything when I programmed TMP files besides the special behaviour for bridgeheads.
IIRC there's nothing in IsoMapPack5 that indicates alternative versions for tiles.
Every tile is loaded in one big list.

_________________


Mental Omega 3.0 Mission creator - Creator of FinalOmega: APYR 3.0 Map Editor

/ppm/'s stupidity

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Wed May 04, 2016 7:41 am    Post subject: Reply with quote  Mark this post and the followings unread

A TileSet can contain multiple TMP files using the filename suffix a-h.
e.g. clear01.tmp, clear01a.tmp, clear01b.tmp

If i understand it correct, the random tile selection ingame doesn't work if the tmps have the value DamagedArt set.
Only when disabled, they use the random selection.

Bridges for example use
ovrps01.tmp for the normal image and
ovrps01a.tmp for the damaged version.
On these TMPs the tiles have damaged art set, so they don't randomly switch between the different TMPs.


@E1 Elite: thanks for the info. I'll try to implement it in this way, though i'm still confused about the values of the vanilla TS files.
If i understand you correct, only 1 byte should actually change.
e.g. CA CD CD CD
But on the vanilla TS files all 4 bytes constantly change the values.
See the latest version of TMP Shop and switch into "Single Frames" mode.
If you have the 4 bytes
AA BB CC DD
TMP Shop is showing
AA on "Has Extra Data"
BB on "Has Z Data"
CC on "Has Damaged Data"
DD on "unknown Data"

Following your description, only "Has Extra Data" should change, while the other 3 stay the same.

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
E1 Elite
General


Joined: 28 May 2013

PostPosted: Wed May 04, 2016 7:55 am    Post subject: Reply with quote  Mark this post and the followings unread

@RP:
If the Has Damaged Art bit is set to 1, then game will not randomize the tiles. XCC TMP Editor 1.04
that comes with XCC utilities sets it to 1 by default if edited. So, XCC TMP Editor 1.05 should be used.

This thread started because of the ramp tiles didn't ramdomize in Crimsonum's edit:
http://www.ppmforums.com/viewtopic.php?p=544088#544088

@LKO:
If the 4 bytes are say XN XX XX XX in the TMP files, we are concerned only about the nibble represented
by N. X can be anything in 0-F. Vanilla uses CD whereas TMP Studio 00 which is anyhow irrelevant.
Within the nibble also 1 bit is unused, so the 3 bit means the same when you put A or 2. It is not in 4
seperate bytes but only 3 bits within just a nibble.

Back to top
View user's profile Send private message
CCHyper
Defense Minister


Joined: 07 Apr 2005

PostPosted: Wed May 04, 2016 2:04 pm    Post subject: Reply with quote  Mark this post and the followings unread

I have not seen reference to the other flag (4th bit), has anyone seen any difference with this bit toggled?

Back to top
View user's profile Send private message
E1 Elite
General


Joined: 28 May 2013

PostPosted: Wed May 04, 2016 3:23 pm    Post subject: Reply with quote  Mark this post and the followings unread

There is no difference whether the 4th bit is 0 or 1.

Back to top
View user's profile Send private message
CCHyper
Defense Minister


Joined: 07 Apr 2005

PostPosted: Wed May 04, 2016 4:34 pm    Post subject: Reply with quote  Mark this post and the followings unread

E1 Elite wrote:
There is no difference whether the 4th bit is 0 or 1.


I was thinking as much, as I am unable to find any reference in the games code to a 4th bit.

Back to top
View user's profile Send private message
E1 Elite
General


Joined: 28 May 2013

PostPosted: Fri May 06, 2016 3:54 pm    Post subject: Reply with quote  Mark this post and the followings unread

Checked TS/RA2 vanilla files, could only find - C? CD CD CD pattern. If some file is different, let me know.

On earlier post:

Even though the C Struct is kept close to file format, it need not match the bytes exactly. Actual mapping
might be happening when reading from and writing to the file.

Typical int in C is 4 bytes on 32-bit OS. (minimum is 2 bytes)

A declaration like - unsigned int x: 5;  means variable x can hold 5 bits of data.

For the tool:

If the flags of extra data or z data are disabled, the related data is not shown on the UI by tools and while
saving, those related content could be removed. Game also doesn't seem to use them when these flags are
disabled, even though the related content exists. If these flags are provided as editable fields, enabling them
on a tile that doesn't have the related data, it would need more editing capability like importing images and
coordinates editing etc.

Back to top
View user's profile Send private message
MadHQ
Commander


Joined: 07 Nov 2003

PostPosted: Thu Apr 19, 2018 12:53 am    Post subject: Reply with quote  Mark this post and the followings unread

tomsons26lv wrote:
wat
What xcc source are you looking at

struct t_tmp_image_header
{
__int32 x;
__int32 y;
__int32 extra_ofs;
__int32 z_ofs;
__int32 extra_z_ofs;
__int32 x_extra;
__int32 y_extra;
__int32 cx_extra;
__int32 cy_extra;
unsigned int has_extra_data: 1;
unsigned int has_z_data: 1;
unsigned int has_damaged_data: 1;
__int8 height;
__int8 terrain_type;
__int8 ramp_type;
unsigned __int8 radar_red_left;
unsigned __int8 radar_green_left;
unsigned __int8 radar_blue_left;
unsigned __int8 radar_red_right;
unsigned __int8 radar_green_right;
unsigned __int8 radar_blue_right;
__int8 pad[3];

https://github.com/OlafvdSpek/xcc/blob/master/misc/cc_structures.h#L368

Knowing Olaf's laziness of actually doing any research but instead copy pasting stuff other people found, that pad ain't no padding but actual data too.


Topic revival!!!

So is this the most current correct file structure for terrain tiles?

I ask because I loaded clear01.tem, and the results are shown below.

fileSize:1872
cblocksX:1                             <-4 byte
cblocksY:1                               <-4 byte
cx:60                                       <-4 byte
cx:60                                        <-4 byte

x:20                                          <-4 byte
y:0                                             <-4 byte
extraOfs:0                                  <-4 byte
zOfs:1852                                   <-4 byte
extraZOfs:952                              <-4 byte
xExtra:3452816845                       <-4 byte
yExtra:3452816845                       <-4 byte
cxExtra:3452816845                      <-4 byte
cyExtra:3452816845                      <-4 byte
hasExtraData:3452816845              <-4 byte
hasZData:3452816842                   <-4 byte
hasDamagedData:2717912320       <-4 byte
height:168                                   <-1 byte
terrainType:80                              <-1 byte
rampType:163                              <-1 byte
radarRedLeft:167                         <-1 byte
radarGreenLeft:80                        <-1 byte
radarBlueLeft:205                       <-1 byte
radarRedRight:205                      <-1 byte
radarGeenRight:205                    <-1 byte
radarBlueRight:63                       <-1 byte    <-- this is wrong, this value is the 1st pixel in the tile

filePointer:79


After looking at the data it looks like I am 1 byte off... if I do not read 'radarBlueRight' I get the expected values...

__int8 pad[3]; <- I completely have to skip this pad byte read.

_________________
MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.)

Back to top
View user's profile Send private message Skype Account
MadHQ
Commander


Joined: 07 Nov 2003

PostPosted: Thu Apr 19, 2018 2:46 am    Post subject: Reply with quote  Mark this post and the followings unread

After another pass I guess 'unsigned int' is 2 bytes.

I also added c_Files... I have no idea what that is...

Problem is I am still reading 2 extra bytes... Is hasZData & hasDamagedData only 1 byte each?

fileSize:1872

4 bytes -> cblocksX:1
4 bytes -> cblocksY:1
4 bytes -> cx:60
4 bytes -> cx:60

4 bytes -> cFiles:20

4 bytes -> x:0
4 bytes -> y:0
4 bytes -> extraOfs:1852
4 bytes -> zOfs:952
4 bytes -> extraZOfs:3452816845
4 bytes -> xExtra:3452816845
4 bytes -> yExtra:3452816845
4 bytes -> cxExtra:3452816845
4 bytes -> cyExtra:3452816845
2 bytes -> hasExtraData:52682
2 bytes -> hasZData:52685
2 bytes -> hasDamagedData:3328
1 bytes -> height:0
1 bytes -> terrainType:162
1 bytes -> rampType:168
1 bytes -> radarRedLeft:80
1 bytes -> radarGreenLeft:163
1 bytes -> radarBlueLeft:167
1 bytes -> radarRedRight:80
1 bytes -> radarGeenRight:205
1 bytes -> radarBlueRight:205
1 bytes -> junkOne:205
1 bytes -> junkTwo:63               <---- 1st pixel in tile
1 bytes -> junkThree:63             <---- 2nd pixel in tile

filePointer:74

If i change hasZData & hasDamagedData to one byte and split hasExtraData into two individula bytes I see this...

fileSize:1872

4 bytes -> cblocksX:1
4 bytes -> cblocksY:1
4 bytes -> cx:60
4 bytes -> cx:60

4 bytes -> cFiles:20

4 bytes -> x:0
4 bytes -> y:0
4 bytes -> extraOfs:1852
4 bytes -> zOfs:952
4 bytes -> extraZOfs:3452816845
4 bytes -> xExtra:3452816845
4 bytes -> yExtra:3452816845
4 bytes -> cxExtra:3452816845
4 bytes -> cyExtra:3452816845
1 bytes -> hasExtraData:202             <- no idea what this is
1 bytes -> hasExtraDataUnknown:205      <- no idea what this is
1 bytes -> hasZData:205
1 bytes -> hasDamagedData:205
1 bytes -> height:0
1 bytes -> terrainType:13
1 bytes -> rampType:0
1 bytes -> radarRedLeft:162
1 bytes -> radarGreenLeft:168
1 bytes -> radarBlueLeft:80
1 bytes -> radarRedRight:163
1 bytes -> radarGeenRight:167
1 bytes -> radarBlueRight:80
1 bytes -> junkOne:205
1 bytes -> junkTwo:205
1 bytes -> junkThree:205

filePointer:74


This looks more correct... I am not sure about hasExtraData & hasZData & hasDamagedData

_________________
MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.)

Back to top
View user's profile Send private message Skype Account
E1 Elite
General


Joined: 28 May 2013

PostPosted: Thu Apr 19, 2018 5:13 am    Post subject: Reply with quote  Mark this post and the followings unread

As already explained above

unsigned int has_extra_data: 1;
unsigned int has_z_data: 1;
unsigned int has_damaged_data: 1;

These hold only 1 bit of data.

So in the vanilla files, if it looks like C5 CD CD CD would mean
0 1 0 1 = 5 = hasDamagedData is yes, hasZData is no, hasExtraData is yes.

Only the least significant nibble is used.

Back to top
View user's profile Send private message
MadHQ
Commander


Joined: 07 Nov 2003

PostPosted: Thu Apr 19, 2018 11:41 am    Post subject: Reply with quote  Mark this post and the followings unread

I think there is a missing byte in that structure.

also, a little off topic but this is my understanding of these data types...

unsigned int <- I base my size of this datatype off C, so this is 2 or 4 bytes.

__int8 & unsigned __int8 <- these are 1 byte each why bother with "unsigned"

Some times these file structures drive me a little crazy.

_________________
MadHQ's Graveyard - Click here!
(Permissions) - (F.A.Q.)

Back to top
View user's profile Send private message Skype Account
Blade
Cyborg Commando


Joined: 23 Dec 2003

PostPosted: Thu Apr 19, 2018 1:45 pm    Post subject: Reply with quote  Mark this post and the followings unread

In C on 32bit and 64bit platforms, int and unsigned int are 32bit. However you have missed the :1 on those 3 boolean values. Those are bitfield entries, they take up a single bit within the bitfield (which will be 32bit due to compiler alignment). The other bits in the 32bit int aren't used and so can be set to any value without consequence.

unsigned __int8 has a value between 0 and 255, __int8 is most likely signed and so has a value of -128 to 127 IIRC.

Back to top
View user's profile Send private message
tomsons26lv
Cyborg Artillery


Joined: 30 Dec 2009
Location: Latvia

PostPosted: Thu Apr 19, 2018 2:06 pm    Post subject: Reply with quote  Mark this post and the followings unread

ztype it im burning the book, starting from scratch

//The IsoTile consists of this

RGB
{
unsigned char Red;
unsigned char Green;
unsigned char Blue;
}

IsoTileHeader
{
unsigned int BlockWidth; // width of blocks
unsigned int BlockHeight; // height in blocks
unsigned int BlockImageWidth; // width of each block
unsigned int BlockImageHeight; // height of each block
};

//Following the header are pointers to each Tile, count is probably gotten by BlockWidth* BlockHeight

IsoTileImageHeader
{
signed int TileX; //X offset of the tile
signed int TileY; //Y offset of the tile
unsigned int ExtraDataOffset;
unsigned int ZDataoffset;
unsigned int ExtraZDataoffset;
signed int ExtraX; //X Offset for tile "extra"
signed int ExtraY; //X Offset for tile "extra"
unsigned int ExtraWidth;
unsigned int ExtraHeight;
unsigned char Bitfield; // known bits HasExtraData, HasZData, HasDamagedData
BYTE padding[3]; // padding made by default MSVC alignment of 0x4
unsigned char Height;
unsigned char TerrainType;
unsigned char RampType;
RGB LowRadarColor; // What color to show on the radar for this set at the lowest height
RGB HighRadarColor; // What color to show on the radar for this set at the highest height
BYTE padding[3]; // padding made by default MSVC alignment of 0x4
}

//Note seems Westwood forgot to clear allocated memory so a lot of tiles have 0xCD in them(0xCD is the default value newly allocated uncleared memory is set to in MSVC)

This all is likely to be revisited as more is discovered

_________________
Tiberian Dawn, Red Alert, Tiberian Sun ,Red Alert 2,Renegade, Command & Conquer 3,Tiberium and Tiberium Wars and Westwood related image & video archive
https://picasaweb.google.com/113361105083292812413?noredirect=1

Skype live:tomsons26
Don't forget to state who are you otherwise i'll ignore the invite

Last edited by tomsons26lv on Thu Apr 19, 2018 6:02 pm; edited 16 times in total

Back to top
View user's profile Send private message Visit poster's website
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Thu Apr 19, 2018 2:20 pm    Post subject: Reply with quote  Mark this post and the followings unread

updated with fields how i use them in TMP Shop
tomsons26lv wrote:
//The IsoTile consists of this

IsoTileHeader
{
unsigned int MapWidth;
unsigned int MapHeight;
unsigned int Width;
unsigned int Height;
};

//Following the header are pointers to each Tile, count is probably gotten by MapWidth* MapHeight

IsoTileFrameHeader
{
long offset; // offset of the tile in the file. Is 0 for empty tile
unsigned int TileX; //X offset of the tile
unsigned int TileY; //Y offset of the tile
unsigned int extra_offset; //offset of extra data
unsigned int z_offset; //z_data offset
unsigned int extra_z_offset; //offset of extra z_data
signed int ExtraX; //X Offset for tile "extra"
signed int ExtraY; //X Offset for tile "extra"
unsigned int cx_extra; //width of extra graphics
unsigned int cy_extra; //height of extra graphics
DWORD Bitfield; // known bits HasExtraData, HasZData, HasDamagedData
unsigned char Height;
unsigned char TerrainType;
unsigned char RampType;
unsigned char RadarRedLeft; //The C&C engine has some complex bitshifting to determine color mode by calculating Left and Right shifts of colors, these results are then used in drawing, having these in here simplifies things as the game doesn't need to calculate this then.
unsigned char RadarGreenLeft;
unsigned char RadarBlueLeft;
unsigned char RadarRedRight;
unsigned char RadarGreenRight;
unsigned char RadarBlueRight;
BYTE[3] padding;
}

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
CCHyper
Defense Minister


Joined: 07 Apr 2005

PostPosted: Thu Apr 19, 2018 3:01 pm    Post subject: Reply with quote  Mark this post and the followings unread

Tomsons has updated his post with updates regarding the Low and High colours, what actually are for the when the tile is on the lowest cell height and highest cell height. The game then generates the remaining 10 levels from these two.

In addition to that, after spending some time looking into the IsoTile loading code it seems that by default, each tile is assigned sequence value of 1, but if there is a sequence of tiles in a set (think of clear##[a-x].tem) then they are stored in a linked list and bit 3 of the tile options controls if it randomises. So the name of "HasDamagedData" is actualy a bit that controls if it should randomise the tile data, but the logic behind this is unclear at the moment, i would need more time to look into it.

Back to top
View user's profile Send private message
E1 Elite
General


Joined: 28 May 2013

PostPosted: Thu Apr 19, 2018 6:00 pm    Post subject: Reply with quote  Mark this post and the followings unread

CCHyper wrote:
Tomsons has updated his post with updates regarding the Low and High colours, what actually are for the when the tile is on the lowest cell height and highest cell height. The game then generates the remaining 10 levels from these two.

Are you sure that is correct. Height can go more than just 2 + 10 = 12. Though graphics glitches starts forming after height 12. But both in-game color and radar color work with height 13 and 14. Game might have certain brightness value (consider map [Lighting] section also) to multiply depending on height for both in-game and radar. Don't test in YR as its radar doesn't show contrast variation as in TS.

Calling it as lowest height and highest height also is misleading. If you look at clear*.tem tileset, those have almost same values. Some high value is even lower than low values. And in TS you can see good amount of brightness variation both in-game and in radar depending on height with clear tiles.

Back to top
View user's profile Send private message
E1 Elite
General


Joined: 28 May 2013

PostPosted: Sat Apr 21, 2018 6:28 am    Post subject: Reply with quote  Mark this post and the followings unread

Created a test map with upto height 14 and also modified the 2 color values to be red and green in TS clear tiles.

Looks like calling it radar left and right edge colors would be more appropriate.



RadarColor.jpg
 Description:
Original - Modified red/green
 Filesize:  235.05 KB
 Viewed:  7596 Time(s)

RadarColor.jpg



Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Sat Apr 21, 2018 7:53 am    Post subject: Reply with quote  Mark this post and the followings unread

I don't get what i see there.
There is no green shown in the screenshot and just some red spots like a brutal jpg compression.

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
Crimsonum
Seth


Joined: 14 Jul 2005
Location: Fineland

PostPosted: Sat Apr 21, 2018 9:05 am    Post subject: Reply with quote  Mark this post and the followings unread

So if I understood correctly, the two values seem to define a gradient that the tile is represented with on the radar? Why not simply settle for one base colour...

Lin Kuei Ominae wrote:
I don't get what i see there.
There is no green shown in the screenshot and just some red spots like a brutal jpg compression.


Yes there is, the green is clearly visible next to the red pixels. Maybe you need to adjust your monitor's colour settings.

_________________


Last edited by Crimsonum on Sat Apr 21, 2018 9:22 am; edited 3 times in total

Back to top
View user's profile Send private message
E1 Elite
General


Joined: 28 May 2013

PostPosted: Sat Apr 21, 2018 9:08 am    Post subject: Reply with quote  Mark this post and the followings unread

The radar image was too small. Attaching the test map as well as the modified TS clear*.tem files. Ecache08 has red/green and ecache09 has red/black for the colors.



RadarColorSmall.png
 Description:
 Filesize:  90.43 KB
 Viewed:  7560 Time(s)

RadarColorSmall.png



TMPRadarTest.zip
 Description:

Download
 Filename:  TMPRadarTest.zip
 Filesize:  25.36 KB
 Downloaded:  4 Time(s)


Back to top
View user's profile Send private message
Nyerguds
General


Joined: 24 May 2004
Location: Flanders (Be) Posts:300000001

PostPosted: Fri Jul 27, 2018 6:52 am    Post subject: Reply with quote  Mark this post and the followings unread

CCHyper wrote:
How certain is the "HasDamagedArt" flag? From what I see, that flag has something to do with if the tile is randomized or not...
CCHyper wrote:
In addition to that, after spending some time looking into the IsoTile loading code it seems that by default, each tile is assigned sequence value of 1, but if there is a sequence of tiles in a set (think of clear##[a-x].tem) then they are stored in a linked list and bit 3 of the tile options controls if it randomises. So the name of "HasDamagedData" is actualy a bit that controls if it should randomise the tile data, but the logic behind this is unclear at the moment, i would need more time to look into it.

This is actually interesting, since RA1 tiles also have this kind of logic; a tileset in RA has a switch to change them from "a series of tiles that make up one tileset" to "a 1x1 tileset that can randomly take one of the included tiles".

It's used a lot in the Interior theater, and I think the game's default terrain also uses that logic.

_________________

Back to top
View user's profile Send private message Visit poster's website Skype Account
E1 Elite
General


Joined: 28 May 2013

PostPosted: Fri Jul 27, 2018 11:06 am    Post subject: Reply with quote  Mark this post and the followings unread

In RA1, the variations are stored in the same terrain file like arro0001.int or clear1.tem. In TS/RA2/YR, these are stored in different files like clear01.tem, clear01a.tem to clear01g.tem. When the HasDamagedData bit is set then the variations are not used for random placing but instead used in damage logic like ovrps01.tem is non-damaged bridge section tile whereas ovrps01a.tem is damaged tile for the same bridge section.

TileSet also takes a different meaning here. Terrain INI files like temperat.ini defines a set as a collection of tiles. Like water tiles start with filename as water where TilesInSet gives the number of tiles in the set making it water01.tem to water14.tem. Game logic is coded for this tileset given in WaterSet= with water behaviour like how a missile shot from a submarine should behave etc.

Map's IsoMapPack5 doesn't store info on the variant of the tile. When loading the map, game will look into the tile and decide to use a random variant if the HasDamagedData bit is not set. Whereas, a savegame stores the tile variant info as well.

Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 1 [33 Posts] Mark the topic unread ::  View previous topic :: View next topic
 
Share on TwitterShare on FacebookShare on Google+Share on DiggShare on RedditShare on PInterestShare on Del.icio.usShare on Stumble Upon
Quick Reply
Username:


If you are visually impaired or cannot otherwise answer the challenges below please contact the Administrator for help.


Write only two of the following words separated by a sharp: Brotherhood, unity, peace! 

 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © phpBB Group

[ Time: 0.2603s ][ Queries: 15 (0.0166s) ][ Debug on ]