Tag: fedora

Game profiles, autobuilder upgrade

Progress has been somewhat slow recently. The central new component I’ve been working on is game profiles. They represent the combination of a game and a list of packages to be loaded with that game — much like a Snowberry profile. A key feature of the Home UI is to let you create and manipulate game profiles.

You may recall that a few years ago we added renderer appearance profiles to manage the various renderer settings. The implementation of these was tied to the old console variable system, but there was a good portion of code that was reusable also for game profiles. I refactored the appearance profiles to extract the generic parts that deal with saving and loading profiles to/from an Info document, and generalized the concept of a profile. That allowed me to rather easily implement game profiles. In practice, the profiles will be written to a file called “configs/game.dei” under the runtime folder.

Now that Ubuntu 16.04 is around the corner, the autobuilder server is due for a system upgrade. My plan is to get rid of the 32-bit Linux builders (Launchpad should take care of that), and only set up builders for 64-bit Ubuntu and Fedora. The Windows builder will be using Windows 10 and the upcoming Qt 5.6 with MSVC2015. I should be finally able to configure a 64-bit build also for Windows (fingers crossed!).

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.