Supermodel Forum

Is discussion of real hardware allowed here?

I have an Ocean Hunter DX cabinet. The person I bought it from had thrown away the original 50" rear projection monitor and replaced it with a widescreen LCD. The problem of course is the game is 4:3 and your choices are either to have the picture stretched or run it in a box with borders on both sides. Neither option I find visually pleasing.

I just tried Ocean Hunter with Supermodel set to widescreen. It looks really good. I have no idea many overlapping hacks it's using, but I'm keen to find out how far you can get with original hardware. How would I find out where the FOV data is stored in the program roms?

I'm fully expecting that there will be issues with aiming after this change, but one problem at a time Worse performance because of additional rendering and stretched 2D art are things I do not mind.

Cheers

Given the low resolution of the Model 3 (496x384), increasing the FOV would probably make some of the finer details in scenes and texture maps less visible. The view frustum parameters are set in each viewport node in the scene graph, and there can be several viewports, not all of which have the same FOV. For example, some viewports on the screen are used to render UX stuff or little picture-in-picture windows and may have different settings.

Your starting point would be Src/Graphics/New3D/New3D.cpp line 841. Here you'll find the code that parses the frustum data out of the viewport node in Real3D culling RAM. Culling RAM in turn gets written by DMA transfers. You could probably identify the CPU instruction that triggered the DMA transfer to the viewport address (the function CNew3D::RenderViewport() is passed the culling RAM address). Once you know where they are in PowerPC memory, you can begin to work backwards through a disassembly of the game and figure out where they are set up. You could then conceivably patch the game to modify the viewport parameters in PowerPC RAM (unless they are copied from some ROM location directly, in which case you could apply a patch that way). Unfortunately, the number of viewport nodes and their location in PowerPC RAM will probably change throughout the game, so you have to be really careful.

One thing you might be able to do is find a good location to insert a hook that walks the scene graph in PowerPC memory just before it is DMA copied to the Real3D. For example, if you determine that the DMA copy is about to write viewport data, you can then walk the viewports (they are arranged in a linked list) and modify the frustum parameters of each one. Then return to the DMA routine, which will copy the data with your modifications. This will require being able to write assembly code. I patched VF3 to run my own tests and the code for that is here: https://github.com/trzy/model3/blob/master/experiments/vf3/. You can see that each experiment consists of a single assembly file, a linker script, and then a Makefile that employs a patch tool (which is also in the model3/ project somewhere) to apply the results to the ROMs at a specific location I identified.

Great info, thanks! I'll see if I can get anywhere with this.