Ferrum development journal · Part 2 of 19
From Return Values to Pixels and Sound
A window, a sound, and a changing image answer different questions. This phase started connecting translated Windows code to results a person can actually see and hear.
Once an executable can run, the next question is pretty straightforward: can it do anything useful outside the terminal? For a game or a desktop application, that means windows, drawing, input, and sound. Those are separate connections, and getting one working doesn't automatically bring the others along.
The August work started joining those pieces. A translated guest produced sound, the Mac surface gained a way to accept an image from the graphics path, and the rendering checks moved toward verifying the pixels the guest had actually drawn. That last part matters more than a successful device-creation call. An application can create a graphics device and still leave you looking at a blank window.
For example, if a test draws a known color, we can read the result back and compare it with what the program requested. Then we can ask a different question: did that image reach the window? The renderer and the presentation layer can each be doing something reasonable while the connection between them is wrong.
This phase also exposed instruction and API gaps that tiny command-line programs hadn't reached. More realistic graphics code exercised vector instructions, DLL initialization, memory, and synchronization in combinations the earlier tests never used. That is one reason I don't treat the number of implemented functions as a compatibility score. What matters is whether the application can use them together.
The sound and pixel milestones were encouraging because they made the work less abstract. There was something to observe. They were still targeted development results, though. They didn't establish sustained game audio, a long interactive session, or support for every DirectX feature.
The practical lesson was to keep asking for the result at the far end of a feature. If we're working on drawing, let's inspect what was drawn. If we're working on presentation, let's make sure the window changes. A return value is useful evidence, but the thing the viewer sees needs its own check.
Ferrum development journal
View the journalLive19 entries so far·Updated New (19 entries updated in the last 14 days)
- Part 1Bringing FEX to macOS: The First Windows Program
- Part 2From Return Values to Pixels and Sound
- Part 3Building More of the Windows Runtime
- Part 4Following a Game Through Its Opening Video
- Part 5Installers, Saves, Fonts, and the Parts Around the Game
- Part 6Game Progress and Measuring the Right Thing
- Part 7Building the 32-Bit Graphics Path
- Part 8Making Memory, Files, and Graphics State Agree
- Part 9DirectX 12, Shader Caches, and the Steam Startup Work
- Part 10Working on Presentation and Controller Input
- Part 11A Launcher and a Freeze That Wasn't the Presenter
- Part 12Portal Reaches a Command Stream, With the Frame Still Ahead
- Part 13Correcting the Ferrum Progress Report
- Part 14Recovering the Project and Resuming Real Tests
- Part 15Making Memory Protection and Lifetime Tests More Useful
- Part 16Getting Wine's Real 32-Bit Startup to Run
- Part 17Making the Launcher Own Its Storage and Processes
- Part 18A Real Archive Roundtrip and Better File Behavior
- Part 19Asynchronous I/O and the Bytes a Cancelled Write Keeps