Re: fpu controlword altered on windows

>
> Hmm. It's my understanding that _controlfp returns the previous state. Down at
> the end of the function, it calls
>
> _controlfp(fpuState, _MCW_RC);
>
> to reset the state back to what it was. Is that not what you see happening?

nope.
the value returned by _controlfp() is the new value *after* applying the 
change. So the saved value that is restored at function exit is actually 
the changed value...

http://msdn.microsoft.com/en-us/library/e9b52ceh%28VS.71%29.aspx


>
>> Speaking of which, the ALC_SOFTX_loopback_device extension works pretty
>> well!
>> compared with the tentative version I once sent you, the implentation in
>> openAl is indeed much simpler.
>>   From the application point of view: it's a bit less transparent than
>> just opening a device that does both capture and playback and calling
>> alcCaptureSamples(), a specific code path has to be written.
>> But on the other hand it's much clearer and robust:
>> On the whole I like it better..
>
> The changes needed from regular playback are fairly minor. You need to set the
> format (type+channels) and frequency when creating a context, the refresh/sync
> flags aren't valid, and you need to regularly call alcRenderSamplesSOFT to
> update things, but it should behave normal otherwise.

yes of course. by "specific code path" I meant three short ifs(), at 
creation, capture and cleanup... ;)

>
>> The only oddity, I guess, is having to use specific enums
>> "AL_STEREO"+"AL_SHORT"  instead of just reusing the same enum as the
>> fallback capture device code path, "AL_FORMAT_STEREO16" (which is
>> obviously less flexible, but more standard..)
>
> Yeah, I was going for flexibility, so the app has to do as little work as
> reasonably possible between rendering samples and getting them to where they
> need to go. The separate values also allow more formats to be provided without
> exploding the number of format enums (eg, adding floating-point output just
> needs to add an AL_FLOAT enum, instead of AL_FORMAT_*32 enums for each
> supported channel configuration; also makes it clearer, so you're not confused
> about what 8/16/32 bits represent).
>
> I'm not entirely happy with how it is now, though. I don't like using AL_*
> enums for ALC state, so I may rename them (or rather, make copies since the
> AL_* enums are also used for the buffer_samples extension).

yeah, that was a bit disturbing indeed. I had to double check the code 
to see what enums I was supposed to use.
And most problematic, it means that when using the extension, you need 
to querry for the extension in ALC and then expect there are new 
enums/functions in both AL and ALC. (with no "correct" current context 
for AL, as the enums are needed to create it)
_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal