-
Notifications
You must be signed in to change notification settings - Fork 522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EAX's .eal files #30
Comments
Any file parsing is done by the game engine. Neither EAX nor OpenAL deal directly with specific file formats, so the engine needs to be loading it first before passing it to EAX or OpenAL. I've not heard of .eal files before, and searches haven't turned up anything relevant. How are they being loaded and given to OpenAL/EAX? If the issue is converting EAX properties to EFX, that's certainly doable. |
It's definitely done by the EAX code. https://github.com/JACoders/OpenJK/blob/master/codemp/client/snd_dma.cpp#L5484 The .eal extension may just be what they chose for the game, I'm not sure. |
Hmm, seems to be something for Creative's proprietary EAX Manager, describing reverb zones and such. The good news is it seems to mostly be a frontend to simply loading EAX-related data into a "manageable" form, while setting EAX properties is still done with the usual eaxSet calls. In that case, it's just a matter of changing the eaxSet calls to the EFX equivalents (and adjusting the property values as appropriate). And yes, OpenAL Soft will be able to work with multiple simultaneous reverb environments, if the game makes use of them. The bad/less good news is that I can't find any information on the file format, and very little information about the EAX Manager itself. The most I can find is a header for the IEaxManager interface and related structures, so I can at least see the kind of information it could have, but loading the reverb data is still going to rely on having eaxman.dll. There's a couple options to work around this:
|
Judging from the file header, they appear to be RIFF of some sort. But my skills to reverse engineer are not existent lol. And yeah, derivatives of them are probably not allowed. |
RIFF files make a bit of sense. Creative seemed to like RIFF for storing resource data (they used it for sf2, too). That gives me some ideas for how it may be structured, though I obviously have no way to know without any sample files to look at. As for the actual EAX stuff (eaxSet, etc), that is convertible to EFX, even with using EAX Manager to load the files. It's not a 1:1 translation though, and may need a bit of restructuring, but certainly doable. So you can convert the EAX code to EFX, then find some way to handle the EAX Manager afterward. If you need any help with converting it, I can try to provide some guidance, although I don't have Jedi Outcast or Jedi Academy to be able to test any code changes. |
Since there's no OpenAL Soft issue here, I'm closing this. However, if you're still interested in help converting the EAX calls ( |
Since |
I did some reverse engineering on the EaxMan.dll in the past, but so far I have only partially figured out the binary layout of the EaxManager, which is a prequisite to figuring out the full details of the file format. It's on my bucket list, albeit very low priority. Also I doubt EaxMan is in scope of openal-soft itsself. |
Someone was able to acquire the eagle sdk source including the eaxman stuff if you want it. Creative considers it ESOL so I don't know if they even care if the source gets out anymore if you want it for looking at the parser or headers. |
Yes, it is End of Service Life (EOSL)... abandoned, and no longer supported... as stated in a response to an inquiry email. I have taken a stab at documenting the EAL file format. It's a working draft at the moment. The EAL description is complete, but I need to finish documenting the EAM file format (for the mesh file that EAGLE saves-- the file name for any geometry set (the .eam file) is embedded in the EAL file). |
Yes, you are correct. Also, SoF2 and Jedi Knight Outcast used EAGLE3.0a to create their EAL files (based on EAX 3.0). |
@mirh |
I do have the EAGLE 2.0 SDK and stuff and worked on that before. Are there download links for the EAGLE 3.0a SDK? Is the eal file format for EAGLE 3.0a in general structural different, or does is it (mostly) down to afaik EAX version specific structures such as EAXLISTENERPROPERTIES, which directly get saved into the eal file? |
@Archangel35757 is the one who was able to acquire it. |
I suspect mostly the latter... due to the changes in EAX 3.0. EAGLE 3.0a exposes almost all of the EAX 3.0 parameters for the artist/sound designer to adjust-- a few parameters (e.g., Panning, Exclusion, Occlusion Direct Ratio are not implemented-- yet supported in EAX3.0) are hard-coded to defaults (plan is to implement these in near-future). See comparison screenshots below. One main change is a much better graphic for the reverb response graphics model (due to an updated revrespdisplay.lib). I hex-edited the sample .eal files that came with EAGLE 2.0 so I could open them in EAGLE 3.0 (not an easy task). Currently working on version 3.0b -- bug fixes and some usability enhancements to make it easier for the artist to work with... but with the goal of keeping changes to a minimum. Please contact me either via email at yahoo(dot)com... or find me here- https://discord.me/jediknight |
More of a question than anything but is there any way to interpret the .eal files with which to use for alsoft's EFX without using the closed source EAX code? I'm assuming nobody has reverse engineered the file format because I couldn't find any results about it online. Looking at moving the JACoders/OpenJK openal code to alsoft eventually and would have to sacrifice the effect support entirely because there is no way to determine environments without those files.
The text was updated successfully, but these errors were encountered: