Developer – Page 7 – Doomsday Blog

Pi the Successor

Upon hearing the news about Raspberry Pi 2, I was immediately interested: a quad-core processor? That could run four Doomsday multiplayer servers without breaking a sweat! I jumped into the web browser to place a preorder without hesitation.

I then remembered my trusty Raspberry Pi model B, which has been lying around unused of late. Perhaps I could employ it as an autobuilder client, to replace my old Mac Mini? Compared to a disk-spinning, fan-blowing Mac Mini, a completely quiet and tiny Raspberry Pi seems much better. Nowadays the Mac Mini has only been running nightly API documentation updates and other documentation generation tasks, so the relatively slow Raspberry Pi CPU shouldn’t be a problem.

Continue reading Pi the Successor

Slow VM OpenGL performance

I sometimes do development work in a Linux virtual machine on my MacBook Pro. At some point in the past, OpenGL performance in this environment was at near-native levels. Recently, though, it seems performance has been bogged down significantly. Continue reading Slow VM OpenGL performance

Release notes

DaniJ agreed to continue looking into the Hexen save issue since he has more recently been working on that area of the code. This frees me up to work on secondary tasks, like writing the release notes. Continue reading Release notes

Hexen save woes

I’ve started investigating what could be wrong with Hexen savegames regarding the state of ACS scripts. Right now I’m feeling quite overwhelmed — this code is complicated, even convoluted. Particularly the ACS state is broken down into multiple parts: world state, map state, individual script states as thinkers, and deferred script run requests. Each part is saved and loaded separately.

Due to all the complexity, I’m not surprised we are having malfunctions. Continue reading Hexen save woes

Xcode trouble

Here’s one for future reference. I’ve been working with Xcode on and off recently, but today all of a sudden, Xcode decided that it couldn’t find any of the dependencies between the project’s apps and libraries. That is, when building Doomsday.app, it wouldn’t build any of the supporting libraries first which, of course, led to a failed build.

Continue reading Xcode trouble

Up to Speed

I’ve been getting back to work on Doomsday after my 1.5 month hiatus.

As I previously planned, I’ve been doing more development on Xcode 6. It took a brief adjustment period to get to know the intricacies of the IDE, but Xcode is starting to feel quite comfortable. My biggest gripe is that the Quick Open box is so slow; Doomsday is a relatively large code base, so there are a lot of files and symbols to find (Qt Creator manages this just fine, though). There are some nice touches like the Assistant editor showing callers/callees, source/header counterparts, and other helpful information, but code navigation on the whole just doesn’t feel right to me. However, Xcode is superb for debugging on the Mac. I’ve already managed to fix a number of bugs thanks to it. Continue reading Up to Speed

Breather

I’ve been taking a break from Doomsday for the past two weeks, partly because I didn’t take a real break during the summer this year and partly because I haven’t had very much spare time recently.

It has been nice to think about some other things for a while, for instance taking a closer look at the C++11 standard and playing around with the more advanced features. With Doomsday there is a lot of inertia that prevents doing this sort of experimentation, because we have to make sure everything still compiles on all of the supported platforms.

I’ve moved the 1.15 Candidate phase and stable release forward to give us time to finish all our work for 1.15.

Oculus Rift DK2

While I’m still working on the 3D model renderer, I’m also updating Doomsday’s VR code for the Oculus Rift DK2. I’m posting about my progress on a thread in the dengine.net forums.

The challenge of revising the renderer

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.

Continue reading The challenge of revising the renderer

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