On Week 13/2012
skyjake:
Last week we took another significant step forward on our roadmap as I merged my Qt-based changes to the master branch. Since then I've been cleaning up various small issues caused by or brought to attention by the merge.
I added a new Mac OS X build targeting 10.6 or newer Macs with 32-bit/64-bit Intel binaries. However, I haven't yet had time to do any QA on it so some things might still be broken. Let me know if you find it malfunctioning in some way. This also means Windows is now the only remaining platform where we aren't providing 64-bit builds. This should be rectified sooner or later. Presently I haven't got a suitable machine to act as a 64-bit Windows autobuilder, but other options exist.
My plan for this week is to continue cleaning things up in the master branch and gradually shift my focus to the stable 1.9.8 to-do list, as we are getting closer to the 1.9.8 candidate phase. With my Qt work branch closed, I don't intend to add much additional new code or functionality for 1.9.8. Instead, I'll primarily focus on the bug tracker and the todo items.
DaniJ:
Last week saw the completion of the refactoring work to our BSP node builder. The BspBuilder class now constructs the final BSP objects we use in-game, rather than producing an interim representation which would then have to be translated.
This fundamental design shift mandated some significant refactorings in order to instill the concept of ownership throughout the algorithm. This work is largely complete other than a temporary kludge whereby BspBuilder modifies the GameMap on which it is working, for the purpose of linking sidedefs to half-edges (violating the ownership model). Once the half-edge data structure has been implemented this kludge can be removed.
On the whole I'd say my work for 1.9.8 is running a little behind where I'd hoped to be at this point. I had intended to have the map-hedgeds branch completed and merged to the master some time last week.
The BSP builder implementation is now at a point where it is ready to accept the half-edge data structure. This is what I intend to work on over the coming week. With luck this work will progress smoothly and it'll be ready for merging back to the master by the end of the week.
In addition to the BSP builder, I also pushed out the revised design for dengine.net There are a few issues in older web browsers (nothing critical, however). These issues will be resolved in time. I think its looking a lot better now.
Last week we took another significant step forward on our roadmap as I merged my Qt-based changes to the master branch. Since then I've been cleaning up various small issues caused by or brought to attention by the merge.
I added a new Mac OS X build targeting 10.6 or newer Macs with 32-bit/64-bit Intel binaries. However, I haven't yet had time to do any QA on it so some things might still be broken. Let me know if you find it malfunctioning in some way. This also means Windows is now the only remaining platform where we aren't providing 64-bit builds. This should be rectified sooner or later. Presently I haven't got a suitable machine to act as a 64-bit Windows autobuilder, but other options exist.
My plan for this week is to continue cleaning things up in the master branch and gradually shift my focus to the stable 1.9.8 to-do list, as we are getting closer to the 1.9.8 candidate phase. With my Qt work branch closed, I don't intend to add much additional new code or functionality for 1.9.8. Instead, I'll primarily focus on the bug tracker and the todo items.
DaniJ:
Last week saw the completion of the refactoring work to our BSP node builder. The BspBuilder class now constructs the final BSP objects we use in-game, rather than producing an interim representation which would then have to be translated.
This fundamental design shift mandated some significant refactorings in order to instill the concept of ownership throughout the algorithm. This work is largely complete other than a temporary kludge whereby BspBuilder modifies the GameMap on which it is working, for the purpose of linking sidedefs to half-edges (violating the ownership model). Once the half-edge data structure has been implemented this kludge can be removed.
On the whole I'd say my work for 1.9.8 is running a little behind where I'd hoped to be at this point. I had intended to have the map-hedgeds branch completed and merged to the master some time last week.
The BSP builder implementation is now at a point where it is ready to accept the half-edge data structure. This is what I intend to work on over the coming week. With luck this work will progress smoothly and it'll be ready for merging back to the master by the end of the week.
In addition to the BSP builder, I also pushed out the revised design for dengine.net There are a few issues in older web browsers (nothing critical, however). These issues will be resolved in time. I think its looking a lot better now.
Comments
Seems that switching to an earlier build and deleting the frontend fixed it.
It is an intentional change that attempting to click close defers the decision to the in-game quit dialog. Clicking close again while that dialog is visible will then confirm the close (an alternative method to then using the in-game quit function).
I clicked with the mouse before and the mouse disappeared but still no response, but the time before when I clicked with the mouse, it worked like you said. But I'm running it in full screen mode, not windowed mode.
In both occasions, restarting Dday fixed the issue.
It seems like since the beginning of QT merge, that turning left and right with the keyboard has become a little jerky although the over turning issue appears to have lessened a bit (even after all that excellent work on the controls for 1.9.7, something still seemed slightly amiss with over turning left and right).
- you are running Windows? (7?)
- you are using Snowberry?
- you are starting the game in fullscreen mode?
- you have mouse enabled (not using -nomouse)
- you try to press a key to bring up the menu but nothing happens? (please describe exactly what you do and what you expect to happen)
There have been a couple of instances of non-responsive keyboard in Linux, but it seems to occur rarely and randomly.
Currently vsync and FSAA are always forced on, that might lead to occasional performance problems (particularly with large display resolutions).
Do you mean "jerky" during the turning movement, or in the beginning of the movement?
What do you mean by "over turning"?
I have AA off via the command line because my video card can't handle it with dynamic lights; immense slowdown occurs.
I tested the start area of E3M1 of Ultimate Doom in 458 and 452. In 458, it felt like everything was jerking a bit, particularly when I was turning left and right. The jerking seemed consistent (in timing and amount). My FPS, according to the meter, didn't change.
On the overturning front; I often find myself turning a bit further than expected relative to 1.8.6. It's as if the controls are more sensitive rather than anything being wrong with player movement; I find it allot more difficult to make the tiniest left/right movement in 1.9.7 possible for instance.
EDIT: I just tried turning dlights on and off via the control panel and when I turned them back on, I started getting considerable slowdown identical to if I had AA on (I have it off via the command line). Restarting Dday doesn't appear to have fixed it.
EDIT2: The issue I and Gary mentioned above with non-responding controls is related to when you click the mouse on the Dday window (i.e to give it focus); if you only do it once the title screen of the loaded game is reached, you have full control.
But if you click the Dday window during engine start up, you get a vareity of controls not work. The controls that don't work seem to depend on how early in startup you click the mouse.
I use Windows and run in full screen.
As I said, presently FSAA and vsync are always on, no matter what you set on the command line. Only GL driver settings will affect it.
That's a good lead to check out, thanks.
It's still there even with 0. It seems to be intial and final camera movement (i.e when you first press the key and right after you take you finger off the key).
The jerking is also still there.
The fps drops considerably once I turn dlights off and back on via the control panel.
To elaborate a bit more on this, the ability to activate the console seems to randomly disappear in game; one has to restart Dday to get it back. Might be related to either alt-tabbing and/or the intermission screen. Of course the former requires one to refocus the mouse again...
Somewhat OT, I like the fact that Dday now auto pauses/un-pauses when you alt tab. But it's a little bothersome that manual pauses are also undone when you alt-tab back (i.e. if the game was already paused by the player before you alt-tabbed away from the Dday window).
All of the above. And like Vermil, sometimes the console key doesn't do anything. I also notice something about turning that doesn't feel the same, but I thought it was because my joystick's axis was not popping back into the neutral position immediately. As for pausing; I never pause; I just hit Esc for the menu since it does the same.
And this is when I click upon startup. Also, clicking upon startup doesn't do anything most of the time when it comes to the keyboard working. The keyboard isn't doing anthing in the menu no matter what button I push. Alright, I won't upgrade to any future unstable builds until this is resolved. Now I have to delete the frontend again and revert back to a previous build.