Whorld V2 Roadmap

The alpha version of V2 is done, and being tested. As with FFRend, rendering runs entirely in its own worker thread. The renderer doesn’t even have a Windows message loop, so it cannot be blocked by the UI. The UI can only communicate with the renderer via a thread-safe command queue. The renderer doesn’t have a timer either, and that’s why there’s no frame rate setting. Instead the renderer runs at the monitor’s display frequency, via a DXGI swap chain, just as game developers do. Whorld has essentially been restructured into a modern Windows game.

Whorld V2 now renders entirely via Direct2D, which is fully hardware-accelerated. Direct2D is a wrapper around Direct3D, so we’re running Direct3D under the hood. Tessellation is on the CPU, possibly on multiple cores, but drawing is on the GPU. But I digress. Here’s a quick roadmap for what lies ahead:

1. MIDI mapping. This will be a complete do-over. I plan to follow the same paradigm used in my Polymeter app. The advantage of that paradigm is flexibility. A control can map to multiple targets, a target can map to multiple controls, all bases are covered. I expect MIDI mapping to be a long-ish ride because V2 is multithreaded, which adds spice. With the MIDI revamp will come a new Options dialog, based on standard property sheets, again borrowed from the Polymeter project. Various other features are also waiting on an options dialog.

2. Mirroring. I had a long chat with GPT about this last night. For programming projects, I talk to version o1; slow but comprehensive. It was a bit vague at first, but I busted its imaginary balls a bit, and it coughed up some solid-looking Direct2D code for mirroring. The method is quite complex and may affect performance, but it’s definitely worth a try. The core problem is that there’s no way to copy a rectangle within the back buffer anymore. That went away with DirectDraw and the move to GPUs. In D2D a buffer can be a source or a destination, but never both. So instead, we must use command lists, which are an advanced feature of D3D. I expect some R&D and a fairly steep learning curve.

3. Playlists. While we’re redoing the MIDI mapping, we should reconsider the Playlist file format, which is how OG Whorld stored its MIDI settings. That file format is a mess and needs a rethink.

4. Image export. Exporting a PNG will be fairly easy. The tricky part is learning to use WIC, but GPT will help with that. In fact I already have a basic export working as of today, only the UI remains to be done.

5. Snapshots A snapshots is Whorld's vector format. It captures the entire ring stack, along with all related state information, in a highly compact form that’s losslessly scalable because no pixels are involved. In the original version, snapshot format depends heavily on Whorld’s internal structure, which makes the format somewhat fragile. Perhaps we can do better this time. I have considerable personal motivation to work on snapshots, because I have a large and beloved collection of snapshots, some of which have potential as art, and they will definitely look vastly better with antialiasing.

6. TRANSPARENCY. It’s got the word “trans” in it, so we gotta go for it. It will hurt performance, but it’ll look so cool it’ll be worth doing a low ring count. Transparency will definitely work in fill mode, and that will be the most awesome use of it, because you will partially see through the “cone” revealing structure that was previously hidden. I envision two types: One where we change the alpha of the entire ring list, and another where the rings gradually get more transparent as they migrate further from the center. Both have potential.

After that, I’m not sure. XOR is vaguely possible, but it would be hard. D2D supports other blending modes, just not that one. But there is the option to create a so-called “effect” which is a type of custom blending mode. It means writing shader code. With GPT’s help, I can probably manage it, but not soon.