Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

Week 46/2013: Camera lens effects

edited 2013 Nov 18 in Developers
Last week I was working on camera lens effects and lens flares, and DaniJ has been refactoring the resource management subsystem.

I have been working in a branch called gl2-lensflare. Much of last week I spent organizing all the current camera lens effects into one, well-defined rendering subsystem. Currently the engine supports applying a simple color filter, vignetting, and lens flares. I also added a new type of effect that allows applying any OpenGL shader on the rendered frame. This is useful for effects like Doom's inverted monochrome invulnerability filter, or for instance a film grain effect.

Here is a screenshot of a test build where an inverted monochrome shader was manually applied using the new "postfx" console command:


(Doomsday on the left; original Ultimate Doom on the right.)

My goal in the work branch is to rewrite lens flare rendering using GL2 graphics. This is a good place to start incorporating GL2 into the renderer because it is mostly a superficial layer on top of the GL1-rendered map. I won't be merging this branch back to master until the flares are looking better than the old ones, so it might take a while before this lands in the unstable builds.

The Oculus Rift support is in a fine-tuning stage now. The goal is to get it working well enough in time for the 1.13 release, which is planned for late December.

My plan for this week is to continue the work in gl2-lensflare, first trying to render something meaningful using the GL2 classes in such a way that it can be incorporated on top of the GL1 frame.


  • Through my work updating the renderer's draw list mechanism (which was merged to the master last week), I came to realize that it is the resource representations which is stifling progress elsewhere. In this case it was the basic GL texture representation which underpins the texture management being the issue.

    Historically Doomsday has lacked a solid separation between resource management and the various solution domains (such as rendering and audio) that utilize them. This is partly due to vanilla DOOM lacking such a distinction -- anything that isn't renderable and which isn't a part of the play simulation is dealt with in a very loose, ad-hoc manner. I decided it was high time we dealt with this situation and began a new "resourcesystem" work branch.

    I plan to tackle this work in a series of largely separate but overlapping phases. The goal of the first phase is to establish a single, central resource system in which to store and provide access to all shared, logical resources used by the other domains. In the process I'll be reimplementing much of the old C-style code which remains for this. Bitmap fonts. Color palettes. Sprites, etc. Once achieved this work can be merged back to the master.

    The next phase will involve more progressive redesign and refactoring. I expect that most of which won't happen until after the 1.13 release as we've other more urgent work scheduled which must take precedence.

    Thus far I've established a ResourceSystem which has ownership of fonts/materials/textures and various other resource types. My plan for this week is to continue this work, bringing in more resource types and updating them in the process, where necessary.
Sign In or Register to comment.