Should We Just Throw Beta6.0 Out There?

skyjake

<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Beta 6, Engine, Games, Mac OS X, Releases, Unix/Linux, Version 1.9, Windows.</i>

I was thinking that unless there is something utterly broken (that we know of) at the moment, we should just package the current code and call it Beta6.0. We can then separate Beta6 into its own branch and release fixes (6.1, 6.2, etc.) from there as need be, to fix the critical issues that people may encounter. These bugfix releases could be made as often as neccessary, when suitable fixes have been made.

I have everything ready for making the OS X release package. How about the win32 one?

I can also zip up the sources for the source code package.

DaniJ

Other than the NPOT texture issues (which could, at a push, be disabled by default for this release) I'm quite happy about calling current svn head Beta6.0

I'll have a go at setting up a win32 release environment tonight.

skyjake

I say we just disable the NPOT textures by default for now and take some time to investigate what is causing it later on. I believe the only benefit of the NPOT textures is saving some texture memory? As such it doesn't seem hugely important on the priority list.

DaniJ

The main benefit is that it improves the appearance of the various game UI displays noticeably, as we don't have to resize all those odd sized textures and as a consequence; introduce "blurring" artefacts.

skyjake

The blurring issue could also be fixed by not scaling the image to the POT dimensions in the case of non-repeating (i.e., tiled) textures (which, I think, many UI textures are).

I've forgotten how the system goes: are we scaling all textures regardless of whether they are repeating or not?

DaniJ

Currently we will always scale all textures to POT dimensions regardless. There are a few notable exceptions which use a slightly different approach (mainly "raw" textures used for the Heretic/Hexen title pics and finales).

Certainly, simply blitting them to a POT canvas and then adjusting the texture coordinates would achieve the same end for the non-repeating textures.

I had been thinking about implementing texture atlases (at some point) for use here but made the NPOT changes as an interim, quick-fix solution for the UI.

skyjake

Will you also be changing the NPOT to disabled by default?

<strong>EDIT:</strong> Never mind, I'll commit it now.

MasterPhW

Can't wait to see and test it!
The bugfix release idea is great, we'll see how it turns out.

rbaliko

First of all I have to apologize.

I'm relatively new to all of this. I used to play doom all the time. Then I discovered Doom Engine 2 weeks ago.

I apologize because I have 2 questions to ask. I tried to do research before I asked these questions, so forgive me if you already answered them.

1. Is the "segmentation violation" problem fixed?
2. Will 1.9.0-beta6 run on Vista?

I know you all are busy, so these will be the only 2 questions I ask.

skyjake

Currently we seem to be having a problem with the Doomsday UI fonts going all missing or getting mixed up when continuously opening and closing the control panel. I'll investigate further.

<strong>EDIT:</strong> Fixed it. However, I did notice that the <code>doomfont</code> command is broken (the resulting font looks pretty much blank). Not an issue of the highest importance, though...

DaniJ

<blockquote>Will 1.9.0-beta6 run on Vista?</blockquote>
Doomsday 1.9.0-beta6 does indeed run under Vista, both 32bit and 64bit variants. Note though that currently we only build 32bit binaries but this will (hopefully) change some time in the not-to-distant future.
<blockquote>Currently we seem to be having a problem with the Doomsday UI fonts going all missing or getting mixed up when continuously opening and closing the control panel. I?ll investigate further.</blockquote>Hmm interesting. Once I finish updating the win32 release script I'll check this out and let you know if its system-specific.

skyjake

<blockquote>Once I finish updating the win32 release script I?ll check this out and let you know if its system-specific.</blockquote> See if my committed fixes work, I would suspect the issue was platform independent.

DaniJ

Seems to be working fine here so I assume you fixed it

I've now got Doomsday and all plugins building fine, in Release mode and am now about to look at building Snowberry, as it is currently failing for some reason.

<strong>EDIT</strong>: Doh! It would help if I had the wxWidgets setup on my dev system.

DaniJ

Quick question, should I be using the Unicode or the ANSI version of wxPython with Snowberry?

<strong>EDIT</strong>: Never mind, clearly its the ANSI package we need.

Here is where I'm at currently with building Snowberry: <a href="http://rafb.net/p/sd4vDv69.html&quot; ref="nofollow" rel="nofollow">buildlog</a>

rbaliko

Thank you for answering one of my questions.

I believe you skipped over the first question about whether the segmentation violation problem (that occurs when jdoom addons are loaded) is now fixed.

DaniJ

This is not the place to be doing technical support. Please start a new thread at our user forum, here : http://forums.newdoom.com/forumdisplay.php?f=80

skyjake

<blockquote>unless there is something utterly broken</blockquote> ...which reminds me that clientside multiplayer is probably broken at the moment. We should check if there's anything that can be fixed easily, before we begin the larger changes for Beta 7.

DaniJ

Speaking of which, the following comes to mind:

<a href="http://sourceforge.net/tracker2/?func=detail&aid=2582804&group_id=74815&atid=542099&quot; rel="nofollow">Bug 2582804</a>
<a href="http://sourceforge.net/tracker2/?func=detail&aid=2284029&group_id=74815&atid=542099&quot; rel="nofollow">Bug 2284029</a>

I think that at least bug #2582804 should be fixed before we release beta6. The issues in #2284029 could probably wait until we begin beta7 as (like you say) there are other problems in multiplayer right now which make it unplayable.

skyjake

Also, a fatal error in jHexen:

<a href="http://sourceforge.net/tracker2/?func=detail&aid=2620256&group_id=74815&atid=542099&quot; rel="nofollow">Bug 2620256</a>

DaniJ

I'm still working on the Windows release script (currently updating our Inno Setup installer) but I'll look into that DDVT type issue in jHexen shortly, its most likely a simple mix up on the caller's part.

DaniJ

I think I've just about finished updating the Windows release script and I've now got a shiny new deng-1.9.0-beta6-setup.exe in my packages directory.

Tomorrow I'll do some QA but right now, I think we are good to go once we fix up the aforementioned bugs.

DaniJ

Ok, both the fatal error in jHexen and the fakeradio plane shadows vs fog bugs should be fixed in svn.

I've just begun doing QA on the Windows release and have ran into an immediate issue:

Currently, Snowberry must be run with elevated administrator privileges due to it writing to the install directory (typically <i>c:\Program Files</i>), for the user profiles, uninstalled addons etc, etc. These will need to be moved to more suitable locations as we shouldn't require admin privileges post install.

skyjake

<blockquote>Currently, Snowberry must be run with elevated administrator privileges due to it writing to the install directory (typically c:\Program Files), for the user profiles, uninstalled addons etc, etc. </blockquote> We could just revert to the original behavior of using the user home directory also on Windows (like it is on *nix). On Windows the default is to use the app directory instead of the home directory.

Check out <code>isHomeless()</code> in paths.py.

DaniJ

Ideally Snowberry should use the home directory by default under Vista and the app directory under previous versions of Windows. Unlike earlier versions of Windows, Vista does not create users with administrator privileges unless instructed to do so.

Would the above be possible for this release, or should we simply revert to doing it the Right Way on all supported Windows platforms?

However, I imagine that a great many of our devote XP users might want to continue using Snowberry in homeless mode.

skyjake

I would imagine that Vista can be detected through some Python os/sys module string?

<strong>EDIT:</strong> I'm looking at the multiplayer issue. It would appear there is some mixup in the console numbers.

OK, I fixed the control and view problems, but there are still problems with getting the client player's position and other data across.

DaniJ

How are we looking now? Anything remaining to do/should be done before we release Beta 6?

<strong>EDIT:</strong> I've submitted a patch to Snowberry (in the tracker) for using the home directory in Windows Vista.

skyjake

I'm currently looking into a crash I got in Heretic E4M1 after I died and tried to respawn. There was a segfault from con_busy.c.

I've committed the Snowberry patch (also committed new icon graphics which I apparently forgot to commit earlier).

DaniJ

I'm currently looking at ensuring we add complete vendor metadata to all Win32 binaries produced via the command line compiler and vcbuild.bat (when using Visual C++ 2008 Express that data is present and correct).

Then I'll continue on with adding my changes to the release notes/change log.

skyjake

I fixed one crash in jHeretic related to angles in P_DamageMobj. However, that was not the same as the busy crash, which I can't reproduce.

I'll continue my QA.

<strong>EDIT:</strong> The culprit seems to be <code>deleteMapLists()</code> in the automap, which is called from the busy worker. Only the main thread is allowed to call OpenGL functions. I guess I'll do some rearrangements...

I'll continue QA tomorrow night. I think we're definitely looking at a release before the end of the month.

DaniJ

As of svn rev #6414 all Doomsday plugin, Win32 binaries now include proper vendor metadata. Doomsday.exe is still missing that data when built via vcbuild but I'll fix that tomorrow.

Time is getting on here so I think I'll call it a night.

skyjake

I'm currently out of obvious issues with the OS X build. I'm compiling a release candidate that might as well be posted to SF.net.

I'll see if I can write some kind of an overview for the release notes.