1.9.0-beta6.3 Released

DaniJDaniJ
edited 2009 Jun 7 in Developers
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Beta 6, Engine, Games, Launchers, Mac OS X, Releases, SourceForge, Version 1.9, Windows.</i>

Version 1.9.0-beta6.3 has been released and can be <a href="http://sourceforge.net/project/platformdownload.php?group_id=74815">downloaded from SourceForge.net</a>.

<a href="http://dengine.net/dew/index.php?title=Doomsday_version_1.9.0-beta6.3">Release notes</a> are in the wiki as usual.

Comments

  • skyjakeskyjake
    I'll tag it and bag it tonight (the source package, that is).
  • DaniJDaniJ
    Later on tonight I plan to repack and update the Windows release package on SourceForge.
  • DaniJDaniJ
    Currently, I am doing some QA on the head of the 1.9.0-beta6 branch in preparation for the re-release. So far, its looking good.

    <strong>EDIT</strong>: Something strange going on right now. Debug build, everything works fine, all games. However with a release build, the only game that works is DOOM2.

    <strong>EDIT2</strong>: Its looking like heap corruption. Most likely a rogue Z_Malloc/free pairing has crept in somewhere.
  • skyjakeskyjake
    I'll hold off the tagging until we've resolved the issues and updated the release packages.

    Maybe it's a buffer overrun somewhere? The memory zone isn't protected against writing in any way...
  • DaniJDaniJ
    I've tracked down the cause of the corruption. Its not a buffer overrun per-say. Basically its due to resizing a zone-allocated memory block using the standard allocation routines.

    Hopefully it shouldn't take me too long to resolve.
  • DaniJDaniJ
    How is the beta6 branch looking now, skyjake? Are we ready to do the re-release?
  • skyjakeskyjake
    After the fixes I did today it's looking pretty OK. I'll do a few more test runs...

    <b>EDIT:</b> Ran into problems: after changing the resolution in the control panel, most of the control panel UI textures were missing. Trying a texreset lead to a crash. Investigating...

    <b>EDIT2:</b> Fixed the crash (OpenGL accessed in the wrong thread). Any idea on why the UI textures go missing? Note that I'm using windowed mode.
  • DaniJDaniJ
    Interesting. I'm not experiencing that problem, a texreset is working fine for me.

    I did notice a small usability issue with the control panel in that any slider which adjusts the value of a cvar with a callback is updated every time the slider position changes (for example, texture quality slider). A better approach would be to take a copy of the cvar's value when the slider gains focus, update the copy while focussed and then set the cvar when the slider then loses focus.
  • skyjakeskyjake
    Likely it went unnoticed by the Windows OpenGL driver (or it's thread safe). Can you reproduce that UI textures missing issue?
  • DaniJDaniJ
    Sorry, I was actually referring to the missing UI textures issue.

    <strong>EDIT</strong>: I've not yet wrapped the UI textures with the gltexture interface so provided that <tt>UI_LoadTextures</tt> is still being called <em>post-texreset</em>, they should still be working as before. Perhaps we are missing a call to <tt>UI_ClearTextures</tt>?

    <strong>EDIT2</strong>: I remember fixing a problem with the deferred upload. The issue was that we were trying to use texture names after a GL reset which had been reserved before the reset. Perhaps something similar is going on with the UI texture upload?

    <strong>EDIT3</strong>: I've just tried a resolution change in windowed mode via the control panel and I too am getting the missing UI textures problem. The problem is also occuring when using the <tt>setres</tt> console command. The problem seems to be that <tt>UI_LoadTextures</tt> is simply not being called post GL reset.
  • skyjakeskyjake
    Does rev 6648 fix it?
  • DaniJDaniJ
    Well, not for me because on Windows we don't use the SDL window management :-) Copying the same over to the WinAPI window manager does fix the problem.

    So clearly, whatever should be calling <tt>UI_LoadTextures</tt> post reset is not being reached, which could mean that there is a larger issue here.
  • skyjakeskyjake
    I'm not seeing other showstoppers at this time, so I'm good to go for a repackaging.

    I'm thinking we should keep the version number at Beta6.3, just note that it's the June 7 build, not May 31.
  • DaniJDaniJ
    What should we do about the <tt>UI_LoadTextures</tt> issue? Leave it as is for now (I'll commit the same fix but for the WinAPI window manager) or look to see where the GL reset is going wrong prior to release?
  • skyjakeskyjake
    It doesn't seem too critical, we can leave the proper fix until 6.4 and use the workaround for now. It would be good to have a fully functional 6.3 out there.
  • DaniJDaniJ
    Ok. I'll begin repackaging.
  • skyjakeskyjake
    Uploading the OS X package...

    <b>EDIT:</b> Done. Release date adjusted to June 7.
  • DaniJDaniJ
    Windows package uploaded and download link at SourceForge updated.

    <strong>EDIT</strong>: I guess all that remains to be done is to generate a project news item over at SourceForge and to post an update at the forums. I'll go do the forum post.
  • skyjakeskyjake
    SF.net news item posted.

    <b>EDIT:</b> Also, source package uploaded.
Sign In or Register to comment.

© Vanilla Keystone Theme 2024