On Week 40

skyjake

skyjake:

Last week I made some nice progress with the remove-sdlnet branch. I've now gotten libdeng2 set up for all the platforms, and the LegacyCore class that hosts deng2 functionality under the C-based engine is up and running. I've imported a number of useful classes from the Hawthorn branch, mainly related to networking. The plan is to next implement a simple C API similar to SDL_net using which the old network code can tap into the Qt-based networking in libdeng2. After that's working I can start extending it with new useful things like monitoring output bandwidth.

Let's take a quick look at the big picture. As you know, we are working towards a new stable release that will be given version number 1.9.7. This is a breakdown of our current roadmap items for the stable release:

• Replace CMake with qmake. This has been completed. We are still tweaking the details a bit to make things nicer on the whole, but qmake is now successfully handling the build on all our platforms. This is very good for the future as we can soon include Qt in the master releases, giving us a nice boost in terms of software technology.
• Fix network games. According to my estimation most of the big, gameplay-ruining issues have been solved in multiplayer. However, plenty of smaller issues remain that collectively reduce the quality of the experience. More work needs to be done on this front. However, I expect that some small issues will remain in 1.9.7. The work to polish the multiplayer experience will then continue in subsequent stable releases. (As we now have the master branch in solid shape, we are able to make much more frequent stable releases after 1.9.7.)
• Fix player controls. This hasn't yet been addressed, but we have some solid leads as to what might be behind the "wrong" feel of the player controls.
• Fix the 64-bit build. I believe on this front we've made some nice progress recently: I made sure that in 64-bit builds the engine is not using the wrong data types in places like savegames. I have switched to using the 64-bit build for daily development on my Mac, so any remaining issues should be caught sooner or later. However, it is worth mentioning that in terms of performance or memory use, the 64-bit build has no real advantage over the 32-bit one.
• Merge ringzero to master. The merge is ongoing in our repository ("ringzero+master" branch). DaniJ knows the latest details on this, but overall there is still a number of things to fix before the new code can be included in the master branch. I'm looking forward to when the merged codebase is up and running, though, as there's plenty of great stuff in the works, e.g., the "Resource URIs" roadmap item.
• Optimize performance bottlenecks. As brought up in last week's update, we have some pretty serious performance bottlenecks that need to be optimized for the stable release. I don't suggest we'll spend a lot of time on this for 1.9.7, but at least the dynamic light related slowdown seems quite important.

Overall I'm pretty happy with the progress we've been able to make during the past months, given the limited amount of time we have for working on the project. It is very difficult to make any predictions as to when we might be able to finish 1.9.7 but I'll keep everyone posted on this forum.

My plan for this week is to continue with the low-level networking code rewrite, hopefully finishing it. The work is quite straightforward and I don't expect to run into any bigger issues. One last note: once the Qt networking is in place, we can also get rid of cURL (master server comms), reducing the number of external dependencies.

danij:

Last week I mostly spent researching and experimenting with the WiX Toolset and Windows Installer technologies. The plan being to replace our use of Inno Setup for generating the Doomsday for Windows Installer. Toward the end of the week I started the new branch replacing-innosetup-with-wixtoolset and began fleshing out a first attempt at using this technology (and incorporating it into our automated release system).

This work has been going well thus far, though there remains some significant roadblocks to overcome (the fact that Windows Installer only deals with three part version numbers for example). However we now have a somewhat functional installer that is automatically generated as a process of the automated release system using WiX.

Over the coming week I plan to continue working on the new installer and implementing several new features rather conspicuously missing in previous incarnations (for example, optional user config clean up on uninstall). Hopefully I'll have this work completed by the time I make my next update, so I can then return to working on the ringzero branch.

gary

I'm playing Plutonia II & confused because a certain wall texture that I believe is supposed to be bloodfalls, like in the map called 'Where the Hate Runs Red' and the map before that, changes into a different texture every 1/2 of a second or so. I'm sure the texture is animated and it isn't using all the proper textures through the entire animation but instead displays different wall textures quickly one after the other, which looks strange. It switches through about 5 or 6 different textures in a matter of 2 seconds. Even when I remove the high res textures folder that I made under jdoom (created it so that I could use high res textures in place of the doom I and II textures being used in Plutonia II and delete the ones that are covering up the Plutonia 2 textures) & shut off the texture pack under addons, it still does this. I wonder if it is a problem with 6.9 itself and it not being 100% compatible with this wad. According to a video on youtube of those maps, it looks like it is supposed to be the bloodfalls textures, and I already suspected that before I watched the video.

Vermil

Does Dday still have animation defs, that define the entire animation, for the original texture animations somewhere, like it did in 1.8.6? Or does it now handle the original animations in the same way Vanilla Doom does (i.e only checks the first and last frames)?

DaniJ

The blood fall problem in Plutonia 2 is a known issue that has since been fixed in the ringzero branch. There are in fact a number of issues with this mod in current releases that have already been addressed but the fixes for which aren't out in the wild yet.