[Bug 22302] Alien Dominion: The Acronian Encounter crashes

http://bugs.winehq.org/show_bug.cgi?id=22302

Chris  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #24 from Chris   2010-04-23 22:43:14 ---
(In reply to comment #23)
> I don't know anything about openal32, but the lag is pretty short:
>
> ...
>
> If i get it correctly from openal-documentation it tries to find the major
> version with   alcGetIntegerv, but then somehow fails.
> Hacking alGetError() to return 0 (AL_NO_ERROR) makes the game start fine. So
> the question is why alGetError() returns 0x000a004 (which seems to be
> AL_INVALID_OPERATION). Maybe this needs to be fixed on the Linux-openal side
> (?)

Hi.

I've seen a similar issue once before (coincidentally, another game that also
uses Ogre in Windows), and it is a separate issue from the one in bug 20799.
The problem here seems to be that the app is (incorrectly) checking alGetError
for an error generated by alcGetIntegerv, and raises an exception if it doesn't
return AL_NO_ERROR. However, the alcGetError function is supposed to be used,
being passed the same device, for testing previous alc* function calls.
Further, alGetError is supposed to work on the current context, so it's
generating an AL_INVALID_OPERATION error for being called without a context.

For some reason, Creative's OpenAL32 DLL will always return AL_NO_ERROR if
alGetError is called without a context set, regardless of previous calls. Eg:

ALuint source;
alcMakeContextCurrent(NULL);
alGenSources(1, &source);
if(alGetError() != AL_NO_ERROR)
...

Will not report any problems even though alGenSources couldn't do anything and
left 'source' as random junk. OpenAL Soft is more strict about this, and you'd
see the same problem using its OpenAL32.dll in place of Creative's.

There's two ways I can think of to solve it on this side. One would be to patch
Wine's DLL thunk to do:

ALenum CDECL wine_alGetError(ALvoid)
{
    if(alcGetCurrentContext() == NULL)
        return AL_NO_ERROR;
    return alGetError();
}

And that will replicate the behavior of Creative's DLL. The other option is to
modify OpenAL Soft so the NULL context has its own error state, and set an
error if any other al* calls are made without a context set. Neither option is
especially pretty, IMO, as its technically against spec. The best option would
be to fix the application, if possible.