Doomsday 1.9.7 Released
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.
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.
Comments
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.
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:
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.
Nevermind, sorry, forgot you moved to qmake - had to install some libraries and it's building away, thanks for the new version!
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.
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.
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.
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.
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.
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.
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.
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).
Best port for Doom 1 2 / Heretic / Hexen I ever played
I wish you fast bugfixing
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.
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.
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.
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
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.
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.
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.
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?