On Week 45
skyjake:
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.
danij:
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.
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.
danij:
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.
Comments
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.