Tag: home

Doomsday 2.0 released

The first stable build of Doomsday 2.0 is now available.

The highlighted features of 2.0 are:

  • Home Screen replaces the frontend app. A launcher is no longer needed; games and add-ons can be managed using Doomsday itself.
  • Built-in support for different data file and package formats. Used packages are tracked in saved games and multiplayer games.
  • The new 3D model renderer that has been in development since the 1.15 release is now mature enough for use. It supports FBX and MD5 models, skeletal animation, GLSL shaders, and scripting.
  • This is the first 64-bit stable release for Windows.

See the Manual for the complete release notes.

Thanks to everyone who reported bugs in the release candidates! A number of nasty bugs were found and fixed. There is still a few less serious known issues that have been scheduled for next month’s 2.0.1 update.

Work on the 2.x series will now continue along the lines planned in the roadmap, with the first focus area being multiplayer improvements. Under the hood, there is still lots to do with updating remaining old OpenGL rendering code so we can take full advantage of shaders in future releases.

Improved UI for multiplayer

For the past two weeks I’ve been focusing on finishing the Home UI for 2.0. I’ve also been doing plenty of small improvements and bug fixes.

The final element that has been missing from the Home is the Multiplayer tab. That is now no longer the case: build 2227 has a new UI for viewing server information, and a couple of important bug fixes for multiplayer servers.

Server info dialog

In the Multiplayer tab you can see more information about a server by right-clicking it or by clicking the […] button in the server description. This pops up the new dialog that can be seen in the screenshot above.

A direct connection to the server is automatically attempted so that you’ll see the server’s current status and to verify that the server is reachable. The status information includes the current map outline, just like in the Shell.

In addition to status information, the dialog has a “Join Game” button, a list of the packages loaded on the server (the client must load the exact same ones when it connects), and you can choose additional packages to load locally. These local packages are game-specific rather than server-specific and are remembered in the client configuration (part of persist.pack). The “Local Packages” button is disabled by default. It can be enabled in Network Settings.

Note that if you load additional local packages in multiplayer games, you must ensure that they don’t contain gameplay-affecting changes. For example, loading a different map is out of the question, as are changes to mobj states. Doomsday 2 packages with 3D model assets are safe to use locally in multiplayer games.

I now consider this UI, along with the rest of the Home, feature-complete for 2.0. The long-term thinking behind the server info dialog is to evolve it toward a mini-Shell interface so that you could issue quick console commands to servers that you control. That will not be part of the 2.0 release, though.

Continue reading Improved UI for multiplayer

Now playing

First I’d like to mention that the Windows CI builds are back. They were previously disabled because compiling Doomsday was a bit too much to handle for the AppVeyor open source builders. However, they’ve recently upgraded their hardware, which has improved build times dramatically. CI building is particularly useful for projects that run on multiple platforms since compilation issues can be caught early.

During the past week or so I’ve been tying up loose ends in the Home UI.

One thing that should be immediately obvious when starting a game in a recent build is that there is a new transition animation when loading a game or returning to Home. Namely, the Home now scrolls up and down in a manner reminiscent of the old Quake-style console. This makes the transition into a game smoother an affair, and one gets the sense that the Home is hanging around “above” the game while playing.

Previously, while a game was loaded, one could open a game/multiplayer selection dialog via the DE menu. These dialogs used the same code as the old Home screen, so they have been removed along with it. I’ve chosen a new approach to provide access to Home functionality while a game is running: the game can now be minimized so that the top part of the screen is taken over by the Home, while the game remains running and playable in the bottom.

minimized_game

In practice you can minimize the game by selecting DE > Show Home.

I also made a couple of small UI tweaks:

  • The add-on compatibility dialog that may appear when loading savegames can now be ignored by holding down the Alt key while the dialog is open. This may sometimes be useful if you are confident that the add-ons in use actually are compatible and you wish to override the rather strict criteria used by Doomsday. (However, this may also lead to a crash if the add-ons actually are incompatible.)
  • In fullscreen mode (while in Home), there is a convenient Quit button in the top right corner of the screen next to the notification area.

On the bug fixing front, some important issues were addressed:

  • Recently I was refactoring the resource management code and inadvertently introduced a bug which caused game color palettes to randomly malfunction. This has been fixed.
  • Sometimes the automap was not being drawn (bug 2165).
  • Crash when unloading data files, for example when switching add-ons on the fly.
  • The data files within a .box were not sorted properly, leading to false negatives in add-on compatibility checking.
  • The UI focus indicator did not respect UI blurs or clipping rectangles.
  • Final remnants of the fixed-length file path handling were removed (bug 1829).

Files and fixes

Last week I continued working on Home and data file packages, and fixed a number of bugs.

Loading of PK3s, WADs, individual lumps, DED files, and Dehacked patches is now working via Home. Loading of .box folders is also somewhat operational, although the dependencies of the box contents are not yet completely handled. (Boxes can have required, opt-out, and opt-in files.)

I put quite a lot of additional effort into cleaning up how data files get mapped to Doomsday packages particularly when it comes to selecting identifiers and tags. This could still be improved with additional rules for smart detection of file groupings based on common names and parent folders. I’ll probably leave the finer adjustments for later.

The game profiles you see in Home are now more deeply integrated into the rest of the application. They are used when loading game plugins, so that the packages selected for the profile are appropriately loaded and unloaded. Multiplayer games will also be using profiles shared by the server.

I also did several bug fixes for issues that have cropped up in recent unstable builds:

  • On Windows, quitting the game might not always trigger unloading of the game plugin, leaving you with a black screen. (Shift-Esc was still working.)
  • If the .cfg files were missing when launching Doomsday, they weren’t written at all. The clearest symptom of this bug was that your settings were not remembered when relaunching the game.
  • There was a long-standing bug in the doomsday.out file writer that had not been triggered before. It was causing log output to stop being written to the file at a certain point.
  • The Home UI layout was not always updated correctly when the window was resized (or display resolution changed) while a game was being played.
  • Popup widgets with long text content were using too much memory.
  • There was an illegal memory access to a deleted object when closing submenu popups, for example when viewing information about a package.

Refinement

I came down with a small cold so progress has been somewhat slow recently. My main focus continues to be the Home UI.

I’ve mostly been applying small bug fixes and improvements, such as correcting errors in the Home layout. The Tutorial was also crashing because it was trying to reference a removed UI element. There is now a new settings dialog for configuring the UI. This includes a new setting for slightly scaling down the fonts and other UI elements. This should be particularly helpful when using smaller display resolutions. Continue reading Refinement

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!).