AURORA: New FEV loading capabilities#367
Conversation
Nostritius
force-pushed
the
aurora_fevproperties
branch
from
bc8df36 to
e9cea7f
Compare
src/aurora/fevfile.h
Outdated
| uint32 type; | ||
| int32 integerValue; | ||
| float floatValue; | ||
| Common::UString stringValue; |
There was a problem hiding this comment.
Hmm, that same pattern, a variable with multiple potential types, comes up again and again in the codebase now. In the ActionScript code, the NWScript code, the Lua code, etc.
Maybe be should see if we can use Boost.Any or Boost.Variant for this instead? This code might be the ideal test environment for that. Could you see if you can do that?
For the differences between Any and Variant, see https://www.boost.org/doc/libs/1_53_0/doc/html/variant/misc.html#variant.versus-any . I'd say Variant sounds like the better candidate, with Any a fall-back if Variant should not work for our use case.
You probably still need variable to store the current type, though. I'd rather that be an enum instead of just an integer without any obvious meaning, too.
Nostritius
force-pushed
the
aurora_fevproperties
branch
2 times, most recently
from
12d4a81 to
0f8db23
Compare
|
I have now changed the properties to use an enum and boost::variant. As for the other occasions with such constructs (at least the ones I wrote), I will change them in other PRs. |
src/aurora/fevfile.cpp
Outdated
| Property property; | ||
| property.type = PropertyType(fev.readUint32LE()); | ||
| switch (property.type) { | ||
| case 0: // Integer value |
There was a problem hiding this comment.
Can you replace these with the enum value as well, please?
Nostritius
force-pushed
the
aurora_fevproperties
branch
from
0f8db23 to
aef26cc
Compare
|
Done |
|
Merged as 204cccc...29ce633, thanks! :) |
|
Btw, upon further thought, I think this belongs into sound/, not into aurora/. |
|
Hmm, but SSFFile is also in aurora? |
|
I consider FEV to be more connected to FMOD wavebanks than SSFs are to
sound files.
In fact, my "vision" for FEV, and also to the analogues files for XACT
and Wwise, is that a FEV would, by itself, be able to start playing a
sound. I.e. the engine would load a FEV, that FEV would maybe even
load the relevant wavebanks, and then the engine would tell the FEV to
play a sound, and the FEV would handle the rest.
XACT and Wwise would have similar interfaces.
|
|
Ok, i will move this in my next update for FEV files |
2 participants
Add some new values which can now be read from the FEVFile loader