On Week 35

edited 2011 Sep 5 in Developers
skyjake:

The past week was pretty slow-going for deng work. I fixed a couple of the known issues in multiplayer, such as co-op weapon pickup notifications. I also went through the items in the list and did some re-prioritizing: particularly, I moved the weapon behavior issues to the top, as they can affect gameplay quite a lot.

I spent some time thinking about the best way to get rid of SDL_net and replace it with Qt-based networking. Basically I'd like to start copying things over from the Hawthorn branch, so that we would have a bare-bones libdeng2 library in the master. Initially it would contain just the new network code plus any Qt-related mandatory things like the Qt event loop. This copy of libdeng2 would be completely separate from the rest of the engine at this point; it would basically be treated as a 3rd-party shared library that provides low-level networking functionality for the engine. However, over time, we can start moving & upgrading engine functionality into libdeng2. This way we can avoid converting the old engine sources to C++. We can also provide a legacy C API from libdeng2, so it can be used from the C-based engine and plugins.

My plan for the coming week is the same as before: continue working on the known issues. If I have some extra time, I may also start looking into introducing libdeng2 to master, as getting rid of SDL_net will allow increasing the robustness of multiplayer games, making game behavior more manageable and predictable.

danij:

At the beginning of the week I decided to implement a web based Master Server XML output. The reason being it can then be easily processed by scripts like Master Server RSS, a set of XSL Transformation transforms into almost any other format like RSS 2.0 in this particular case (download). I've got further plans for this, involving either some javascript or an iframe and some HTML 5. However I didn't want to be distracted too much from my current work on Doomsday itself so I've not taken it any further.

Last week I mentioned the in-progress engine component LumpCache. LumpCache is now functionally complete but the interface needs refinement. While considering the LumpCache interface I began reckoning up the architectural impact it would have within the rest of the object API. In the process I realized a few very necessary changes in our object architecture and ultimately decided to put LumpCache aside temporarily while I implement them, as they will in turn help to improve it's interface.

This work is going well thus far, open files are now represented using a set of further specialised objects from their previous DFILE base (now known as AbstractFile). I am now in the process of refactoring the old DFILE out of the architecture.

So, I've got the refactoring to complete, LumpCache to finalize and then I've to integrate it. Lets see how much I get done this coming week.
Sign In or Register to comment.