Could this project (or the knowledge gained from it) be used to add high resolution rendering for SuperFX to emulators?

[DerKoun]

Hello, I'm the developer of bsnes-hd (currently on break). I've had users ask for high resolution rendering of SuperFX games. Now I found this project and wonder if you'd be willing to share the knowledge you used for or gained from this project. Primarily I wonder what data exactly is stored in the game, e.g. is it just 2D points and fill colors or is there actual depth, how is the way from the models to the rasterization, and so on.?. Maybe a high resolution render, maybe even with further improvements, is really possible (I thought is was not, at least not without many hacky workarounds). Note: I'm not that good at C++ and know very little about 3D programming. This is mostly to look into possibilities and collect knowledge for some new concepts. Thanks in advance for any help

[Hordeking]

The vertices are all ordered triples (x,y,z), so yes, they also contain the depth information you're after. They're not flat sprites. Each object has basically two components:

1. A vertex list, which may or may not be animated. The vertices for animated ones are stored per frame.
2. The polygon list, which contains a number of things: the triangle list, BSP tree for culling, and the actual polygon list. The polygon list defines the colors or textures based on the palette in use. I understand the format of this list, but the texture stuff was where I bogged down.

So if you export the models, and load them up in blender for instance, the mesh itself will be zoomable and animable with as much resolution as you like.

One thing to keep in mind about SuperFX games: Almost everything is actually done on the SuperFX MARIO chip on the cartridge. The SNES itself really is just providing a place to dump its vram to get it on the screen and take input from the player. When you play a SuperFX game, you're really playing on a different machine that's piggybacking on the SNES. So if you plan on doing your own rendering, you'll have to understand what the MARIO chip is doing behind the scenes.

If you want to see an example in action, I am attaching an annotated dump of the helicopter object. It has most things one would expect in an object: regular points, x-mirrored points, animation frames, etc. What is doesn't have: image textures, though it does use colors from the particular palette 8213 which is used in most of the game.

Of course, if you mean by "high resolution" that the curves are smoothed and so on, no this program doesn't do that. It outputs the model fairly faithfully to the original model. If you want to do things with normals and smoothing, you have to do that yourself. Fortunately, these models are fairly simple, and I've gotten some very nice results with blender.

[Hordeking]

Here's a high-def render of one of the bosses, as an example. This one didn't have any materials attached.

[Hordeking]

Helicopter.txt

[SpyderTL]

The 3d model format is documented pretty well over at http://datacrystal.romhacking.net/wiki/Star_Fox, although most of this information was put together before the giga-leak, so I'm going through all of my notes and utilities and updating them as we speak. Creating a stand-alone engine that can render these models and play through the levels is a project that I've been working on for years, but now that the source has been leaked, things should go much quicker.

[Hordeking]

No kidding. I cooked this program up about two years ago based on a lot of poking. It incorporates some things that Datacrystal doesn't mention, in particular regarding the BSP trees.

Also, the Magic Door Object, while not used in-game, has a minor problem that it has 20 vertices or triangles or frames (or something), and in the data, it has "20", but that's in hex, and it should be 0x14 (whoever created it used hex 20 when they should have used decimal 20).

The gigaleaks thing was pretty kickass. I've already built the rom from source with it :) The gigaleaks dump is missing a file, btw: the andorf game over screen (the part that fades in and says game over)

[Hordeking]

In case you were wondering, the main part of the program can actually be built as a library. It's really a driver/backend pair, where main.cpp is the frontend/driver. You could easily use the data structures presented by the backend in your code.

BTW, if you figure out the model/object addresses of other superfx games, please let me know what they are? I'd like to test this code with Vortex and Stunt Race FX

[SpyderTL]

I was actually looking for that file yesterday, as I'm extracting the tile sets and tile maps and building images from those. If you can figure out where the files near that file in the ROM are located, you could just extract the bytes and create the file yourself. Once I get all of the other files extracted, I may do that myself.

Actually, I forgot that Everything8215 just release his decrunch utility, which contains a text file that has the addresses for all of these tile/map files. Although only the tileset file is listed for this image. I'll try to find the address for the tilemap file in the rom based on the include files.

[Hordeking]

Oh, I already did it. I pulled the data itself from the commercial rom. and.pcr.gz

[DerKoun]

So, in theory, using the models in a modified emulator to render them in high resolution (just less pixelated and anti-aliased) on-the-fly would now mostly depend on knowing how to hook into the renderer to know at what 3D position and rotation to display the models. I always assumed that would require emulator-specific ROM-hacks, but as you know much more about the system, maybe you can help out there. If this is using high-level SuperFX functionality things would be relatively easy. If it's all in the game code, using only generic instructions, until it is written to the frame-buffer, I guess it would have to come down do ROM-hacks that interface with the emulator. Thanks a lot for helping out with your knowledge, much appreciated.

SpyderTL: Looking forward to see the engine. I assume you are reimplementing the gameplay. So it's a different approach than an emulator with a modified renderer. Still, I hope pooling research will benefit all projects.

What I have personally looked into, mostly theoretically, is reconstructing the vertexes from the pixels drawn into the buffer, which is pretty much a last resort. Then I randomly found this project, and now I hope we can do better than that.

[Hordeking]

Thanks for the vote of confidence, but in this one, I stand on the shoulders of giants.

Normally I would say that you're probably going to wind up doing a lot more work than you expect, but then again, you really made the mode 7 stuff look good. In this case, it'll probably be similar to what HLE emulators do, but with the Superfx chip. Essentially you're proposing exactly that. I suspect you can do it! Let me know when you have some video of your work. I know a Hi-Def starfox has been something people have wanted for a long time. One thing: Star Fox essentially operates at 14 FPS. Hooking the renderer might not be too hard, but getting the timing right AND increasing the framerate might be harder. And the game does things like distance lighting, and directional lighting (pre-calculated), so you either have to deal with that or settle on the "standard 0° incidence" shade, and then apply your own shading.

[DerKoun]

I'm only looking into the concepts. I don't have the skills to implement this alone. Also I have many other bsnes-hd todos first. But I hope someone will pick these ideas up. I hope the communications stay open so people looking into this can tap into the existing knowledge, code and ideas. Until then I'll keep an eye on the work of both of you.