Howdy, Stranger!

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

On Week 45

edited 2011 Nov 16 in Developers

Last week I ran into difficulties while testing my new Qt-based network code on the public server. I have come to the conclusion that the root of the problem is that I've been a bit too conservative in making changes to the original Doomsday executable: it seems that simply removing SDL_net while keeping the rest of the application tied to SDL will not play nice with Qt's application and event loop management.

While I managed to remedy the situation on the Mac, the same kludges will not work on Linux (and Windows, I assume). I don't like the notion of applying this many workarounds in order to get a temporary networking solution up an running, so I am leaning towards the full removal of SDL.

However, going cold turkey on SDL will have some short-term implications. In particular, joystick/joypad support on Linux and Mac is dependent on SDL. After switching to Qt, we must find another way to provide this important functionality. One approach I have been considering is running an SDL-based background process that reads the joystick input and passes it to the main client executable via some form of IPC.

Totally getting rid of SDL also means rewriting the default window management code and the fallback audio driver, so it's not a trivial change. Furthermore, I would like to take this opportunity to add a new dedicated server executable target that is not linked against any of the 3D, input, or audio libraries. This will make it easier to run and maintain a dedicated server, and it will be easier to turn it into an "invisible" server daemon process (and restart it automatically in case of a crash).

I have not forgotten about the multiplayer debugging. My choice at the moment is between continuing with debugging gameplay issues in the master branch, or starting the more sweeping Qt-related changes in a continuation of the remove-sdlnet branch. Presently I am still undecided which of these I should focus on; maybe a short trip to Skyrim will help make up my mind.


Over the past week worked continued on refactoring the management of texture resources. This work is steadily progressing toward the goal of linking it in with the general resource locator subsystem.

I reworked texture resource initialization to allow dynamically reloading textures without having to clear and rebuild the whole Textures collection. At the same time I also implemented a name/path binding mechanic, allowing multiple names to reference a single Texture instance. Consequently, Texture instances and their associated identifiers are managed in much the same way as the Materials with the exception that Texture instance references are not public.

Work also began on implementing a deferred construction mechanic for Texture instances. The Textures collection now implements a declared state (by name/path) prior to their definition. This allowed for the autogenerated Material definitions to now be constructed from declared textures rather than defined ones.

The next step is to revise the way we deal with DOOM's texture animations. Presently these are constructed from chains of Materials via a game-side mechanic which operates post game-initialization. There are several issues with this, not least that it means animations defined using Group definitions are overridden by the auto-built animations. My current thinking is that this mechanic should be replaced with one which builds new definitions, operating post game resource loading but prior to definition processing.

Unfortunately the current DED interface for manipulating definitions outside the engine is rather limited. It may prove easier to define a temporary interface for building the texture animations abstractly using URNs.


  • I think that resolving the input device situation is the logical next step given your findings in the remove-sdlnet branch. On Windows joystick/joypad support is currently dependent on the old DirectInput code for this (which should be replaced anyway), implemented as a subroutine of the main application loop. Once we switch to Qt, this will have to be revised on Windows too. Consequently it seems to me that moving this out of the engine and into an input plugin, which communicates with the main executable via an IPC protocol is the next step.
  • Looking at the big picture, I think that at this moment we should prioritize getting the stable 1.9.7 released, and then we can start looking at more disruptive refactorings like the removal of SDL. This means that the network code in 1.9.7 won't be as good as it could be due to SDL_net's shortcomings, but at least it will be playable on a sufficiently speedy internet connection.

    So I'm thinking that I will continue addressing multiplayer gameplay glitches for now in the master branch. It would also be good to get maximum utilization out of the public server, which I'm still funding myself. I won't be able to solve every single known issue as some of them are due to the lack of bandwidth management, but I should be able to still make significant improvements in the gameplay experience (e.g., psprite functionality).

    After the stable 1.9.7 is done I can continue with a remove-sdl branch and start by solving the input situation.
  • Presumably this means libcurl will be around for the 1.9.7 release in that case? I still need to implement an encoded representation for Uri in the ringzero branch, which could be implemented using cURL if it will be available.
  • Yeah, cURL won't be going away until the Qt-based network code is up and running.
Sign In or Register to comment.