On Week 16

skyjake

<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Blog.</i>

<strong>skyjake:</strong>
<ul><li>The past week I have been finishing up on fixing the remaining serious show-stoppers in multiplayer games. So far I've been running in co-op mode only, but I don't expect any major problems with getting deathmatch mode also up and running. Among the most important fixes of the week were 1) client picking up items, 2) improved tick smoothing (removing all the things that might lead to unsynchronized ticking), 3) client's palette effects (e.g., flash red for pain), and 4) various issues when dealing with more than one player in the game (e.g., spawning when changing maps, swapping player mobjs when dying).</li>
<li>Overall, the work with repairing multiplayer in the master branch has been progressing rather well, and I think we've reached a point where the focus of the work can move onto fine-tuning certain behaviors instead of fixing the gameplay-ruining bugs. At least I will need to check up on plane movement and how mobjs are affected by it on clientside, and see how well 3D models are animated on the client.</li>
<li>I'm not sure how much time I have for Doomsday next week, but my plan is to keep up with the fixes and when things are looking good enough, I will set up a public open server so that everyone interested can join in on testing the revised multiplayer code. However, while this allows me to stress-test and debug the server, it doesn't give me much to go on with the improving the clientside experience (as I'll practically have a zero latency if I join the game). Thus it would be helpful if someone were to run another server so I could witness the clientside behavior first-hand. But it will still take a few weeks before we reach that level of code maturity...
</ul>
<strong>danij:</strong>
<ul>
<li>This week I've not had an awful lot of time for actual coding work. There have been changes, certainly, including the reimplementation of the console variable database using <tt>de::PathDirectory</tt> and various public API refactorings, however not a lot else. My deng development time this week has largely been spent on planning upcoming work. Particularly the plan of approach to the folding of our resource management subsystems in with Qt's class library architecture and how the remaining work in the ringzero branch will mesh with it.</li>
<li>Over the coming week I plan to effect a few refactorings which are designed to address some of the issues I've encountered in our existing architecture. In addition I plan to leverage libcurl to implement a percent-encoded representation of <tt>de::Uri</tt></li>
</ul>

skyjake

A small amendment to the plan: so far I've been focusing on fixing Doom, but Heretic and Hexen need some attention, too. Thankfully the code is very similar in all the game plugins, it's mostly a matter of applying the same set of fixes to all the games -- the biggest task is making sure that all the problem scenerios have been addressed in all game modes.

DaniJ

I think you'll find there is a little more work to do than you first expected. The intermission sequences in Heretic and Hexen have never worked correctly in multiplayer games, to my recollection in any case.

Furthermore, Hexen itself is fundamentally broken multiplayer since the shift to a client/server architecture, as mobj spawning was never updated to take this into consideration. At the very least, mobjs will need to be spawned for all spawnspots, regardless of their player class flags, always. Although I don't think it will be as easy as that, given that it would be logically possible to use this mechanic to have mobjs spawn in completely different parts of the map depending on the class of the primary player (i.e., consoleplayer). I don't recall what happens in vanilla Hexen although I expect it wasn't explicitly dealt with (i.e., I'd hope to find an <tt>if multiplayer then ignore class flags</tt> logic in there somewhere, thus forcing mappers to deal with the situation if they intended to support multiplayer modes).

As for the client-side multiplayer debug, I'd be happy to host a server for you when the time comes.

skyjake

OK, thanks for the heads up. The intermissions at least should be easy enough to fix.

<blockquote>the plan of approach to the folding of our resource management subsystems in with Qt’s class library architecture [...]</blockquote>
I'm interested in hearing your thoughts on this... My thinking for the long-term plan is that the libdeng2 file system would provide the underlying foundation for resource management -- although I haven't yet considered all the intricacies of the resource handling.

Also, what is the status of starting the merge of ringzero to the master? It would be better to get it over with sooner than later...

DaniJ

<blockquote cite="#commentbody-3601">
<p>I’m interested in hearing your thoughts on this… My thinking for the long-term plan is that the libdeng2 file system would provide the underlying foundation for resource management — although I haven’t yet considered all the intricacies of the resource handling. </p>
</blockquote>
My interpretation of the Qt resource management systems is that they are pretty much a superset of the facilities already present in the current Doomsday architecture. Nearly all of our existing concepts such as the resource search paths, namespaces, etc, have logical counterparts in Qt with equivalent logical mechanics. Much of the work done in ringzero thus far has been to resolve areas where our own implementations diverged from their equivalents in Qt.

The Qt resource management systems are extensible, meaning we can wrap and hook our own management facilities into/around it (specifically, the WAD and Zip archive file handlers).
<blockquote cite="#commentbody-3601">
<p>Also, what is the status of starting the merge of ringzero to the master? It would be better to get it over with sooner than later…</p>
</blockquote>
The ringzero branch is now at the stage where I'm tying up the loose ends and fixing regressions compared to the old beta6 branch. The most important tasks left to do are fixing up the game menu (which I'm currently working on), implementing an encoded Uri representation and completing the texture and material variant specification implementations.

Merging ringzero with the master is not going to be straight forward, thats for sure. Looking at the change sets for both I'm thinking it will be easier to manually replay the changes in the master commit-by-commit to a copy of the ringzero branch.

skyjake

Integrating things with/into the Qt resource system does seem like a worthwhile thing to do, although I believe it is mostly geared towards wholly static data. In constrast, the contents of, e.g., Zip archives can be changed by Doomsday, so we must be careful not to restrict the system by employing the Qt resource system at the wrong level of the architecture.

Also, Doomsday's resource system must integrate neatly with the script engine, so unless we also switch to Qt Script (which might have some advantages; although I'd prefer the Python-esque Doomsday Script), it might get tricky to rely too much on the Qt resources.

DaniJ

In Doomsday we basically have two types of data resource; static resources loaded during startup and dynamically loaded resources for things like textures and mods. As of the beta5 release we've had something of an issue with the classification of data resource, particularly, those which are said to be "startup resources" which must exist prior to the initialization of the file system abstraction layer and the resource locator. For example, resources like the fonts used during initial startup and rendered with in busy mode.

My thinking is that these "startup" resources could be acquired through the Qt resource system. In other words, replacing the bottom-most layer in our own filesystem abstraction using Qt's implementation. On top of this lower-level we can re-implement our own resource management systems, leveraging a great deal of the Qt class hierarchy.

On the scripting side I too think we should use our Doomsday Script system. There wouldn't really be much to gain from leveraging Qt Script.

skyjake

Well, when it comes to the "startup" resources, that issue is solved in the Hawthorn branch by initializing de::FS as soon as possible -- everything, including plugins, are loaded using it. As de::FS is also supposed to serve up the resources, there shouldn't be a problem?

One feasible option that I see is to expose the Qt resources as one branch in de::FS, under a (e.g.) QtResourceFolder class. They would be ideal for static platform-independent engine resources such as UI images.