On Week 31

edited 2011 Aug 11 in Developers
skyjake:

The past week was very interesting as we finally got started with testing the revised multiplayer code with a larger number of people. Immediately a large number of issues was discovered, the worst being that there was a serious problem with the client-side network message reception: the client was overflowing its reception buffer, which meant 1) heap corruption and 2) some messages were only partially read. This was fixed in build 217, which had a record 26 commits -- highest so far for any unstable build.

Unfortunately there was a new issue in build 217 with client-side plane management, which caused doors and lifts to easily malfunction. The issue manifested when the client received a new move delta for a plane that was already moving: the old mover wasn't destroyed, causing the new one and the old one to both attempt moving the plane. Consequently the plane stalled on the client even though on the server everything was operating normally.

Currently the servers are suffering from a problem where they stop announcing themselves to the master after several hours have passed. The fix is quite straightforward, but it requires setting up a persistent background thread for master-server communications. Apart from that the servers are getting more stable. I have seen a couple of occasions where they hang with an infinite loop, but the few segfaults that have occurred have all been easy to fix.

Many thanks to all who have participated in the multiplayer testing! There is still much to do and the testing will continue, so your patience and perseverance is greatly appreciated. My plan is to keep working through the known issues roughly in order of gameplay impact.

danij:

This week saw progress pick up once again, with 38 commits to the ringzero branch. Work continues to be centred around resolving functionality regressions compared to previous releases and consequently, I again find myself struggling to write this blog update. That said, there was a significant number of bug fixes and optimizations in addition to the regression work.

One of the more interesting possibilities afforded by the recent work is the ability to dynamically load and unload resource packs like the DHTP (highres textures) from the in-game console. I hope users find this at least as useful as I do for debug purposes :)

The WAD directory name-search algorithm was replaced with a derivative of that written by Lee Killough (for PrBoom), which reportedly offers a ~300% speed improvement over the original. Virtual file system search time (i.e., de::PathDirectory) has also been reduced significantly.

Next week the plan is largely unchanged, I intend to continue addressing regressions and improving robustness of the new ringzero feature set.

Comments

  • So it's safe to say that the next release of jdoom will be much faster ingame and much less slowdown with monsters on screen?
  • Not because of these optimizations no. Unlike vanilla DOOM we try to avoid searching for resources in-game by precaching search results and/or data resources during the game and/or map load processes. Although these optimizations will affect cases where a resource has to be loaded dynamically (for example, a Patch used in the UI that hasn't yet been registered), they are more about accelerating processes outside of actual gameplay.

    That said, there has been significant improvements elsewhere which should help with the cases you mention.
Sign In or Register to comment.