An X-fi release day review argues they even had to tone down EAX effects in some points, and phil sounded enthusiastic about the XP experience.
(also this seems to be the alchemy bug I had mentioned)
Still, yeah, I guess without a record under ideal conditions you can't really claim much.
pcgamingwiki.com
I don't really know how they possibly solved it in ALchemy once (it doesn't seem to be through the usual simple game profiles), but something can definitively be done for as much as it might be complex.
Btw you can't even assume that different versions of ALchemy on different drivers than the ones they had in 2007 are equivalent, given how they seem to have completely lost the awareness of their own crap (from shipping newer cards with the wrong alchemy path, to keeping openal broken in UE for years and years).
It seems that Creative has created a special patch for Far Cry to solve the problems of missing sounds but there is no mention of reverb effect.
The 2007 Creative ALchemy is "different" from today's due to the fact that Sound Blaster cards, from the Z series and newer, no longer have hardware accelerated OpenAL. In 2007 ALchemy converted DirectSound calls to OpenAL Audigy/X-Fi driver ct_oal.dll. Today ALchemy (which is no longer supported) uses some sort of internal emulation, in fact if you read the dsound.log file you will read "Using Creative software 3D library" or something like that and not "Using native OpenAL render". Owning a Sound Blaster Z, I can say that ALchemy exaggerates with the reverb effect in all games (and with DSOAL I realized it even more). In Half Life it is very noisy, you can't hear the dialogues. All this reverb, to my ears, makes the sound flat and details are lost (and I'm not an audiophile). I'm surprised that Creative has not been able to create a more accurate emulation.
For native OpenAL games there is Host OpenAL (sens_oal.dll) which has the same problems as the ALchemy emulation (also probably no longer supported). Doom 3 breaks your eardrums with reverb 😀
However even today in Windows 10, if ALchemy detects the ct_oal.dll driver in SysWOW64, it will use it as in 2007. Some rename sens_oal.dll (Host OpenAL) to ct_oal.dll. This makes ALchemy believe that there is an hardware accelerated card and then it will use the fake ct_oal.dll instead of its internal emulation. It makes no sense to do so, you replace one emulation with another. It also breaks the audio in some games.
mirh wrote on 2021-12-27, 20:17:An X-fi release day review argues they even had to tone down EAX effects in some points
I interpret the nordichardware site as talking specifically about the crystalizer functionality:
In short, we should have a lot to gain from using Crystalizer.
When we turn on the effect you notice how the sounds become more distinct, everything from footsteps to the jungle ambience. When we start to fill our enemies with led the setting is feeling a bit overdosed and we have to turn it down to 25-30% to make it comfortable for the ears. All and all Crystalizer boosts the sound but the sound image is a bit spiky in the higher regions which makes it a bit tiresome for the eardrums after some time. An ambivalent result.
I think Far Cry is the last game in the Crystalizer test section, before it goes on to CMSS. There is also a Far Cry section testing CMSS, but I don't see anything about reverb (or other EAX effects).
(Side note: It amuses me how much time they spent testing that stuff. I always turn anything like that off immediately in any hardware or software I have! I guess Creative's marketing worked, though...)
mirh wrote on 2021-12-27, 20:17:(also this seems to be the alchemy bug I had mentioned)
I interpret this as talking specifically about DirectSound emulation issues (rather than EAX). The specific bug mentioned is about duplicate sound buffers (I also had bugs with that in IndirectSound hehe), and it is vague enough that it's not clear what the "problem" is (it seems to be a different problem from the bullet point immediately preceding it). I guess to me when I read it I don't get the impression that it says "EAX didn't work in Far Cry but now it does"; it seems more like some DirectSound wrapper fixes.
It does mention Far Cry as a "new game", but I bet this is talking about the utility they had that you could use to "install" ALchemy to work with games. Back then when ALchemy was introduced I didn't know anything about wrappers, and I didn't realize that the only thing that program did was look in the registry for recognized games and copy dsound.dll into the appropriate spot, so I definitely used that utility and would have been excited to have new games "supported", even if they would/should have worked regardless with the dsound.dll placed correctly.
mirh wrote on 2021-12-27, 20:17:phil sounded enthusiastic about the XP experience.
I don't think that a lack of EAX means that the game doesn't sound good, far from it! In fact, after having listened to EAX reverb so much in a controlled environment (not in a game in context but with a single isolated sound playing over and over and over with different reverb settings) I actually don't think it sounds very impressive at all, and clearly games can sound good without it. Doom3 is the classic example in my mind that sounds worse with it enabled. I remember when they added it I was excited and turned it on, and immediately thought it sounded bad and turned it back off. I didn't know until years later that id was forced by Creative to add EAX so that DOOM3 could use the patented shadow method, and then it all made sense that it was added as an obligation and not designed with it in mind. There are some games, like F.E.A.R., that are clearly carefully designed to use EAX well and that using EAX is definitely the best experience and what the developers intended, but if a game wasn't designed to take advantage of it (like Far Cry seems to me), then that doesn't mean the sound design won't still sound great; it just might not have any reverb.
Sigh.. I guess I have been too much eager in trying to find some clue.
Comments here in particular suggest indeed some kind of cumulative issue with flushing older sounds/settings.
jonpol wrote on 2021-12-27, 23:48:I didn't know until years later that id was forced by Creative to add EAX so that DOOM3 could use the patented shadow method, and then it all made sense that it was added as an obligation and not designed with it in mind.
I don't really know about doom, but at least for the very closely related Quake 4, we know it was Creative's Carlo Vogelsang to implement the thing.
Anyhow, I think it's ironic that this way we got eax 5 headers to ship with the id tech 4 source code when it was released.
Kappa971 wrote on 2021-12-27, 23:17:The 2007 Creative ALchemy is "different" from today's due to the fact that Sound Blaster cards, from the Z series and newer, no longer have hardware accelerated OpenAL.
For the love of god, let's stop to fetishize "hardware acceleration".
There's nothing that cannot be replicated in software, especially with modern cpus.
I'm only implicitly setting that as a target because it just so happen that the few half-way "positive" reports I could find are from those days (since there you had the first release, and illions of people that cared about this)
Kappa971 wrote on 2021-12-27, 23:17:In 2007 ALchemy converted DirectSound calls to OpenAL Audigy/X-Fi driver ct_oal.dll. Today ALchemy (which is no longer supported) uses some sort of internal emulation, in fact if you read the dsound.log file you will read "Using Creative software 3D library" or something like that and not "Using native OpenAL render".
Yes, that's exactly what I'm talking about.
And that's bad as we extensively discussed in the EAX emulation thread (though I guess I may have assumed too much HOAL was inherently better)
Kappa971 wrote on 2021-12-27, 23:17:However even today in Windows 10, if ALchemy detects the ct_oal.dll driver in SysWOW64, it will use it as in 2007. Some rename sens_oal.dll (Host OpenAL) to ct_oal.dll. This makes ALchemy believe that there is an hardware accelerated card and then it will use the fake ct_oal.dll instead of its internal emulation. It makes no sense to do so, you replace one emulation with another. It also breaks the audio in some games.
Nothing wrong with emulation, and one could be potentially better than the other.
In fact, now that we have eaxefx implementing the EAX#.0 extensions, I wonder how "native OpenAL" ALchemy could sound there.
... not that I'm expecting any reverb even with that (if it even exists, it must be some implementation-specific behaviour like the UT2k4 one I just linked in my post in the last page), but still I guess it's something else to experiment with.
pcgamingwiki.com
Unreal 2 - EAX through OpenAL *ONLY* - reverb with an Audigy 2 ZS driver ( https://danielkawakami.blogspot.com/2021/08/f … port-packs.html ) and EAXEFX is.....different. You can just test it in the training area (basement of the first level). NO CMSS, just the EAX.
EAXEFX is still missing something. But it's good and perfectly working 😁
Speaking of which.....there's a new release! https://github.com/bibendovsky/eaxefx/releases
For the love of god, let's stop to fetishize "hardware acceleration".
There's nothing that cannot be replicated in software, especially with modern cpus.
I'm not a programmer but I think it is impossible to emulate something accurately without having all the documentation. What I don't understand is why Creative is so reluctant to release source codes and documentation of technologies that are no longer supported and with which they no longer have a way to monetize.
Yes, that's exactly what I'm talking about.
And that's bad as we extensively discussed in the EAX emulation thread (though I guess I may have assumed too much HOAL was inherently better)
Host OpenAL works worse than ALchemy. With Doom 3, Quake 4, Pray, BioShock... I've always had issues with Host OpenAL. The level of the reverb effect is exaggerated as in ALchemy. Getting ALchemy to use Host OpenAL is a bad idea, it doesn't improve emulation and it breaks the sound in some games I've tried.
Currently I have uninstalled both ALchemy and Host OpenAL to use DSOAL (or EAXEFX) + OpenAL Soft instead. They are not perfect and never will be due to Creative, but I think they are still better than the official emulation.
One question, is OpenAL Soft's reverb with "boost = 0" the same as Audigy's reverb? In some games where the reverb was very loud with ALchemy, with DSOAL + OpenAL Soft it is barely noticeable.
Kappa971 wrote on 2021-12-28, 22:50:What I don't understand is why Creative is so reluctant to release source codes and documentation of technologies that are no longer supported and with which they no longer have a way to monetize.
I don't have an answer, but from what I can tell on the outside and after-the-fact it seems like something changed (for the worse) at Creative the company. Look at some of these quotes from the EAX 1.0 SDK:
As DirectSound property sets, EAX is an open standard that takes advantage of any hardware-accelerated card (such as Sound Blast […]
As DirectSound property sets, EAX is an open standard that takes advantage of any hardware-accelerated card (such as Sound Blaster® Live!) that provides the necessary reverb processing.
...
As an open standard, EAX works not only with Creative’s cards, but with any manufacturer’s cards that care to take advantage of the EAX reverb property sets.
...
We’re also at work to turn EAX into an integrated component of DirectSound, which will allow developers to use EAX’s reverb effects without going through a property-set interface. This also means that the same reverb effects will be simulated in software if an audio card doesn’t exist to add them.
If you have ideas on future directions for EAX, please send them to [redactedDirectEmail]@ensoniq.com.
It's all so friendly! In August of 1998 they were all about having an open standard and documenting things and wanted to get input and make the PC audio world a better place and were even apparently excited about having EAX work in software even if someone didn't have a Creative card.
The EAX 2.0 SDK from 2001 has almost the identical quotes about open standards, and also talks about OpenAL. Everything is once again documented.
And after that............ everything seems to have changed 🙁
I'd love to get my hands on the old EAX SDKs, but they were apparently never widely disseminated into the developer community and nobody has posted them anywhere. Ironic, since we can still get the old A3D SDKs easily.
jonpol wrote on 2021-12-29, 00:53:It's all so friendly! In August of 1998 they were all about having an open standard and documenting things and wanted to get input and make the PC audio world a better place and were even apparently excited about having EAX work in software even if someone didn't have a Creative card.
The EAX 2.0 SDK from 2001 has almost the identical quotes about open standards, and also talks about OpenAL. Everything is once again documented.
And after that............ everything seems to have changed 🙁
ALchemy's support ended just under a month ago, we'll see what happens in the next few.
jonpol, if you have time and desire, would you check if Far Cry 64 bit makes EAX calls like the 32 bit version? Only the v1.32 64-bit patch needs to be installed https://community.pcgamingwiki.com/files/file … -upgrade-patch/ and https://community.pcgamingwiki.com/files/file … -content-patch/. This would definitely solve the dilemma (was discussed earlier).
Kappa971 wrote on 2021-12-29, 09:23:jonpol, if you have time and desire, would you check if Far Cry 64 bit makes EAX calls like the 32 bit version? Only the v1.32 64-bit patch needs to be installed https://community.pcgamingwiki.com/files/file … -upgrade-patch/ and https://community.pcgamingwiki.com/files/file … -content-patch/. This would definitely solve the dilemma (was discussed earlier).
I'm not able to do that at the moment, sorry. The current (released) 0.X versions of IndirectSound weren't written to compile with x64, and that's where I have all of the EAX stuff implemented. The new (unreleased) 1.0 version does build for x64, but I don't have any EAX stuff implemented yet so I wouldn't be able to see what calls are being made. I will try to keep this in mind, though, and try it out when I get that far.
Even if we find out that it makes the function calls, however, be aware that that doesn't necessarily mean that they would have succeeded (based on what was said in the earlier discussion). I could imagine, for example, that they might have just made whatever changes were necessary to make FarCry compile with 64 bits but otherwise made no changes (pretty typical to do the least amount of work possible when porting something that isn't expected to make much money heh), meaning that the game might still query for EAX support but then be expected to fall back to default no-EAX behavior (i.e. the same way it would behave on any 32-bit system without EAX support).
I found this: https://www.gog.com/forum/unreal_series/enabl … ment_2004_64bit. It could probably apply to Far Cry 64 bit too. In UT2004 64 bit EAX is missing, as already mentioned above on this topic.
Far Cry is the only game that allows you to select EAX in the menu even without compatible hardware (and probably in this case EAX would not work even if activated from the menu). Maybe that's why no one has ever wondered whether EAX is actually running in the 64-bit version. Case closed 😀
If there's no 64 bit "eax.dll" than there's no eax.
Given that EAX doesn't work on 64-bit games due to the "laziness" of the developers, it is strange that in 2004-2005 nobody talked about it in the forums (I couldn't find anything). I think a lot of people had a Sound Blaster in those years. Perhaps few had a 64-bit PC with 64-bit XP, but none of them ever noticed the lack of EAX?
Kappa971 wrote on 2021-12-30, 11:24:it is strange that in 2004-2005 nobody talked about it in the forums (I couldn't find anything).
64-bit versions of windows XP and server 2003 came out in April 2005. The first 64-bit AMD Opteron CPUs came out two years earlier in April 2003, but I guess at the time Linux would have been your only option to utilize the 64 bits of that CPU. Seeing as hardware EAX doesn't work on Linux, guess no one could have experienced any issues till they could game on XP/Serv03 after April 05.
God Of Gaming wrote on 2021-12-30, 12:21:64-bit versions of windows XP and server 2003 came out in April 2005. The first 64-bit AMD Opteron CPUs came out two years earlier in April 2003, but I guess at the time Linux would have been your only option to utilize the 64 bits of that CPU. Seeing as hardware EAX doesn't work on Linux, guess no one could have experienced any issues till they could game on XP/Serv03 after April 05.
In fact, the 64-bit patch for Far Cry came out in May 2005 (at least from the sites I've seen). Probably later the patches for UT2004 and Escape From Butcher Bay came out. The fact is that even after May 2005, no one noticed that EAX was not working? Very strange.
Not strange at all. Why bother playing the 64bit version when you've already played the 32bit version and iirc the game stores only provided the 32bit version. I used 64bit 2003 back in the day for gaming, the amount of people doing that is already very small 2003 64bit and farcry 64bit as well? Ha no.
UT 2004 64 bit is graphics-wise bugged, by the way (it has the bugged D3D9 renderer only 'cause there's no D3D8 64 bit). It's why we've always avoided it.
Red Mercury (Unreal Engine 2 based too) has the 64 bit patch on the CD release - it's NOT available as a download - and no one knows that.....'cause it brings no improvements at all.
HL2 64 bit has disappeared no one knows where 😁
As I've said EAX support is provided by eax.dll and there's no 64 bit eax.dll.
lowenz wrote on 2021-12-30, 14:08:UT 2004 64 bit is graphics-wise bugged, by the way (it has the bugged D3D9 renderer only 'cause there's no D3D8 64 bit). It's wh […]
UT 2004 64 bit is graphics-wise bugged, by the way (it has the bugged D3D9 renderer only 'cause there's no D3D8 64 bit). It's why we've always avoided it.
Red Mercury (Unreal Engine 2 based too) has the 64 bit patch on the CD release - it's NOT available as a download - and no one knows that.....'cause it brings no improvements at all.HL2 64 bit has disappeared no one knows where 😁
As I've said EAX support is provided by eax.dll and there's no 64 bit eax.dll.
At this point, the only 64-bit patch worth installing is Far Cry's. Far Cry 64-bit seems more optimized than the 32-bit version. By installing the contents of the 64-bit patch on the 32-bit version, in some places the fps drops below 144 (I forced Super Sampling from Nvidia Inspector), with the 64-bit version they seem more stable.
FC 64-bit had a purpose. It showed what you could do with high-end hardware and the power of 64-bit. HL2 64-bit tried to do the same thing, but the Source engine was just too buggy at the time - which is why the patches are no longer available - and Valve has since moved on to Source2, which is 64-bit, so they can just port the old HL2 offerings to it down the line - possibly before HL3 ever shows up - and get full benefits.
Crysis 1 64 bit works perfectly on AMD CPUs (it's still CPU heavy but it works). The 32-bit version requires a modification to the executable to ensure that the game does not crash, due to the missing 3DNow instruction (if you have an AMD CPU), but there is no reason to use Crysis 32-bit, unless you have a really old PC (but at that point the CPU definitely supports 3DNow).
#Far Cry
With AMD Ryzen 5 1600 + GTX 1060 6gb, 1920x1080, with all details maxed out, HDR enabled and Supersampling Antialiasing forced by Nvidia Ispector, with Far Cry 32 bit (with 64-bit content) I don't always maintain 144 fps. With Far Cry 64 bit, the game feels more stable (I think Far Cry 64 bit uses the CPU in a better way).
