Beta 6.6 Ahoy

edited 2009 Sep 1 in Developers
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Beta 6, Engine, Games, Releases.</i>

We are nearing the deadline for <a href="http://dengine.net/dew/index.php?title=Doomsday_version_1.9.0-beta6.6">Beta 6.6</a>, but it seems everyone is quite busy with other stuff at the moment. There's still a week to go, and I would very much like to at least sort out the <a href="http://sourceforge.net/tracker/?func=detail&aid=2830442&group_id=74815&atid=542099">-file option issue</a> (which can't be that big of a mystery to solve). However, I have no idea whether I'll have time to do so. Probably not before the weekend in any case, but let's see...

Comments

  • Sadly my free time continues to be consumed by Real Life commitments presently. I do hope this situation changes real soon as I'm not happy about me missing all the fun happening in the new-order-phase4 branch in particular.

    I'm glad to hear that the -file option issue has been resolved, I knew it would be something trivial like that (however I'm somewhat perplexed as to how I could have gotten those logical tests inverted in the first place).

    As for the <a href="http://dengine.net/dew/index.php?title=Doomsday_version_1.9.0-beta6.6&quot; rel="nofollow">other short-listed issues</a> the most important is arguably the problem of <a href="http://sourceforge.net/tracker/?func=detail&aid=2837486&group_id=74815&atid=542099&quot; rel="nofollow">"Couldn't open dd-buffered-song for writing"</a>. Although I've not had much time for deng lately I have had time to look into this problem a bit (though I don't know whether I'll have the time to resolve the issue myself at present).

    Looking at the logic of Mus_Start() it appears we are already explicitly calling Mus_Stop() which *should* mean that SDL_mixer is sent the Mix_HaltMusic() instruction from our own DS_SDLMixer_Music_Stop() before we attempt to write to the buffered music track files.

    However this is not correct according to the docs for SDL_mixer:

    Mix_HaltMusic() does not in fact release any acquired handle(s) to the music source if it originates from a file. In order to ensure the file is released, Mix_FreeMusic() must be used (or initiate playback from another source).

    This would seem to substantiate the file lock explanation for this issue, as suggested <a href="http://dengine.net/forums/viewtopic.php?f=7&t=97#p686&quot; rel="nofollow">here</a>.

    Changing DS_SDLMixer_Music_Stop() adding a call to Mix_FreeMusic() is likely not sufficient unfortunately as our iMusic interface specifies that after a "Stop", music playback can be resumed without needing to go through loading the file again.

    This means than we need to either revise the iMusic interface itself (not desirable at this time), or we need to revise how we interface with SDL_mixer (track the file currently being played within DS_SDLMixer_Music (note that the Mix_Music struct should not be used!) so that we can then release and re-load the music source file as/when needed).
  • I was thinking that maybe we could set up a rotation of, say, 2 temporary files (<tt>dd-buffered-song0</tt> and <tt>dd-buffered-song1</tt>). By the time a file is reused, it's sure to have already been released.
  • That is of course another option. The benefit of such an approach is that it would be implemented on the engine side of the <tt>iMusic</tt> interface and thus all music playback plugins are absolved of handling the same case.

    I think the rotation should be implemented so that the only time two files exist simultaneously is during <tt>Mus_Start()</tt> (as soon as music playback begins, delete the other temporary file).

    <strong>EDIT</strong>: Perhaps in the 2.0 architecture we should consider implementing a more universal resource caching schema (which could also be used for maps) so that we avoid repeated, JIT transforms of data into our native formats.
  • It looks like we are set for a release tomorrow? Or are there some fixes that warrant postponing the release a day or two?
  • There are a couple of things that I'd like to address for this release but they aren't worth delaying the release for.
  • Let's do the release on schedule then.

    P.S. They are switching internet connection providers today in my building, so I may or may not have a very fast connection today (or in the near future, if they mess it up somehow). Consequently, I may not be able to upload the release today. Let's see how it goes...

    <b>EDIT:</b> I'm still connecting through my mobile only, so it seems that postponing the release at least to tomorrow is not a bad idea. So there's some extra time for small fixes, if any suitable ones are waiting.
  • OK.

    I'll commit the few small fixes I had accumulated in that case.
  • Now my connection is back online so let's do the release tonight.
Sign In or Register to comment.