Dissecting the Stunts files, trying to. Anyone know more?

[dstien]

dstien will find specially amusing the fact it is written in Fortran...

Hehe, I do find your choice of languages -- Fortran and R -- a little, um, esoteric.

And before I forget, nice find about the helmet, when we find what escape code produces the circular taillights it will be a neat addition.

Actually, there's no magic about the GTO's "round" taillights, they're just 6-sided polygons:

Those corrections mean that now we only have the mysterious "UNKNOWN" middle section to understand. Actually, I did some brute force tests while writing the parser (e.g. blanking the whole thing), and it seems that the "UNKNOWN" section has actually two parts, one with five-byte blocks and the other with three-byte blocks. The first part might have some relation with angles of visualization - for instance, wheels have "ff ff ff ff ff" sequences, and blanking some (don't remember which) values will make them disappear, while arbitrary changes might make them go on and off as the car0 structure rotates in the selection screen. As for the second part, still no clue on what it stores.

The first part does indeed appear to store values related to detail culling. I think the first list is 4 bytes per polygon, maybe max-distances? I'll have to dig deeper into this...

Now, on where we go from now... first thing I wish to do is to print better polygon maps, so it is feasible freely colorize a car. Also, I wonder about editors. One of the motivations behind the creation of the ASCII parser was to use it as an intermediate tool for feasible edition. I can think of two routes:

• Decompose the .3SH in tables of vertexes, colours, polygons and whatever else is needed, modify the intermediate as wished and re-package everything on a new .3SH with another program. That could be useful, for instance, in providing a comfortable way to tune colours without having to worry all the time about offsets - but more important would be the role of such process in the other treatment...
• ...namely, use a new parser to convert the essentials (vertex and polygons at least) data in a format that can be read by an actual 3D editor, then use another program to rebuild the .3SH. While that may sound unfeasible at first, there's a damn simple and common 3D shape format that uses tables very similar to what we already have to code polygonal shapes: the .OBJ format.

For the moment, though, I'm merely speculating. Surely dstein knows a lot more about 3D shape edition than me (for I would have found nothing without his guidance), and is a more experienced programmer as well (he doesn't have to write his parsers in Fortran  ), so he can have a more proper opinion in that respect.

I plan on making a resource editor with low-level editing and import/export of 3d mesh data...

[Paleke]

WOW! So much information so much above my understanding 

Anyway, good work!!! 

[Duplode]

dstien will find specially amusing the fact it is written in Fortran...

Hehe, I do find your choice of languages -- Fortran and R -- a little, um, esoteric.

  That's due to my impromptu learning of programming due to academic needs (numerical calculus-intensive applications) while ago. Now I'm finally in the process of leaning some Java, but still a newbie nonetheless 

I plan on making a resource editor with low-level editing and import/export of 3d mesh data...

That would be magnificent... you may be sure beta testers won't be lacking!

BTW, before I forget, dstein: are you reading the colour data while generating that shape pics for the file from somewhere?

Now another teaser for you guys:
Krys mentioned creating new shapes for old custom cars. There is one, however, that we may not need to touch: there's nothing wrong with the Melange shape. Or, didn't you ever wondered why the Acura never really looked like an NSX?





Since this one is ready-to-go already, I attached the .3SH. Enjoy!

[Krys TOFF]

Look at this video : in Tandy graphic mode the indy can be white.
The Skid Vicious car seen twice (at around 30 seconds and also around 2 minutes and 30 seconds) in this video is definitively white !

Is it a color not available in Tandy mode that is transformed into white, or is it that this guy modified the color of the cars (so it means he dissected the files too) ?

[Duplode]

Krys: The differences are most likely because palette definitions are encoded in the "device-specific" graphics files (TANDY.COD, TANDY.DIF or TANDY.HDR for instance). The colour indices we modify in the *.3SH are pointers to someplace in those files. Since Tandy and other graphical systems have a smaller range of colours available than MCGA, the pallet must be simplified accordingly. A quick run with pseudo-Tandy in DOSBox shows the colours of the cars are mostly the same, except the shadings are far less rich; and thus what we think of as a shiny silver Indy looks white under Tandy. Anyway, if we could understand and edit the hard-coded palettes, maybe it would be possible to pick unused values and add custom shades... that's far beyond my comprehension, however 

BTW, that does not mean we can't have good looking (or at least as good looking as the Tandy one) white cars:



This is an American Blue Corvette. One day it will evolve into the full-fledged design of white with Viper-like blue stripes all through the roof ...

[Krys TOFF]

I like bi-color Stunts shapes.
Anyway, what was the interest of the file you attached in your message just before the last one ? It's just the Acura shape uncompressed ?

[Duplode]

It is, but with the roof painted in the body colour instead of glassy black, as it always should have been. Look at the pics above it...

[Krys TOFF]

Oh, I didn't pay attention. Thanks, I'll download this one.
I've got to create a new Stunts directory with all car shapes tests that will come, or I will have problems with my replays in competition if I keep it all in my regular Stunts directory.

[dstien]

I've started working on a simple Stunts resource editor; stressed. Only plain text resources are supported right now, so MISC.PRE is probably the only file it can load. Compressed files are supported by re-using stunpack (as intended), but remember to change the file name (=> MISC.RES) when saving as encoding is not supported.

you may be sure beta testers won't be lacking!

The code is available in a public repository. Google Code project hosting doesn't offer XML feeds of commits, but I'll post a message here when/if I add something exciting. In order to build it you'll need a SVN client and the QT4 dev package.

Code: [Select]

svn co http://stuntstools.googlecode.com/svn/trunk/stressed/ stressed
cd stressed
qmake stressed.pro
make
src/stressed /path/to/MISC.PRE

I've only tested it under x86_64 Linux, altought that shouldn't really matter. It'll hopefully compile for Windows/Mac etc. as well using the GNU toolchain.

BTW, before I forget, dstein: are you reading the colour data while generating that shape pics for the file from somewhere?

The "colors" are in fact materials that can have simple textures. Locating and reversing this data structure would take longer than just making the list by hand. I took in-game screenshots and identified the color values...

[dstien]

Added support for loading, displaying and writing bitmap resources. Only the unknown header values are editable at the moment, but stressed can now open all PSV files. Here's the VGA palette used.

[Krys TOFF]

WOW ! Nice tool. You're really good dstein, thanks for your work.

[dstien]

Just added bitmap import/export. When will we see the first custom dashboard?

[Duplode]

OMG, what I'm doing right now under Windows?! I must setup SVN and try that stuff!! 

[zaqrack]

wow, awesome!

I remember I have translated the opponent description/winning/losing texts to Hungarian by hex editing 10 years ago, but this tool is way too cool. and I love the name.

[Krys TOFF]

Just added bitmap import/export. When will we see the first custom dashboard?

Is it you on the picture ?