Something has been bothering me about the notion of revising the renderer by starting with certain superficial bits like lens flares and 3D models. While this approach is feasible, there is a considerable amount of friction when trying to interface with the old rendering code. The old code makes certain assumptions and behaves in inefficent ways; it is difficult not to let the new GL2 rendering code be overly affected by these inoptimal traits.
Thoughts on animation
In the past, the way Doomsday has approached 3D model animation has been exceedingly simple. Since MD2 models are vertex-animated, with a full set of vertices per each frame, Doomsday has simply associated a model frame with each object state. When rendering, the model frame would be selected by looking up which one has been linked with the current state of the object. In other words, each 3D model frame was being treated like a 3D version of the original 2D sprite. Continue reading Thoughts on animation
Internal data for thinkers
My work has progressed to a point where it is becoming increasingly cumbersome that map objects remain POD C structs. While map data (sectors, lines, etc.) has long been refactored to be C++/PIMPL friendly for maximum flexibility, all variants of thinkers (including mobjs) remain inflexible and fully shared between the engine and the plugins. Continue reading Internal data for thinkers
Packaging practicalities
I’ve organized most of the various essential resources needed by Doomsday into a set of packages. This is an important step in verifying that the new package system is working as intended. Continue reading Packaging practicalities
Immaculate detail
Today I added support for OS X HiDPI resolutions. It turned out to be relatively straightforward, with Qt 5 already doing most of the work for us. Doomsday’s default UI style package was easy to adapt for HiDPI, with a couple of extra factors applied to UI metrics and font sizes. It helped that we had already prepared suitably high-resolution versions of the icons and other graphics used in the revised UI.
I’m very happy about how crisp everything looks on a retina display.
Packaging fundamentals
I have set up the basic building blocks for native packaging within Doomsday 2.
The guiding principles for this design are maximal utilization of existing functionality — FS2, Record and Doomsday Script — and keeping everything simple yet flexible. Continue reading Packaging fundamentals
Planning ahead
While working towards the next-gen 3D model renderer, I now have a more detailed step-by-step plan for moving forward. Continue reading Planning ahead
Schedule wrt. model rendering
I’ve had little mental bandwidth for Doomsday recently. This is not unexpected during the weeks leading up to the summer vacation. Looking at the calendar, there is still time until the end of July to wrap up any new code for 1.15. This should be enough for putting together a basic package loading mechanism and set up a simple model pacakge.
Progress with Doomsday Script
Doomsday Script (DS) is the Doomsday 2 scripting language, built right into the core of the engine. Its syntax is heavily Python-inspired, however with a somewhat smaller set of language features. Recently I’ve been improving DS with future needs in mind.
Xcode
Xcode is growing on me. Especially Xcode 6 on Yosemite is looking fantastic. Qt Creator is a very capable editor, however I plan to make another effort to write a generator script for a “native” Doomsday Xcode project. A sensible goal would be to produce a Snowberry-free build using Qt 5.3.