Hello community,

I try to write a tool for editing a scenery of a game. But I fail when I try to interpret data from that file.

In fact, in a maximum of 11 Floats(probaly rather somewhere around 9 Floats) there have to be stored Texture Size X and Y, Texture rotation and Texture scalation X and Y for 3 Textures each.

Uncompressed, this would be 2*1*2*3 = 12 Floats, but this one is, like written above, not possible.

At first, I was expecting a sparse matrix, but I does not seems like this is the solution for that. Does anybody here have any idea how I can get the needed values?

Maybe it is helpful to know that the game itself was written in C++, using DirecX and D3D. As for me, I am using Pascal, so I case you feel like posting some code, please comment it basically.

When reverse engineering data files, it can be helpful to collect as much data you can, and plot or chart the data you have as unknowns, to figure out the data ranges and distributions of it, e.g. are the data unsigned perhaps, or normalized, or bounded by some other range?

Also, since the original game is able to load all the data, you might try mutating some of the existing data files and seeing how the game reacts to those changes when loading the data, which can help to give a clue what the data means for the game.

But how is it in that case possible, that I need to have more values than I have available?

Meantime, I found out that there are exact 10 Floats, but still I have to get 12 Values.

So it is left with 2 floats, but I can guarantee that there is no other place which the missing floats can be stored.

So are there any common methods of saving space by storing these values in a special format?

10 cannot be divided by 3, so given 3 textures, you can already see that the textures must necessarily share some state, or some really mean bit whacking must take place. Without knowing more details or experimenting for a long time, it's hard to guess which one it is, though.

For example, it could be that there is the requirement that all three textures are the same size. That would mean storing 2 floats instead of 6 for size. Same is possible for scale, too (or scale could simply be uniform).

Packing half-precision floats into normal floats and integers is possible and has been done. GLM has functions for that kind of thing, and if I remember correctly, Cg even had functions (and hardware support on Kepler) for that. OpenGL's ARB_shading_language_packing does that kind of thing, too.

Also, as long as you do not need to interpolate this "float", you could in principle type-pun any collection of arbitrarily-sized integers as a float, for example 6 bits each for the POT size of a texture, and 10 bits each for a scale. After all, to the hardware, it's just a pattern of 32 bits (to some extent).

If textures are required to be power-of-two sized (quite possibly?), there are at most 16 or so possible sizes, thus you could easily pack the texture size into one float and still have room to encode rotation. Even if NPOT textures are allowed, assuming they're at most 2048x4096, they will fit into a float's mantissa no problem, precise to the pixel (with some hefty bit whacking one could fit 16kx16k textures in there too, but that's nasty).

Similarly, scale needs not use the full range of a float, it could very be two half-precision floats. Or, something else, two 16-bit integers type-punned as float, for example.

Sorry, mistake by myself. You are right, there have to be 15 values

The file is a binary file where the Material settings are stored. Each record contains 60 bytes, where 16 are already in use (e.g. 3xTexture indices, Materialmode, and else). So it is left with 44 bytes. That makes a maximum of 11 Floats. Like said, in the meantime I recognized that there is one more Integer at the beginning, so the maximum of each Material is 10 Floats.
I already readed some other binary File types from that developer, they store e.g. their angels usually in 3x3 matrices, so I was expecting it will be something like that again.
The textures are all POT, although non-squares like 64x256 are also possible.
I also suspect that SizeX and SizeY are seperated because in the Materialsettings of other Files (which are readable like a *.obj MTL File) they seperate them, same as the MoveX,MoveY.

Anyhow, I attached an Excel file with some of the records, if somebody feels like having a look he's free ;)
Click here!

I hope I provided some more information you need.