On Week 14/2012

edited 2012 Apr 17 in Developers
skyjake:

I spent last week on miscellaneous cleanup work after the big Qt merge. Notable fixes include a crash during startup on Mac OS X 10.4, grabbing mouse and keyboard input at startup, and the FPS counter. I also tied up some loose ends with the refactoring: Qt is now used for threads and timing, too -- SDL is all but ready to be dropped completely.

Thanks to the flexibility provided by the new underlying platform I implemented a few new useful features:
  • ”releasemouse” command: relinquishes control of the mouse pointer so one can access the rest of the desktop or manipulate the game window.
  • ”vid-fsaa” variable: enable or disable GL multisampling at runtime.
  • ”vid-vsync” variable: enable or disable vsync at runtime.
The default binding for F11 was changed: instead of cycling through software gamma correction levels, it will toggle fullscreen mode. Alt-F11 releases the mouse pointer.

This week I will continue the cleanup with a few minor details and then focus on the stable 1.9.8 to-do items.

DaniJ:

Last week didn't quite go to plan for me. I ended up spending a large amount of my Deng development time on bug hunting in the new framework, rather than developing the BSP node builder as I intended to. Since the Qt merge there have been a few minor regressions which have impacted on my own development work, however I'm sure these will be ironed out over the coming week (we've got some solid leads now).

As open development time is beginning to run out on 1.9.8 I have decided to postpone the half-edge data structure integration until a following release. The remaining time will be spent on upping the map coordinate space precision to double floating point and other ancilary improvements to map data loading/pre-processing.

Comments

  • The unresponsive keyboard problem is still in existance (it is still on the to-do list of course). I saved myself some time by making a copy of the good functioning frontend and then deleting and replacing the altered bad one with the good older one (so if something went wrong and the keyboad bug wasn't fixed, I wouldn't have to go through the time of reimplementing my custom settings) because for some reason when using a newer build with the problem and then reverting to an older build without the problem, the problem continued occuring when using the older build because it spread to the frontend (like the previous bug with the cvar causing loading to freeze a couple weeks ago and it writing a corrupt player config file as a result). Deleting the Frontend is a cure to the damage done by the newer build.

    How is it that the build is able to alter the frontend so that the bug carries over to the frontend? What file in the frontend is being changed? It isn't the player config file. It is like the faulty build is acting like a virus by changing the frontend (spreading) in a negative way.

    Also, normally when installing a new build, I leave the frontend alone. When uninstalling an older build and replacing it with a newer build, does the correct way of uninstalling involve deleting the frontend every time, or am I ok leaving the frontend alone each time I upgrade like I usually do?
  • gary wrote:
    How is it that the build is able to alter the frontend so that the bug carries over to the frontend? What file in the frontend is being changed? It isn't the player config file. It is like the faulty build is acting like a virus by changing the frontend (spreading) in a negative way.
    I doubt the frontend has anything to do with this; most likely the .cfg files stored under the runtime/configs folder are to blame. I noticed earlier that if the startup failed due to an error (like "FI_Responder: Not initialized yet!"), it would cause configs/player/bindings.cfg to be overwritten with one that contained no bindings. This occurred because the user's bindings hadn't yet been read from the .cfg file. I've added this issue to the todo list.
    Also, normally when installing a new build, I leave the frontend alone. When uninstalling an older build and replacing it with a newer build, does the correct way of uninstalling involve deleting the frontend every time, or am I ok leaving the frontend alone each time I upgrade like I usually do?
    Almost always you can and indeed should leave the frontend folder untouched when upgrading; it contains your personalized settings like the aforementioned bindings, savegames, and other config options.
  • I fiddled around a little with the menu with the latest build and got more knowledge of what is going on when none of the keyboard keys are working. I found out that only the two mouse buttons are working most of the time upon startup (the left button selects an item in the menu while the right mouse button goes back, and that is all I can do).

    I hope this info is useful somehow to what the problem is because maybe someone knows what I am doing wrong, if anything. It seems like it is in mouse mode instead of keyboard mode, assuming there are toggled modes between the two. Previous comments about the menu indicate that holding a button or something on the mouse shuts off something like a mouse mode. I forgot exactly what it was that was said. How to switch the modes isn't clear to me, but sometimes pressing a key on the keyboard will cause the buttons to work again. Not sure how though.
  • I'm currently looking into the cause of this issue but in the mean time, Windows users may simply alt+tab out and then back to Doomsday and the keyboard will work as expected.
  • No problem now. I'm happy that now I can stick with the latest build and it works after following your advice.
  • I'm running Linux (Debian Wheezy with KDE) and mouse-look is very jerky. Moving the mouse in a smooth motion causes my view to rotate non-smoothly. I will turn like 20-30 degrees suddenly, hold, and turn some large amount suddenly again. You're probably already aware of this, and it's probably a consequence of the new input system through Qt still being under development, but just in case you're not, this issue exists on two computers I own, even with fresh installations.
  • Yeah we're aware of the X11 mouse problem. However, I need to figure out where I can run Linux natively before I can fix this...
  • Seems the latest build fixed the keyboard problem, as anticipated by a dev when looking at the to-do list (#472). Confirmation has been achieved.

    However, the console button is still broken.
  • commit 444257d19da4df7d855d5c87fd5dbee6c39143c8 seems to have fixed the x11 mouse input jitter
Sign In or Register to comment.