Doomsday 1.9.7 Released

edited 2012 May 6 in News
We are happy to announce the release of the stable version 1.9.7 (build 425).

The work to make this happen started a year ago when we decided to end the unproductive Beta development phase and switch to a more iterative development model. We've made a ton of progress in the last 12 months, finishing up loose ends and cleaning up after several refactorings. Even though there's still more work to do and bugs to squash (as always), the engine is today in a better shape than ever before. Our momentum is good and the future is looking bright.

We'd like to say a big thank you to all the people who have helped with testing the unstable and candidate builds! Without you the quality of this release would be significantly poorer.
  • See the release notes for more information about what has changed since Beta6.9. Also note the Upgrading instructions if you haven't installed a version of Doomsday recently.
  • When you encounter bugs please use the SF.net Bug Tracker.
  • Downloads and other links are available on the dengine.net front page.
- Deng Team
«1

Comments

  • edited 2012 Mar 1
    Congratulations on reaching this milestone toward Dday2.

    EDIT: Moving my post from the now defunct candidate thread.

    While 1.9.7 is a significant milestone on the way to Dday 2.0 and a big improvement over Beta 6.9, there are a couple of bugs/issues I think are noticible from a gameplay perspective, that I'm suprised wern't fixed before declaring a 'stable' release, even if they will take ages to fix.

    But the bi-weekly builds are set to continue, so as soon as they are fixed, we will probably be able to test drive them.
  • Great news, and good luck (pray to Armok for more fortunate-non-bugginess)
  • I wish this release wasn't so hasty... The game still takes 45 seconds to startup when I use the JDRP (compared to 5 seconds in build 364), and Daniel Norton's detail textures do not work still... I spent a lot of time modifying the .ded files in my version of his detail pack so that Final Doom textures were supported, and now they are all broken. :(

    Edit: Also, the Final Doom bugs I mentioned over in the candidate testing thread still exist. All the bridges that should be invisible in Final Doom (like in map03) display an HOM at the bottom and a texture at the top. The bridge in the screenshot below is found at these coordinates:
    MAP [MAP03]  X:3665.86  Y:-1890.42  Z:128
    MAP [MAP03]  X:3665.86  Y:-1890.42  Z:128
    Subsector 131 / Sector 59:
      FloorZ:128 Material:Flats:rrock12
      CeilingZ:256 Material:Flats:rrock12
    

    http://i6.photobucket.com/albums/y226/l ... bridge.jpg

    Also, the water in TNT map 31 still has the HOM around the edges:
    http://i6.photobucket.com/albums/y226/l ... ntbug1.jpg

    In my opinion, build 364 is still superior to this release.
  • edited 2012 Mar 1
    There doesn't seem to be a makefile which works on linux or bsd - is there a documented method (which I haven't found yet) that could allow me to build it on something other than Debian perhaps?

    Nevermind, sorry, forgot you moved to qmake - had to install some libraries and it's building away, thanks for the new version!
  • Detail textures work if they're external files.

    It takes me about 23 seconds to start the engine and the first level with models, about 9 seconds without. Then for comparison.. Doom3 takes about 40 seconds to start the engine and the first level, Quake2 takes about 9 seconds to do the same.

    The levels load much faster than before.. averagely 1 second.
  • About 10 seconds for me to start the engine with addons. To start a map in Armadosia, which has complex maps, about 4 seconds. Not bad. Since people are using the same build and saying it takes longer to load, it probably depends on the hardware they have. I doubt configuration alone or even an extra addon would add 35 more seconds to the loading time. I'm using all models, the latest hi-res textures, the latest UI interface, and Sambo's soundpack, which is pretty much all the big addons that aren't related to music. I've turned the music all the way down lately, but I do have music packs.

    Also, I downloaded this build (425) this morning. I didn't expect it to be posted later today as a stable release in the news section.

    Also, Lightning Hunter, that is the same HOM visual bug I was talking about with the fluid in the corridors and the HOM where the floor and the wall merge in the corner. Don't worry; I have the same issues. Sooner or later, it will probably get fixed.

    I haven't tried 425 yet, but I did play with 423. I'm assuming there isn't any real difference between the two, especially after reading the list of fixes under the build description - mostly homepage which I believe has nothing to do with the actual build and game, but instead has to do with the dengine.net website layout or something). Whatever homepage means.

    And yes, flying monsters and cacos still get stuck, but I do remember the devs saying that it is a complicated bug and more fixes are needed in the future to prevent it.

    As for performance; that is separate from loading times. We all could benefit from modifications to the engine to increase performance. I wonder if 1.9.8 will have any performance increases. I have to keep dynamic lights off in most maps in Armadosia or the framerate will become unacceptable and maybe around 10 fps, which is utterly unacceptable.
  • JCA wrote:
    Detail textures work if they're external files.

    It takes me about 23 seconds to start the engine and the first level with models, about 9 seconds without. Then for comparison.. Doom3 takes about 40 seconds to start the engine and the first level, Quake2 takes about 9 seconds to do the same.

    The levels load much faster than before.. averagely 1 second.

    Yes, but how fast did build 364 load for you? For me, build 364 started up in 5 seconds, with ALL addons selected. The new build takes about 42 seconds. That's longer than it takes Doom3 for me. Very annoying.
    gary wrote:
    Since people are using the same build and saying it takes longer to load, it probably depends on the hardware they have.

    I'm not comparing my startup time to other people with different hardware. I'm comparing the load time of build 425 to build 364. A difference of nearly 40 seconds is quite large. I don't care what kind of hardware we have - I'm just comparing the different builds.
  • But for some reason, my loading speed hasn't slowed down nearly as much as some people. It is slower and gets a little annoying though. Also, you should care about what hardware you got since it might help a lot. Loading time is relative between users seemingly because of hardware differences, and therefore makes waiting much shorter and more tolerable depending on the hardware.

    I'm not arguing that it is slower, but we already been through that with the devs a few days ago and I asked them the same questions on why it is slower than 364. They seem to not realize that it has slowed down quite a bit since 364. There is surely something they can do to fix this problem since it used to be faster, and should do soon. We would all benefit, especially those with much longer loading times than myself.

    I can imagine how annoyed you must be having to wait 45 seconds, LH. That must really suck. Hopefully it doesn't take long for you to load saved games or reload a map after dying because that would be a lot of long pauses in the game that to me would feel almost intolerable.
  • There does seem to be some issue with add-on loading in 1.9.7 (and the last bunch of unstable builds).

    From my own experience and what I've read regarding loading issues in 1.9.7, I'm wondering if it's related to loading a bunch of files with similar names and that it can produce a variety of issues, some fatal (bizarre crash), some non-fatal but bothersome (notably longer loading); something I've put to DaniJ:

    [*]The JDRP contains loads of pk3's named: JDRP-xxxxx: I haven't tested this one, but apparently takes about 30-40 seconds to load.
    [*]The almost dozen deds from my own Corr7TC, all named Corr7xxxx.ded; take 40 seconds to load in 1.9.7 and bizarely cause the Hud options menu to crash when accessed.
    [*]A group of five of my own pwads (all named TempleX.wad, where X is a number), which include no replacement menu graphics: when the are loaded in reverse numerical order, they also cause the Hud options menu to crash when accessed.
  • Vermil wrote:
    There does seem to be some issue with add-on loading in 1.9.7 (and the last bunch of unstable builds).

    From my own experience and what I've read regarding loading issues in 1.9.7, I'm wondering if it's related to loading a bunch of files with similar names...
    This would suggest a problem with the file name hashing algorithm. I'll run some tests...
  • I wish this release wasn't so hasty...
    Vermil wrote:
    (...) there are a couple of bugs/issues I think are noticible from a gameplay perspective, that I'm suprised wern't fixed before declaring a 'stable' release, even if they will take ages to fix.
    I know there are bugs and performance problems left. It was our decision that the codebase has reached a level of quality that surpasses the previous stable version 1.8.6 by such a magnitude that updating the stable version makes sense. I wish we had the ability to produce bugfree code; sadly that is an impossibility with a codebase as complex and unexpectedly interwoven as ours.

    The fundamental change in our development process is that releases are more timed-based now than before. If something doesn't make it to a release (unstable or stable), then it doesn't. If we hadn't stopped Candidate mode now we would've continued focusing on the million tiny (and big) bugfixes for weeks to come, which would've called for canceling the Candidate phase and switching back to Unstable without making a stable release. Instead, I felt it was more productive to start the stable release cycle and retain our forward momentum.

    Fixing the bugs and performance issues is near the top our priority list.

    As always, you are welcome to use an older build if the latest stable or unstable ones don't suit your needs.
  • In addition to skyjake's comments I want to point out that 1.9.7 is in fact the first stable release for the Mac OS and Unix platforms. While we appreciate that a couple of the regressions on the Windows platform are important (primarily initial startup performance) you have to balance these against the much more significant issue of users not even being able to run the engine. It did not seem fair that those users should be denied a stable release while we address relatively minor regressions on the Windows platform.

    With 1.9.7 we have now for the first time in Doomsday's history reached a point of near-complete feature parity on all supported platforms (there are a few notable exceptions, e.g., no vsync by default on Unix).
  • Don't worry, I do understand and I respect all the hard work you guys put in :)
  • Good job guys - pleasure to play Doom, Hexen et al on your engine!
  • if any dev reads this then the co-op doom server is having a problem that requires a mp server restart witch this problem has happened before and i did report about it before and that was the solution Dani did and it worked after that.
  • Gordon wrote:
    if any dev reads this then the co-op doom server is having a problem that requires a mp server restart witch this problem has happened before and i did report about it before and that was the solution Dani did and it worked after that.
    The deng team MP servers are currently being rebuilt and restarted automatically Monday and Friday a short while after each unstable release.
  • Idea: Perhaps the host script can send a warning message to any players currently in the servers? (It has admin rights after all)
  • that would be best but if what you say is true then why would it happen on a non build day? i mean the errors aka player not able to do much except kill and open doors
  • What are the top priorities of Doomsday production at the moment? I was just thinking that it would be nice if the slowdown at startup was worked on first, so that we can have a true stable version to use. 1.9.7 seems stable in almost every way, except for the slow startup time. I'm just worried that the code will be "unstabilized" for 1.9.8 when more features are added (similar to what happened when ringzero was merged), and that we will have to wait a very long time to see another stable build with fast loading times. If the current version is kept stable and the loading time is optimized, then we can at least use such a build for a long time to come, until another stable version is out. At the moment I still use build 364 due to the load times. If it wasn't for this, I'd use the new version in a flash.
  • Good job!
    Best port for Doom 1 2 / Heretic / Hexen I ever played
    I wish you fast bugfixing
  • What are the top priorities of Doomsday production at the moment?
    We're back to Unstable, so we're working mostly on the roadmap items and overall refactoring. As we get closer to the next Candidate phase we will start putting more attention on bug fixing again (stuff in the Bug Tracker).
    1.9.7 seems stable in almost every way, except for the slow startup time.
    Well, we have a different definition of "stable". When we say "stable", it means "unchanging". You're probably looking for "bug-free and fully optimized", which is more of a long term goal that we're gradually moving towards with each stable release.
    I'm just worried that the code will be "unstabilized" for 1.9.8 when more features are added (similar to what happened when ringzero was merged)
    That will not happen. Merging of the ringzero branch was a special circumstance that was necessary because we were undergoing a change in our development practices and were forced to do a "big bang" merge. Work branches will not be allowed to grow that large any more, making things more manageable. If the master regresses again in the future, we will simply rewind the changes back to a good point and keep working on the problem in a separate work branch. That's why the work branches exist: to keep the master always in top condition.
  • Great job, guys. deng is nice piece that allows me to enjoy hexen/heretic/doom on a new level. keep up the good work
  • Seems with the latest build, some of the sound effects are getting cut short, like for example the sound with the cyberdemon walking. Doesn't matter if I change sound settings in the console or use FMOD Ex. Ok. it is noticeable with most sounds, especially the chaingun. What did you guys change? This never happen before. Maybe the Hexen sound change affected Doom.
  • In the original games, only one sound could come from a source (i.e. a individual badguy) at once.

    Dday previously, didn't respect this behaviour. It led to some humorous cases like Heretic's Disciple continuing to talk to you from beyond the grave.

    Yes ID also made some sounds long enough that they would always be cut off, in the original game.

    I imagine there is a console cvar to control this though if you don't like it?

    Obviously, I would ideally love to have a def level flag to control it on a per sound basis (I am aware of the ‘group’ option, but effects the sound across all sources), but that's a typical user wanting their cake and to eat it.

    I haven't downloaded the newest build to personally decide whether I like it better.
  • Well, I'm using the high quality pack (Sambo) but it never did this before, so it has to be the build's fault.
  • It is Dday...

    It was a new feature added in the latest build (430), in order to be more faithful to the original game. As I stated above.

    You can see it right at the bottom of the changelog: http://dengine.net/build430
  • Having downloaded the new build; I'm quite liking the change; fireballs sound so much better having their launch sound cut out when they hit something.

    However, there is a mistake in the change; the Cyber Demon and Spider Demons alert sounds (the two I can remember from memory), where exempt from being cut off in the original game. They aren't in Dday.
  • Vermil wrote:
    I imagine there is a console cvar to control this though if you don't like it?
    Currently there is no cvar for this, but I can add one later.
    Obviously, I would ideally love to have a def level flag to control it on a per sound basis (I am aware of the ‘group’ option, but effects the sound across all sources), but that's a typical user wanting their cake and to eat it.
    There is the sf_dontstop flag for Sound defs. That should prevent the sound from being cut off. We could add it to the more noticeable cases like the Cyberdemon steps.
  • edited 2012 Mar 7
    Vermil wrote:
    Having downloaded the new build; I'm quite liking the change; fireballs sound so much better having their launch sound cut out when they hit something.

    I that sarcasm or a joke or are you serious? I don't think it is good at all. I thought the goal is to improve sound quality, not downgrade audio to mono. It behaves almost like one channel. Also, it makes the spider mastermind's pain sound non-existant. Fire a chaingun if you want to listen to how bad it sounds. Also other sound oddities are present. It ca't be a new feature since it isn't an improvement. Sounds like a bug. Features upgrade, not downgrade. Darn, I hope you aren't being serious.

    Edit: Yep, looks like you werent kidding.
  • There are cases where one sound per origin produces good results and there may well be other cases where it doesn't.

    Given that this is quite a fundamental change, maybe a separate thread to ask the users which sounds they think should/shouldn't be affected?
Sign In or Register to comment.