Tag: package

Steady progress

Last week I continued working on the Home UI as planned.

There is now basic keyword filtering for the Packages list. The entered words are matched against package names, IDs and tags, so it is possible to quickly locate specific packages.

The current implementation is quite rough, though, and not suitable for large collections of packages. It needs optimizing, and the list widget itself should support reusing a small number of widgets to represent only the potentially visible items. At the moment it simply creates widgets for the entire list, even though most of them would be outside the view.

Another improvement is persistent state for the Home columns and item selections. In other words, when you start Doomsday, the previously selected column and game are automatically re-selected.

On the whole the work is progressing as planned and it is clear what needs to be done next. My short-term goal is getting all the important features working so the new UI can be released in the unstable builds for public testing.

Homeward

With the 3D model renderer in reasonably good shape so that new models can be worked on, I’m now pushing toward building the front-end’s central features into the Home screen: selecting PWADs and other resources to use when playing a game.

The main feature I was working on last week was a new way of handling classic data files such as WADs, PK3s, DEDs, and DEHs. The engine is now able to recognize these files and treat them as Doomsday 2 packages internally. Additionally, I’ve added a small database of known files (such as the vanilla IWADs) that are further identified as packages with very specific IDs and versions.
Continue reading Homeward

Getting started on data file packages

This week I decided to switch gears and start work on support for data files in the Doomsday 2 package loader.

As planned, the idea is that the various supported data files are each seen by Doomsday as packages. This makes it possible to identify the data files uniquely, save the list of used files in savegames, share the file list in multiplayer games, and also set up game configurations via the Home screen.

In practice, I’ve begun by making the Doomsday 2 file system aware of what these data files (like WADs and PK3s) are and what kind of data they contain. I’m also planning to set up a new way to identify data files based on a set of criteria read from a configuration file. Continue reading Getting started on data file packages

Wand update and custom shaders

This week’s screenshot shows a work-in-progress version of veirdo’s beautiful new Sapphire Wand model for Hexen. It takes advantage of the new model rendering features such as random alternative animation sequences, animated shader variables, and custom GL parameters for drawing layered effects.

On the topic of weapon models, the new renderer still lacks the vanilla-style walk bobbing. That shouldn’t be a lot of work to implement, though. After some additional weapon position fine-tuning this should be ready for prime time, and we can start preparing some models for distribution and use with the 2.0 builds.

As planned, last week I was working on a better way to load shaders from packages. I managed to complete the improved functionality as planned: when any package is loaded, it is checked for shader definitions; if found, the shaders are added to the runtime shader bank. Similarly when a package is unloaded, its shaders are removed from the the shader bank. Now there is no longer any special case logic needed for the net.dengine.client packages, as their shaders are loaded the same way as shaders from any other package.

I then proceeded to add a way to customize shaders using macros. Like C, GLSL allows defining macros for the preprocessor. This enables injecting custom code at compile time. For example, let’s say a model wants to continuously scroll its texture. This could be done using Doomsday Script, however one would need to keep restarting the script at regular intervals to keep the animation going — not the most efficient way to do things if you have a lot of objects using the model. However, if the model injects a line of code into the model shader for modifying its UV coordinates on every frame, all the work is done cheaply by the GPU. And even better, if the shader is later updated (for example when the user installs a new version of the engine), the model has a much better chance of continuing to work correctly.

Click the screenshot below for a short animation:

UV scrolling shader

Naturally model packages can also provide their completely custom shaders that do not depend on the net.dengine.client shaders in any way.

I was also briefly obsessed with improving the formatting of log entries. There is something about formatting text that manages to hook me every time. The most visible changes are that the so-called “log sections” that contain contextual information about where a log entry was created are now placed within square brackets. This should improve readability. In the doomsday.out/runtime debug output, the content now uses better alignment to visually indicate which entries belong together.

#1815 200.594 I  (v) [BindContext] 'global' cleared
#1815 200.594 I  (v)               'deui' cleared
#1815 200.594 I  (v)               'console' cleared
#1815 200.594 I  (v)               'message' cleared
#1815 200.594 I  (v)               'chat' cleared