Category: Developer

Developer blog and journal entries

Miscellany

Last week I was working on various odds and ends. It has been a nice change of pace after a few weeks of focusing only on the new model renderer.

That’s not to say I didn’t do anything model related. I made several minor improvements:

  • The model definition can specify an offset to apply to the object origin (worldOffset).
  • Special built-in shader variables are made available for model rendering, for instance uMapTime that stores the time since the start of the map. This is useful for continous material animations.
  • Fixed a bug that caused lighting to be incorrect on scaled models.
  • Autoscaling is no longer enabled by default. The assumption is that the model author has sized the model as intended. Enabling autoscaling will make Doomsday match the height of the model with the height of the thing’s bounding box.

On the Linux front, I upgraded my Fedora installation to 23 and was quite impressed with how it’s coming along. A few test builds showed that our CMake configuration wasn’t working quite right with the newest CMake versions (failed to enable C++11). Another issue that needed addressing was the incorrect linking of the FluidSynth plugin — it was causing a crash at startup.

I have decided to disable Oculus Rift support in the distribution packages. We haven’t updated Doomsday’s Oculus Rift code since LibOVR 0.5, so it has become incompatible with the current Oculus SDK. I think the wisest course of action is to revamp the code after Oculus releases the official 1.0 SDK. I have to say, though, that I am currently not planning to upgrade my Windows PC to be compatible with the Oculus Rift system requirements. It may take until a later time when Oculus Rift support is fully restored. (One can of course use the older builds with the older Oculus SDK versions.)

I also did a small fix on the dengine.net Forums: our phpBB style template was a bit broken and it wasn’t showing the attachment and poll creation options.

We have been releasing patch builds for the stable release on the first of every month. This means 1.15.6 is coming on Tuesday with a fixed OS X build, removed Oculus Rift support, and some source cleanup.

Wiki facelift

The wiki has received a major facelift. I admit I have a soft spot for pretty document styling, so I’ve been planning to improve the looks of the wiki for quite some time now. Since I’ve been fine-tuning things elsewhere on the site, I decided to align the wiki style with the homepage appearance as well.

There are also functional improvements: I’ve enabled a mobile view extension that works much better than desktop view on phones. Another new extension provides syntax highlighting for source code blocks.

There is still plenty of work left with updating the contents of the wiki. Many of the articles will become obsolete once Snowberry leaves the picture. The build instructions are also still for qmake, although we’ve switched to CMake. It would be great to have a revised, concise User Manual section in the wiki, too.

OpenGL Window

Our reliance on the old QGLWidget has been somewhat of a stumbling block now that the renderer is starting to embrace FBOs and other modern day OpenGL concepts. Fortunately, Qt 5.4 now offers a new way to manage the OpenGL surface in a way that is more compatible with OpenGL 3+ and the Core profile. Furthermore, since Doomsday doesn’t need the OpenGL surface to be an actual QWidget, it will save resources not having to treat it as one. Continue reading OpenGL Window

C-Made

I’ve been setting up CMake build files for Doomsday in the cmake-build branch. This has been quite an undertaking because Doomsday has about 50 individual components to build. (Mind you, some of those are tests and tools.) Not having done anything substantial with CMake in recent years, it was very useful to really jump into the deep end and get familiar with CMake version 3. While setting up the build for all the components on OS X, Windows, and Unix I gained a real understanding of CMake as a scripting language and now feel quite comfortable with how it operates. Continue reading C-Made

When it’s done

There are two popular ways to manage software releases: feature driven or timeboxed. In a feature driven project, each version commits to a predetermined set of changes and the release is done when everything has been finished. In a timeboxed project, releases are done based on calendar dates without committing to any particular set of features. The latter method is used for example by modern web browsers and Ubuntu.

We more or less followed the timebox method during stable releases 1.9.10–1.14, having a roughly three month release cycle for each version. However, during the 1.15 unstable builds the schedule was first extended and then continually delayed. It eventually became clear that we had abandoned the notion of timeboxing completely.

Continue reading When it’s done