On Week 29
skyjake:
The past week was quite productive for me. I was doing two things in particular: fixing the worst remaining issues with multiplayer, and preparing a merge with DaniJ's beta6.10/ringzero branch.
On the multiplayer front, I managed to tackle about half of the known issues. The worst was with teleporting: it was suffering from multiple malfunctions, both on the server and on the client. In short, the client was doing the teleport locally without consulting the server, and the server was fumbling the client's coordinates, causing it to trigger the teleport again when the player was exiting it. Another significant change was how the movement of remote players is represented on the remote instances (server and client). Previously the client just sent frequent samplings of its position and momentum to the server, which then applied them to the player's mobj. Game physics was then applied to make the mobj move more smoothly. However, this approach produces warping when the player's acceleration is changing (running in a curve, strafing, accelerating... i.e., pretty much all the time). From now on the movement is reproduced by interpolating between the player's known positions, bypassing the game physics on the remote end(s). The end result is more faithful to the original motion and does not exhibit warping.
Working on these fixes was much easier now that I implemented a simple way to simulate latency on a local network connection. However, the variable "net-dev-latency" is only available in debug builds.
For a while now we've been intending to do the merge between the master branch (where the releases are made) and DaniJ's development branch, which contains the unfinished Beta 6.10 changes. I finally got the ball rolling on this and we now have a branch called "ringzero+master" in the repository which contains a work-in-progress version of the merged code base. When the time is right, we will merge it back to the master. Before that we need to make sure we haven't produced any regressions with the merge.
I will continue to work on the known issues. I will also fire up the multiplayer test servers again and we'll see whether today's build (#206) is suitable for a wider audience. There are still a few glitches in it but most of them fall into the 'annoyance' category.
danij:
This week my focus has been a series of refactorings which will allow us to utilize the resource locator for runtime/dynamically-defined non-file resources such as abstract fonts, materials and textures (presently the engine implements these separately using entirely independent APIs and object models). It is important that we resolve this now around a higher-level abstract resource manager before we move on to implementing a centralised mechanic for dynamic resource scoping (some examples being; materials scoped to wads and cvars scoped to game plugins).
Some of these refactorings have already been committed but the bulk of which I'm presently hacking away on. The highlights so far:
In addition to the refactoring I also found and fixed a few bugs non-specific to the beta6-ringzero branch:
Over the coming week I intend to continue with the resource locator refactoring work. Once complete this will allow me to fix the remaining resource management regressions in the ringzero branch (mainly fonts).
The past week was quite productive for me. I was doing two things in particular: fixing the worst remaining issues with multiplayer, and preparing a merge with DaniJ's beta6.10/ringzero branch.
On the multiplayer front, I managed to tackle about half of the known issues. The worst was with teleporting: it was suffering from multiple malfunctions, both on the server and on the client. In short, the client was doing the teleport locally without consulting the server, and the server was fumbling the client's coordinates, causing it to trigger the teleport again when the player was exiting it. Another significant change was how the movement of remote players is represented on the remote instances (server and client). Previously the client just sent frequent samplings of its position and momentum to the server, which then applied them to the player's mobj. Game physics was then applied to make the mobj move more smoothly. However, this approach produces warping when the player's acceleration is changing (running in a curve, strafing, accelerating... i.e., pretty much all the time). From now on the movement is reproduced by interpolating between the player's known positions, bypassing the game physics on the remote end(s). The end result is more faithful to the original motion and does not exhibit warping.
Working on these fixes was much easier now that I implemented a simple way to simulate latency on a local network connection. However, the variable "net-dev-latency" is only available in debug builds.
For a while now we've been intending to do the merge between the master branch (where the releases are made) and DaniJ's development branch, which contains the unfinished Beta 6.10 changes. I finally got the ball rolling on this and we now have a branch called "ringzero+master" in the repository which contains a work-in-progress version of the merged code base. When the time is right, we will merge it back to the master. Before that we need to make sure we haven't produced any regressions with the merge.
I will continue to work on the known issues. I will also fire up the multiplayer test servers again and we'll see whether today's build (#206) is suitable for a wider audience. There are still a few glitches in it but most of them fall into the 'annoyance' category.
danij:
This week my focus has been a series of refactorings which will allow us to utilize the resource locator for runtime/dynamically-defined non-file resources such as abstract fonts, materials and textures (presently the engine implements these separately using entirely independent APIs and object models). It is important that we resolve this now around a higher-level abstract resource manager before we move on to implementing a centralised mechanic for dynamic resource scoping (some examples being; materials scoped to wads and cvars scoped to game plugins).
Some of these refactorings have already been committed but the bulk of which I'm presently hacking away on. The highlights so far:
- Split the string interning mechanism out of PathDirectory and into a new class named StringPool. The new class can be used independently but the primary reason for splitting this out is to allow for a new PathDirectory specialisation using uris.
- Resource path compositing functionality is now implemented at PathDirectory level, allowing for specialisations which compose paths using different logic.
- Resource namespaces can now be constructed outside of the resource locator module.
In addition to the refactoring I also found and fixed a few bugs non-specific to the beta6-ringzero branch:
- GL textures for model skins were not released during a texture reset.
- When re-initializing models (e.g., during an engine reset) the modellist was not freed, resulting in a memory leak.
Over the coming week I intend to continue with the resource locator refactoring work. Once complete this will allow me to fix the remaining resource management regressions in the ringzero branch (mainly fonts).
Comments
Also, I notice some collision detection problems in certain maps, especially the Refueling Base map in Doom II where sometimes the effects cease completely, like the blood, smoke, and partical effects. I remember this problem even back then in certain maps. Also when I shot the wall in that map, it is like the effect is embedded in the wall since I only see some sparks, but barely sometimes and no smoke after a few minutes through that map. For the first few minutes of the map, there is usually no effects problem though, but when the effects cease to work, it makes the fire on the imp fireball and lost soul look odd. So it might be a collision detection problem on that map in Doomsday (sometimes occurs off and on in other maps too).
However, near all of this extra efficiency is apparently bottlenecked by half finished code, potentially making the current betas of Dday as a whole run slower than 1.8.6.
Obviously this half finished code will be finished in due time and then the user will see the results of the above mentioned more efficent and faster code.
I can edit my posts in the other forums.
Thanks.