Tag: qt

The Switchover

I just pushed 1036 commits to the master branch. This switches it over to Doomsday 3.

Doomsday 3 in its current form is still quite unfinished and broken in many places. Especially the new renderer remains disabled by default, and cannot be enabled without recompiling. However, the basic things are running, and they’re running fast!

Even the classic renderer has gotten a boost. Although to be fair, it still has the same old bottlenecks as before. The difference is that the application event loop has been optimized, which raises the FPS ceiling even though the floor remains largely the same. On average, the game should be running more smoothly.

Continue reading The Switchover

Doomsday 2.1 RC3

The third and possibly final release candidate of 2.1 is now available (build 2898).

This build comes with a couple of Windows-related updates: the Qt library has been upgraded, and the 32-bit Windows build now has a fully functional FluidSynth audio plugin. This has been available in the 64-bit build for a while.

Unless any showstoppers are discovered, the next build will be the stable 2.1.0.

Notes about build 2353

I’ve been taking it easy for the past couple of weeks, but last weekend I did manage to merge the recent OpenGL changes to the master branch. Build 2353 now includes this work. Please let me know if something appears broken!

There was a slight problem with the autobuilder, so the build change log is empty. GitHub has your back, though.

Here’s a rundown of the most important changes: Continue reading Notes about build 2353

Tightening all the screws

For the past week I have been exclusively focusing on optimizations.

Work in the 2.0 unstable builds has been progressing without much attention having been paid to performance profiling. However, it has become clear that even in very basic maps (like Doom E1M1) there were unacceptable FPS dips. I decided to get to the bottom of what was going on. Continue reading Tightening all the screws

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

Mobile Doomsday

Speaking of mobile Doomsday, having played around with Qt 5.3 on iOS and Android, I now have a bit more concrete picture of what Doomsday will look like as a mobile build.

Supporting mobile platforms is something I think is very much necessary for the future. I see desktop computing becoming more of a niche thing, as most people’s needs will be met by various forms of phones and tablets. Still, DOOM was born in the age of desktop PC gaming and Doomsday will naturally respect this; not only will we continue to develop the project on desktop (or laptop) computers, that is the environment the game was originally designed for.

Continue reading Mobile Doomsday

SDL 2 vs. Qt

We’re switching to SDL 2.0 from the SDL 1.2 that has been in use for years in Doomsday. Sometimes I feel that minimalism would be the right way to go, and start considering if a switch back to SDL as the base framework would make sense. This scenario starts to look more enticing particularly with a switch to C++11 looming on the horizon — at least the crucial Qt components like threading and conveniences like foreach would be available via the programming language itself.

Continue reading SDL 2 vs. Qt