Hello all, I've created a small plug-in that exports the geometry in Tomb Raider .SAT files into Blender. The documentation was provided by b122251 I have found the function that processes the rest of the .SAT, .SPR, and .SAD files. If anyone is interested, let me know. This would allow exporting textures and lighting into Blender. The Saturn format is vastly different from the PlayStation's .PHD format. GitHub: https://github.com/ijacquez/trsat
Nice! The room meshes will be pretty much the same or close to PC/PSX versions which have been extractable for years. The Saturn version of Tomb Raider uses a chunk based file format which is easier to load compared to PC/PSX. The textures are also much lower resolution which is a shame. Vertex lighting is packed on both PSX/Saturn versions of Tomb Raider.
Interesting, thanks for the tidbit. I was curious about why there was hardly any info on the Saturn version, but luckily someone had disassembled the geometry part of the file format. Even if the textures and lighting can be extracted from the PC/PS1 versions, it would be great to have the Saturn version documented as well. Sadly, I don't have all that much time to convert the functions I've found from assembly to C.
Very nice! I'd be interested to see if this would work with the other Core games (Blam! Machinehead, Shellshock, Fighting Force etc). Not sure if they use the same geometry.
That would be ideal. Creating different levels would be great. I'm going to provide with a list of functions in a document so someone who has more time than me can go through the disassembly of that function. This would allow us to write tools to parse the .SAT, .SPR, and .SAD files.
Here is a list of functions inside the main binary (0MAIN.BIN) 0x060347A8 - Parses .SAT/.SPR files 0x06033C90 - Loads actual file "data\level3a.sat" before parsing 0x060478A0 - String compare 0x060436E8 - Prints to console 0x06043A18 - Possibly loads files from CD 0x06043A70 - Possibly loads files from CD 0x0602C5AC - HUGE function
Since you have Tomb Raider, can you check to see if they are using both CPUs, or the SCU DSP for matrix transformations? (Yabause debugger) unless these are already known factors... Wondering if games could be upgraded to use the 2nd CPU (maybe just to handle interrupts), or to set the SCU to do matrix transforms to offload the CPU some. If so, maybe more complex geometry could be loaded, or Goraud shading added in for better graphics. Enabling RAM expansion so better textures can be used would be a nice bonus too. Would require a lot of assembly code injections if possible. I've been reading a lot of the Saturn documentation and SH2 assembler manual so I can try to work on resolution hacks (like 320 Horizontal to 352 like @paul_met has been doing). So the above ideas are way over my head right now.
It didn't use the SCU DSP AFAIK. I've read somewhere that the devs, while doing Tomb Raider 2 on Saturn, realised that they could have pushed the hardware much further if Sega had told them more about the hardware (there was very little support for devs). They probably used the slave CPU, but likely not fully. For the textures, it's probably not a RAM issue : the vdp1 fillrate is just slower than on PS1, so using low quality textures helps a lot. But, by using PVS, you can reduce the amount of pixels rewritten over many times (because of the painter's algorythm), which should help a lot (like Lobotomy games all using 64x64 textures). As for gouraud shading, Tomb Raider does it already.
Making use of the SCU DSP will do very little if the master CPU is spinning until it's done with the calculations. In order to squeeze more performance, the CPU would have to be doing something else while the SCU DSP is churning resultant matrices. All this would mean that you'd effectively have to rewrite the engine. Enabling RAM expansion would be possible. As @XL2 had mentioned, you're limited by the fill-rate of the VDP1, so better textures wouldn't help. You're more than welcome to help reverse engineer the rest of the .SAT/.SPR/.SAD formats! I do like your ideas and of course, I would love to be proven wrong.
That's way beyond me. Here's another idea though. If the RAM expansion can be enabled, it may be possible to create a save state system for easy do-overs in games that only have save points, or to avoid un-skippable videos when retrying a boss fight, etc.
Yes, rewriting another engine would be the best bet, if someone is really motivated. My engine is quite flexible with maps from other games (but still far from perfect), I will update the FPS demo within the next few weeks/months so that others can play with it and start their own game. Here is an example of Saturn Quake maps in Sonic Z-Treme (just for the lol factor) : The same could be done with Tomb Raider maps using this blender tool and my map converter.
Saturn Quake maps? No, they use the Slavedriver format (.LEV) and I used Noesis to convert them to .obj, then used my map tool to convert them to my format. I use my own work-in-progress .ZTM format.
Even though I am not much fan of sega saturn, anyway I have a passion for reverse engineering old games, and this seems absolutely FANTASTIC. GOOD JOB GUYS!!!
