A stand-in for PowerVR's SGL

2026-10-24, afternoon.

POD Gold has a build for each 3D card of 1997. The 3dfx, ATI and S3 builds already run through our own card libraries (wrapper/). The PowerVR build, WPODPVR.EXE, was left for a session of its own, because its card library is different in kind.

SGL is a scene graph

The other cards take triangles. PowerVR's first chips (PCX1 and PCX2) were driven through VideoLogic's SGL. The game builds display lists of transforms, materials, meshes, lights and cameras once per race. Each frame it moves a few transforms, switches lists on and off and calls sgl_render. The build imports 46 SGL calls.

The headers were already ours. Gold's disc carries the PowerVR driver package (POWERVR/310C3.ZIP, March 1997) with sgl.h and sglwin32.h in it. Every signature, error code and structure came from there, so nothing had to be downloaded. The game's own code then showed how it uses each call (docs/hardware/3d-cards.md, "The PowerVR build"). The track is one small list per face. Each list holds a mesh of four vertices and two triangles, with its material set right after the mesh is made. Two cameras sit under named transforms, one per player. Fog and the background colour belong to the camera.

Two surprises in the game's code

A division by an ini file. Before its first SGL call the game reads two "region sizes" from sglhw.ini and later divides its resolution by them. Without the file both are 0. The driver's installer wrote the file (MIDAS.INF gives 32 × 32), so the stand-in writes it too when it is missing.

The address callback. The chip rendered into memory that the game names through a callback. That callback also finishes the frame before: it draws the dashboard over the last render, shows the picture and locks the next back buffer. So our library calls it at the first render of a frame and fills the viewport in that memory with a marker colour. It then draws the scene with OpenGL at the output size. When the game shows its picture, our DirectDraw passes it on, and every pixel that is not the marker goes over the 3D frame.

How far it got

The library builds and exports all 46 names. The scene graph has tests on the host. A small Windows program draws a known scene through it under Wine, shown at the top: projection, lighting, a texture made the way POD makes them, fog and a 2D bar over the marker.

The game itself starts through the stand-in on a Mac. It registers its callback, makes its textures and shows its main menu through our renderer:

Without a sound device under Wine the game first asks about the sound driver; "Ignore" carries on:

Then, at the second drawing of the menu, the game thread faults inside wow64cpu, Wine's switch between 32-bit and 64-bit code. It is not our library: the ATI build with our DirectDraw faults at the same address, and turning off the OpenGL path, the sound, the port I/O handler, or switching to Wine Staging changes nothing. GameFrame already knows this fault as an open problem on Apple silicon (wine-wow64-rosetta-fault). So the race goes to the emulated PC, where the 3dfx, ATI and S3 builds already race. run/vm/wrapper-gold.sh start WPODPVR.EXE 2 starts it there.

What is still a guess

SGL's projection from the camera rectangle, its fog formula, its default material and how a light volume adds light are inferred from the headers and the game's arguments. The one light volume POD makes (a cone, probably a headlight beam) is not drawn yet. Each guess is marked Deviation: in the code until a picture of a race settles it.