On Week 16/2012
skyjake:
I was continuing work on the to-do list for the stable 1.9.8. Overall, preparations for 1.9.8 are progressing at a nice pace. I divided the to-do list into "showstoppers" and "lesser defects". Once we are out of showstopper issues we are technically ready to make the stable release, but I would prefer to fix the less significant issues, too. We may have to extend the candidate phase by one extra week so that the release will occur on week 19 instead of 18.
I fixed a number of minor glitches, for instance related to Windows keycode mapping, default 3D reverb volume, and the autoaim menu option. To improve mouse input smoothness on X11/Linux I applied a fix to how game window updating is done.
There were a couple of multiplayer improvements and fixes. In Hexen, one can no longer instantly change the player class when connected to a network game. Instead, changing the class via the menu or the "setclass" command will cause the class to change on the next respawn. Another change was that in Hexen co-op, items flagged for all player classes will be spawned automatically. This is because on dedicated servers players may come and go at any time; only the items for the players present at the start of the map would get their items. I also fixed a potential crash in Heretic and Hexen where using an item was causing the client to attempt accessing an invalid memory location.
I spent some time looking into why flying monsters get so easily stuck in objects, e.g., the barrels in the starting room of Heretic E1M1. After investigation I made a couple of changes: there is now a new compatibility option for Doom and Heretic that allows flying monsters to float upward over things that block their way (game-monsters-floatoverblocking, defaults to 0; also added to the menu), and flying monsters that use the MF_SKULLFLY flag to make "quick swoop" attacks will be specifically checked against getting stuck mid-attack. After these changes the Gargoyles in Heretic E1M1 should not be getting stuck any more (with or without the new cvar).
The next focus area was player controls, specifically the Sidestep/Strafe control. It turned out there was an old piece of code that was forcing the value of the control to be either -1, 0, or +1. Naturally this meant that analog controls were not being applied properly when strafing. I also fixed the issue where walking or sidestepping with the mouse would produce inconsistent speeds depending on whether moving to a negative or positive direction on the axis.
I noticed an oversight in the engine's GL initialization: non-power-of-two textures were always enabled in the engine even though the driver was not promising support for such textures. This fixed the issue of a completely white main menu background, red blocks instead of menu text, white rectangles instead of psprites, and other such serious graphical glitches.
The final item of the week was a significant forward-looking task where I ported the frontend's cfparser.py module to C++ and included it in libdeng2. This is useful because it provides the ability to read Snowberry profiles, configuration files, and addon metadata (Info) files. Particularly the Info files are important because in the future we will add support for the .box and .addon formats directly into the engine. Currently they are understood only by the frontend. However, for the time being the parser is utilized for Unix system-level configuration files. Check out the man page and wiki for details about /etc/doomsday/paths and ~/.doomsday/paths.
DaniJ:
Last week I completed work on upgrading map coordinates in the playsim and map geometry to use 64-bit, double floating-point precision. After which I then switched my attention to the 1.9.8 to-do list.
The switch to using double was relatively straight forward as algorithmically speaking, the code is largely unchanged. Using double precision is particularly important in large open maps, where there is a very real possibility of exhausting the precision of floats. (Potentially resulting in very erratic behavior). The renderer has not been similarly upgraded and is still using floats. Instead we do in-place conversions where necessary and data is uploaded to the GPU as float. Double precision is used for depth sorting of vissprites but that is all presently.
As we are rapidly approaching the planned renderer rewrite, I felt it was too much work to bother updating the existing renderer. The 2.0 renderer will of course use double precision where necessary, when the time comes.
Upon finishing the map coordinate merge I took a look at the non-functional keyboard showstopper on Windows. It turned out to be a simple case of not receiving a focus message from Qt. Manually focusing the main Doomsday window during initialization seemed to solve the problem.
The next task I decided to focus on was the issue of switch sounds being played from seemingly incorrect origins. At some point during the refactoring work for 1.9.7 it seems we corrected a bug in the original game, which resulted in the switch sounds appearing to originate from the location of the switch. I realised that a small refactoring to the map object model, relocating the sound origin from de::Plane to de::Surface, would allow us to address this issue with few changes to the sound system itself. Further to this, I noticed that the games were doing a fair amount of DMU negotiation for the purpose of stopping sounds from other origins in the same sector (entailing back and forth communication between the game and the engine). To resolve this I devised a method of chaining the sound origins within a sector and a method of parameterizing sound stopping, which I implemented for build 479.
I thought it best to leave the switch sound origins as-is for now, to give us some time to test out the changes to the sound stopping in general. If you encounter any new anomalies with sound stop behavior - do let us know.
In addition to the more significant changes above, I also fixed various lesser bugs/defects (e.g., game menu alignment issues in Hexen and HacX).
Next week I plan to continue work on the sound origins and other items on the 1.9.8 to-do list.
I was continuing work on the to-do list for the stable 1.9.8. Overall, preparations for 1.9.8 are progressing at a nice pace. I divided the to-do list into "showstoppers" and "lesser defects". Once we are out of showstopper issues we are technically ready to make the stable release, but I would prefer to fix the less significant issues, too. We may have to extend the candidate phase by one extra week so that the release will occur on week 19 instead of 18.
I fixed a number of minor glitches, for instance related to Windows keycode mapping, default 3D reverb volume, and the autoaim menu option. To improve mouse input smoothness on X11/Linux I applied a fix to how game window updating is done.
There were a couple of multiplayer improvements and fixes. In Hexen, one can no longer instantly change the player class when connected to a network game. Instead, changing the class via the menu or the "setclass" command will cause the class to change on the next respawn. Another change was that in Hexen co-op, items flagged for all player classes will be spawned automatically. This is because on dedicated servers players may come and go at any time; only the items for the players present at the start of the map would get their items. I also fixed a potential crash in Heretic and Hexen where using an item was causing the client to attempt accessing an invalid memory location.
I spent some time looking into why flying monsters get so easily stuck in objects, e.g., the barrels in the starting room of Heretic E1M1. After investigation I made a couple of changes: there is now a new compatibility option for Doom and Heretic that allows flying monsters to float upward over things that block their way (game-monsters-floatoverblocking, defaults to 0; also added to the menu), and flying monsters that use the MF_SKULLFLY flag to make "quick swoop" attacks will be specifically checked against getting stuck mid-attack. After these changes the Gargoyles in Heretic E1M1 should not be getting stuck any more (with or without the new cvar).
The next focus area was player controls, specifically the Sidestep/Strafe control. It turned out there was an old piece of code that was forcing the value of the control to be either -1, 0, or +1. Naturally this meant that analog controls were not being applied properly when strafing. I also fixed the issue where walking or sidestepping with the mouse would produce inconsistent speeds depending on whether moving to a negative or positive direction on the axis.
I noticed an oversight in the engine's GL initialization: non-power-of-two textures were always enabled in the engine even though the driver was not promising support for such textures. This fixed the issue of a completely white main menu background, red blocks instead of menu text, white rectangles instead of psprites, and other such serious graphical glitches.
The final item of the week was a significant forward-looking task where I ported the frontend's cfparser.py module to C++ and included it in libdeng2. This is useful because it provides the ability to read Snowberry profiles, configuration files, and addon metadata (Info) files. Particularly the Info files are important because in the future we will add support for the .box and .addon formats directly into the engine. Currently they are understood only by the frontend. However, for the time being the parser is utilized for Unix system-level configuration files. Check out the man page and wiki for details about /etc/doomsday/paths and ~/.doomsday/paths.
DaniJ:
Last week I completed work on upgrading map coordinates in the playsim and map geometry to use 64-bit, double floating-point precision. After which I then switched my attention to the 1.9.8 to-do list.
The switch to using double was relatively straight forward as algorithmically speaking, the code is largely unchanged. Using double precision is particularly important in large open maps, where there is a very real possibility of exhausting the precision of floats. (Potentially resulting in very erratic behavior). The renderer has not been similarly upgraded and is still using floats. Instead we do in-place conversions where necessary and data is uploaded to the GPU as float. Double precision is used for depth sorting of vissprites but that is all presently.
As we are rapidly approaching the planned renderer rewrite, I felt it was too much work to bother updating the existing renderer. The 2.0 renderer will of course use double precision where necessary, when the time comes.
Upon finishing the map coordinate merge I took a look at the non-functional keyboard showstopper on Windows. It turned out to be a simple case of not receiving a focus message from Qt. Manually focusing the main Doomsday window during initialization seemed to solve the problem.
The next task I decided to focus on was the issue of switch sounds being played from seemingly incorrect origins. At some point during the refactoring work for 1.9.7 it seems we corrected a bug in the original game, which resulted in the switch sounds appearing to originate from the location of the switch. I realised that a small refactoring to the map object model, relocating the sound origin from de::Plane to de::Surface, would allow us to address this issue with few changes to the sound system itself. Further to this, I noticed that the games were doing a fair amount of DMU negotiation for the purpose of stopping sounds from other origins in the same sector (entailing back and forth communication between the game and the engine). To resolve this I devised a method of chaining the sound origins within a sector and a method of parameterizing sound stopping, which I implemented for build 479.
I thought it best to leave the switch sound origins as-is for now, to give us some time to test out the changes to the sound stopping in general. If you encounter any new anomalies with sound stop behavior - do let us know.
In addition to the more significant changes above, I also fixed various lesser bugs/defects (e.g., game menu alignment issues in Hexen and HacX).
Next week I plan to continue work on the sound origins and other items on the 1.9.8 to-do list.