Lighting system
1 de enero de 2019 | 
Autor: First of all, I wanted to wish a happy new year to all the Death Rally fans.
To start the year, I have a good news: the lighting system of the game has been fully implemented, with some bugs that can be corrected in the future, but we must bear in mind that the format of the files has been deciphered.
The lighting system is defined by the TRX_SHA.bpk file of each circuit. This file is composed of three-dimensional points (the z-coordinate is not used, but it seems that there was a forecast to use it according to the source code), and by triangles that are defined by these points.
Then externally a mask is applied to the colors (they are 8 bits) that the only thing that does is add to those 8 bits the value of the mask.
There are two masks: the file VARJO.bpk, which is used for shadows, and the file TRX_LIT.bpk, which is used to illuminate the headlights of the car (depending on the circuit the headlights can illuminate differently). As an anecdote, the light of the headlights of the car, although it may seem a lie, is defined by three triangles!
Then I leave in format table the shadow file format:
| Offset (byte) | Size (bytes) | Information
|0 |4 |number of points
|4 |4 |number of shawdows
|8 |4 *number of points | x coordenate
|12+(4*number of points) |4*number of points | y coordedate
|12+ (8*number of points) |4*number of points | z coor. (zero values, not used)
|12+ (12*number of points) |4*number of shadows | index to search x, y coor of the first point of the shadow
|12+ (12*number of points) +(4*number of shadows) |4*number of shadows | index to search x, y coor of the second point of the shadow
|12+ (12*number of points) +(4*number of shadows) |4**number of shadows | index to search x, y coor of the third point of the shadow
And finally I leave the video where you can see how the shadows look in Dreerally.
The next step is to decipher the specific textures of the circuits.
Greetings to all.
Publicado en General
Hi Enrique!
I wish you a happy 2019!
Awesome work! As you know, I’m also trying to understand circuit files for my editor, and I’m thinking of a similar format (I did a try: modify some in memory byte values from circuit files during race, all fine and suddenly game blocked). So, given other discovered formats and given your newly discovered shadow format, I think that a file format for texture and 3D Track Object similar or equal to shadow system would be a quite good guess! (Maybe, I hope so 😀 ) For example, varjo equivalent mask for tracks could be first part of SCE track file(s), with other mask and we hope finally all track texture in second and/or third part of SCE file!
hi simone,
problably you are right, the textures must have a palette file (not a mask) with a size of 256bytes wich is used to colorize the textures.
i hope in this two weeks i will have more information about sce files (the most complicated), and i would like to release a prealpha version in the future in wich the the bpa files can be overriden with another files decrypted and decompressed.
Hi,
It seems, that the sce file have 5 sections:
– The number of 3d Objects.
– One structure that contains this structures with size 3152 bytes
– The number of textures
– One structure that contains this structures with size 44 bytes
– The circuits TR2 and TR9 have and extra section. It appears to be a raw data (probably the images).
In the next days I want to write the definition of this files in the wiki of the project (https://github.com/enriquesomolinos/DreeRally/wiki). A this moment I think that of the files are fully understable except tracks SCE files and OHI files.
Yes, in fact by «first part» I mean
«– The number of 3d Objects.
– One structure that contains this structures with size 3152 bytes
»
by «second part»
«– The number of textures
– One structure that contains this structures with size 44 bytes
»
and by «third part» the rest of the (raw) data, always 524288 bytes (so exactly 512KB) partially used.
To sum up, I remember the table that I wrote and shared some months ago about the number of 3D Objects and textures in SCE files and about SHA files.
https://github.com/enriquesomolinos/DreeRally/issues/18#issuecomment-379541305
Some considerations (maybe some right, some wrong) :
I’ve always thought that 3152 byte single block(s) part of data was for the textures, because, maybe, 44 bytes are too few for an image, unless an image of few pixels (like 10×10 or less). Maybe this first parts are also headers/pointers to raw data part? This consideration may be quite right, because images have different dimensions.