ALAudio for UnrealTournament - development and links

[monkeybrain]

for this. the sound positioning is helping a lot against the godlike bots. However, I always get kicked out of servers for using this openal version

it says alaudio.dll is the cause.

[Smirftsch]

no suprise, after all its a modification of your original UT installation and is unknown to the anticheat system in use- it can't distinguish ALAudio from a possible bot or other hack.
All you could do is to ask the serveradmin(s) to whitelist this package, but it needs to be updated then with any update I am doing here.

[monkeybrain]

no suprise, after all its a modification of your original UT installation and is unknown to the anticheat system in use- it can't distinguish ALAudio from a possible bot or other hack.
All you could do is to ask the serveradmin(s) to whitelist this package, but it needs to be updated then with any update I am doing here.

Yep understandable. However, most ut99 guides online acknowledge your OpenAL renderer, and yet none of the active communities allow it online.

Hopefully it catches on and the anticheat systems in use on all the servers whitelist it soon.

[Higor]

Quoting myself in a sunken thread from UT99.org:

Ok that isn't the best non-code dependant system there.
The fact that said ZoneInfo actor is coded directly onto the audio plugin is a complete aberration, I strongly urge mappers to NOT use this at all.

If the coder wants this to have a broader usage, he should implement a code independant system where embedded 'EAX_Actor' types are found in each zone/point-radius and read the UProperty fields for a 'EAX_Ambient' property, then cached into an internal Dynamic Array in the plugin so that no references are held.

You might as well include a ConsoleCommand for triggering zone caching again (FExec hook is available on the audio renderer right?).

You get that sorted (super easy to do) and ALAudio ready maps will start coming up in both UT and Unreal.

[Smirftsch]

Uhuuu... what can I say?
This "aberration" was and still is the first stage of all this development for UT and is like that now almost 10 years, one of the first ALAudio versions are in the OMP which seems to be in use in the UT community more or less.
All the feedback I got over this time you can see is in this topic, hell I even got more feedback already from the DeusEx people and this version is only a few weeks out. I know Oldunreal is more known for Unreal instead for UT and all gigabytes of downloads and developments I also have for UT never changed that.

I am keeping ALAudio in sync with the continuing development I do, in hope to provide something useful for the UT community and sorry to say that, if I read things like:

I strongly urge mappers to NOT use this at all.

and that in places in which I am not involved and which I can't overview, while it would have been really easy to ask/report/question/suggest anything about it here, and that for almost 10 years already - this honestly pisses me off. It really makes me question myself what for I am doing it at all.
I know things are often said without much thought, still its really disappointing.

Also I plain don't have the time to visit other forums on a very regular basis, this also counts for UT99, so forgive me that I didn't know about this feedback from there which you have been quoting from yourself.

Alright, don't get me wrong here, I don't want to start any drama here, it isn't about you in person
I don't want to blame you or anyone else, I don't and I didn't want to insult you or anyone else-  I just had the feeling that it should be said for once.


Now- I have to admit that I am not sure what you are suggesting here. I see the disadvantages you are speaking about, but I am not sure about your solution for it. Can you elaborate?

[Higor]

You have to create two versions of the same maps if you want it to be played by anyone.

ZoneInfo actors are very important on maps, replacing them with ones that generate code dependancy to a native audio renderer and makes it unplayable to anyone unable to run it, or online.

This is solved by setting a simple standard to the developer's choice:
- Force all users to run OpenAL as default/base renderer.
- Make OpenAL obtain EAX data from maps without resorting to code dependancy, by predefining some names.

It's pretty obvious that the second choice is the way to go.
Most Unreal Engine 1 games' packages are cross compatible if simple enough (if we don't want to resort to code embedding) so creating a non-code dependant package with the standar actor and then including it on the OpenAL bundle for mappers will make the process a lot easier.

== Step 1 would be to automatically trigger EAX data caching post-map load and via FExec hook thru a console command (ideal for maps where buildings explode and EAX changes from inhouse to outdoor effect mode)
== Step 2 would be to standarize the actor name as something like 'EAX_Actor', package doesn't matter.
== Step 3 would be to standarize the properties names as something like 'EAX_Ambient' and it's Enum, 'EAX_Radius' (0=zone,default, >0 = radius to actor)

Adding this actor (embedded or not) without generating package dependancy would be enough for the renderer to work.


So in some sort of caching function MyRenderer::CacheEAX we loop the active GLevel's actor list for non-deleted actors named 'EAX_Actor'.
We then run a TFieldIterator on said class (if this class wasn't checked already) to find both properties 'EAX_Ambient' and 'EAX_Radius'.
Store the class and the properties' pointers during the function (this way we get to support more than one EAX_Actor class in case it's being loaded from multiple sources like mutators, etc), if the class doesn't have said properties, discard the actor, keep finding more.
If the properties were found (or already cached for said class), read the memory offsets on those actors and store them in the renderer's cached dynamic array of EAX conditions.
Apply any existing EAX code to the player's position over that array instead of the player's zone.

EDIT:
Actor order will obviously define the actors found earlier in the actor list as the highest priority ones, overriding the ones found later, this is easily manipulable in UnrealEd with Order->To First or To Last.

Result:
Maps with EAX effects can actually be read by other audio renderers that support this (if someone decides to do his own renderer).
Maps with EAX effects run on servers and clients, regardless of what it's installed on those.

PD:
I sounded too harsh I know, it's just me used to a more aggresive community and having had to solve problems with limited time on my hands.


Late Edit:
I happen to know who's currently in charge of ACE's whitelisting, as long as the native package/rendere doesn't affect the GNatives array, it will work when whitelisted.

[han]

To be honest, i still sounds like a rather complicated and expensive way, and i still don't really understand why you need a dedicated cache command?

But when I just take what you wrote under results, my solution would be to simply ducktype the EFX* settings out of the current Zoneinfo. This way, there is no hard dependency on a specific class(name) or package and it's backwards compatible with already created maps. But there should still be some kind of conveniance package for mappers, like EFX.u with the class EFXZone, so non programming aware mappers can simply use this instead of coming up with their own class. But this EFX.u would be a very small pure unrealscript package, which could be downloaded of a server on demand.

So can you elaborate the advantage of your approach compared to the one i suggested above?

[Higor]

ZoneInfo variations, custom ZoneInfos, etc.

ZoneInfo actors are way to important to have them occupied for a single purpose, or having to subclass the EAX zone on every map that needs custom Zone behaviour.
Delegating EAX data to a separate actor, will also give mappers the ability to control EAX effects through radius (and any other conditions if ever implemented).

UnrealScript is extremely powerful and versatile if looked from inside (compiled code, UProperty objects telling other modules where to find an object's characteristics, etc), huge potential for non-code dependant native addons.

The manual cache command is optional, ideally caching should be done after the map finishes initializing, but limiting the caching to that is kind of a waste if you can dedicate an extra few lines of code into calling the caching function again with a console command (can be sent from an actor instead of the player) allowing maps to alter their own EAX effects after certain events, making stuff a lot more dynamic.

EDIT:
"EAX cache" looks like a good ConsoleCommand for that.
Galaxy does have the "astat audio" and "astat detail"(?) implemented, totally open sourced if you know where to look so it's not difficult at all to do.

I'll post later my XC_TravelManager component of XC_GameEngine for UT, it does something very similar by caching Inventory classes and their 'travel' properties allowing players to disconnect and reconnect coop games without losing their inventory.
Lots of class/property caching done there, and there's no performance impact at all.
Might be useful for Unreal 227.

[han]

[...] or having to subclass the EAX zone on every map that needs custom Zone behaviour.

I statet that the properties should be ducktyped. So you don't need to subclass the EFX zone at all.

Delegating EAX data to a separate actor, will also give mappers the ability to control EAX effects through radius (and any other conditions if ever implemented).

That Radius thing might be an advantage, but I doubt that it'll work out that well, as having the effects per zone is a a more natural choice then having them inside a sphere/cylinder.

I'll post later my XC_TravelManager component of XC_GameEngine for UT, it does something very similar by caching Inventory classes and their 'travel' properties allowing players to disconnect and reconnect coop games without losing their inventory.

I achieved the same for the DeusEx Coop mod I'm working on, by simply updating the ULevel::TravelInfo entries when a player is leaving the game.

[Higor]

Holy c**p, I wasn't aware that kind of practice was called 'Duck Typing' until I googled it up LOL, I was already doing this with a couple of functions.

Now it makes more sense to me, where'd the actual properties end up serialized when saving a map using these?


(Half-Life based games used brush-like volumes for EAX effects so it's not such a bad idea)

Either way, as long as mappers don't have to rebuild and save a map into two versions, and no dependancy to native packages is created, anything can work.

(Also, I don't know how to quote here :ape:)

[han]

Now it makes more sense to me, where'd the actual properties end up serialized when saving a map using these?

It's just about a different way to access these variables, so everything else like serialisation works as you are used to.

(Half-Life based games used brush-like volumes for EAX effects so it's not such a bad idea)

I have no clue how the effects work(ed) in hl1. Is there some documentation / code in hlsdk which would shade some light on how they did this?

Either way, as long as mappers don't have to rebuild and save a map into two versions, and no dependancy to native packages is created, anything can work.

So you would be fine with it even when it's implemented in the way i suggested this? I might even supply the code for it, as i would like to have this done before Rajada might start using these in his Nerf Arena Blast community pack.

(Also, I don't know how to quote here :ape:)

At the rights top of a post is a quote button but simply using

tags work too. But there are also rumors about an ancient tradition of encapsulating a string in "" for quoting...

[Higor]

Dude, you just gave me an idea...

In ZoneInfo we have these properties, which should be the same for other Unreal Engine 1 games (hopefully).

Code: Select all

// Settings.
var(Reverb) bool bReverbZone;
var(Reverb) bool bRaytraceReverb;
var(Reverb) float SpeedOfSound;
var(Reverb) byte MasterGain;
var(Reverb) int  CutoffHz;
var(Reverb) byte Delay[6];
var(Reverb) byte Gain[6];

There's a couple of bools there, that means 4 bytes of data, where we're only using the first (or last, depending on endian) 2 bits in memory.
Also, the EAX settings is a byte enum, so we can get away with writing/reading the data in those those boolen's offset+1.

Now onto serialization, we could have the OpenAL driver (and any other EAX supporting driver) create the 'EAX_Ambient' property+enum on it's own StaticConstructor() and attach them to ZoneInfo with the specified offset, this should be possible to do in both Game and Editor.
This way, we'll have access to that memory region from UnrealEd and UnrealScript (unless we do a full script rebuild in UnrealEd lol), and both Game and Editor would be able to serialize that data!.

Regarding dependancy, at least in UT99, it is possible to load maps with actors that contain invalid property names so maps saved using the extra 'EAX_Ambient' property can still be loaded by games and editors that don't have OpenAL (a log warning will be printed during load).

This is what looks closest to the current approach if you think about it, with the difference that every zone is a EAX zone .

[han]

/EDIT:
I made the wrong assumption that the EFX properties are queried on an FPlayingSound basis, and not once in UAudioSubsystem::Update() based on player zone.

Indeed, it's a very cool idea to add it this way. However despite the fact that EFXZone also has a bunch of floating point variables, it has the disadvantage if someone opens the map in UnrealEd without having an audio device supporting this, the properties would get lost when saving.

But another approach came to my mind which would allow a more fine grained control about EFX effects:
Don't load the variables in a direct way out of the ZoneInfo, but add an unrealscript event to load the effects and also pass the actor for which these are loaded.

So a Zoneinfo supporting EFX would look like this.

Code: Select all

//=============================================================================
// EFXEventBasedZone.
//=============================================================================
class EFXEventBasedZone extends ZoneInfo;
        
var(EFX) enum EAmbients
{
      REVERB_PRESET_GENERIC,
      REVERB_PRESET_PADDEDCELL,
      REVERB_PRESET_ROOM,
      REVERB_PRESET_BATHROOM,
      REVERB_PRESET_LIVINGROOM,
      REVERB_PRESET_STONEROOM,
      REVERB_PRESET_AUDITORIUM,
      REVERB_PRESET_CONCERTHALL,
      REVERB_PRESET_CAVE,
      REVERB_PRESET_ARENA,
      REVERB_PRESET_HANGAR,
      REVERB_PRESET_CARPETTEDHALLWAY,
      REVERB_PRESET_HALLWAY,
      REVERB_PRESET_STONECORRIDOR,
      REVERB_PRESET_ALLEY,
      REVERB_PRESET_FOREST,
      REVERB_PRESET_CITY,
      REVERB_PRESET_MOUNTAINS,
      REVERB_PRESET_QUARRY,
      REVERB_PRESET_PLAIN,
      REVERB_PRESET_PARKINGLOT,
      REVERB_PRESET_SEWERPIPE,
      REVERB_PRESET_UNDERWATER,
      REVERB_PRESET_DRUGGED,
      REVERB_PRESET_DIZZY,
      REVERB_PRESET_PSYCHOTIC,
      REVERB_PRESET_CASTLE_SMALLROOM,
      REVERB_PRESET_CASTLE_SHORTPASSAGE,
      REVERB_PRESET_CASTLE_MEDIUMROOM,
      REVERB_PRESET_CASTLE_LONGPASSAGE,
      REVERB_PRESET_CASTLE_LARGEROOM,
      REVERB_PRESET_CASTLE_HALL,
      REVERB_PRESET_CASTLE_CUPBOARD,
      REVERB_PRESET_CASTLE_COURTYARD,
      REVERB_PRESET_CASTLE_ALCOVE,
      REVERB_PRESET_FACTORY_ALCOVE,
      REVERB_PRESET_FACTORY_SHORTPASSAGE,
      REVERB_PRESET_FACTORY_MEDIUMROOM,
      REVERB_PRESET_FACTORY_LONGPASSAGE,
      REVERB_PRESET_FACTORY_LARGEROOM,
      REVERB_PRESET_FACTORY_HALL,
      REVERB_PRESET_FACTORY_CUPBOARD,
      REVERB_PRESET_FACTORY_COURTYARD,
      REVERB_PRESET_FACTORY_SMALLROOM,
      REVERB_PRESET_ICEPALACE_ALCOVE,
      REVERB_PRESET_ICEPALACE_SHORTPASSAGE,
      REVERB_PRESET_ICEPALACE_MEDIUMROOM,
      REVERB_PRESET_ICEPALACE_LONGPASSAGE,
      REVERB_PRESET_ICEPALACE_LARGEROOM,
      REVERB_PRESET_ICEPALACE_HALL,
      REVERB_PRESET_ICEPALACE_CUPBOARD,
      REVERB_PRESET_ICEPALACE_COURTYARD,
      REVERB_PRESET_ICEPALACE_SMALLROOM,
      REVERB_PRESET_SPACESTATION_ALCOVE,
      REVERB_PRESET_SPACESTATION_MEDIUMROOM,
      REVERB_PRESET_SPACESTATION_SHORTPASSAGE,
      REVERB_PRESET_SPACESTATION_LONGPASSAGE,
      REVERB_PRESET_SPACESTATION_LARGEROOM,
      REVERB_PRESET_SPACESTATION_HALL,
      REVERB_PRESET_SPACESTATION_CUPBOARD,
      REVERB_PRESET_SPACESTATION_SMALLROOM,
      REVERB_PRESET_WOODEN_ALCOVE,
      REVERB_PRESET_WOODEN_SHORTPASSAGE,
      REVERB_PRESET_WOODEN_MEDIUMROOM,
      REVERB_PRESET_WOODEN_LONGPASSAGE,
      REVERB_PRESET_WOODEN_LARGEROOM,
      REVERB_PRESET_WOODEN_HALL,
      REVERB_PRESET_WOODEN_CUPBOARD,
      REVERB_PRESET_WOODEN_SMALLROOM,
      REVERB_PRESET_WOODEN_COURTYARD,
      REVERB_PRESET_SPORT_EMPTYSTADIUM,
      REVERB_PRESET_SPORT_SQUASHCOURT,
      REVERB_PRESET_SPORT_SMALLSWIMMINGPOOL,
      REVERB_PRESET_SPORT_LARGESWIMMINGPOOL,
      REVERB_PRESET_SPORT_GYMNASIUM,
      REVERB_PRESET_SPORT_FULLSTADIUM,
      REVERB_PRESET_SPORT_STADIUMTANNOY,
      REVERB_PRESET_PREFAB_WORKSHOP,
      REVERB_PRESET_PREFAB_SCHOOLROOM,
      REVERB_PRESET_PREFAB_PRACTISEROOM,
      REVERB_PRESET_PREFAB_OUTHOUSE,
      REVERB_PRESET_PREFAB_CARAVAN,
      REVERB_PRESET_DOME_TOMB,
      REVERB_PRESET_PIPE_SMALL,
      REVERB_PRESET_DOME_SAINTPAULS,
      REVERB_PRESET_PIPE_LONGTHIN,
      REVERB_PRESET_PIPE_LARGE,
      REVERB_PRESET_PIPE_RESONANT,
      REVERB_PRESET_OUTDOORS_BACKYARD,
      REVERB_PRESET_OUTDOORS_ROLLINGPLAINS,
      REVERB_PRESET_OUTDOORS_DEEPCANYON,
      REVERB_PRESET_OUTDOORS_CREEK,
      REVERB_PRESET_OUTDOORS_VALLEY,
      REVERB_PRESET_MOOD_HEAVEN,
      REVERB_PRESET_MOOD_HELL,
      REVERB_PRESET_MOOD_MEMORY,
      REVERB_PRESET_DRIVING_COMMENTATOR,
      REVERB_PRESET_DRIVING_PITGARAGE,
      REVERB_PRESET_DRIVING_INCAR_RACER,
      REVERB_PRESET_DRIVING_INCAR_SPORTS,
      REVERB_PRESET_DRIVING_INCAR_LUXURY,
      REVERB_PRESET_DRIVING_FULLGRANDSTAND,
      REVERB_PRESET_DRIVING_EMPTYGRANDSTAND,
      REVERB_PRESET_DRIVING_TUNNEL,
      REVERB_PRESET_CITY_STREETS,
      REVERB_PRESET_CITY_SUBWAY,
      REVERB_PRESET_CITY_MUSEUM,
      REVERB_PRESET_CITY_LIBRARY,
      REVERB_PRESET_CITY_UNDERPASS,
      REVERB_PRESET_CITY_ABANDONED,
      REVERB_PRESET_DUSTYROOM,
      REVERB_PRESET_CHAPEL,
      REVERB_PRESET_SMALLWATERROOM,
      REVERB_PRESET_UNDERSLIME,
      REVERB_PRESET_NONE,
} EFXAmbients;

struct EFXData
{
      var int   EFXVersion;
      var EAmbients      Ambients;
      var bool  bUserDefined;
      var float EFXflAirAbsorptionGainHF;
      var float EFXflDecayHFRatio;
      var float EFXflDecayLFRatio;
      var float EFXflDecayTime;
      var float EFXflDensity;
      var float EFXflDiffusion;
      var float EFXflEchoDepth;
      var float EFXflEchoTime;
      var float EFXflGain;
      var float EFXflGainHF;
      var float EFXflGainLF;
      var float EFXflHFReference;
      var float EFXflLFReference;
      var float EFXflLateReverbDelay;
      var float EFXflLateReverbGain;
      var float EFXflRoomRolloffFactor;
      var bool  EFXiDecayHFLimit;
      var int   _Reserved[32];
}

event GetEFXData( out EFXData Data, Actor Actor )
{
      Data.EFXVersion = 1;
      
      Data.Ambients = Ambients;
      Data.bUserDefined = bUserDefined;
      Data.EFXflAirAbsorptionGainHF = EFXflAirAbsorptionGainHF;
      Data.EFXflDecayHFRatio = EFXflDecayHFRatio;
      Data.EFXflDecayLFRatio = EFXflDecayLFRatio;
      Data.EFXflDecayTime = EFXflDecayTime;
      Data.EFXflDensity = EFXflDensity;
      Data.EFXflDiffusion = EFXflDiffusion;
      Data.EFXflEchoDepth = EFXflEchoDepth;
      Data.EFXflEchoTime = EFXflEchoTime;
      Data.EFXflGain = EFXflGain;
      Data.EFXflGainHF = EFXflGainHF;
      Data.EFXflGainLF = EFXflGainLF;
      Data.EFXflHFReference = EFXflHFReference;
      Data.EFXflLFReference = EFXflLFReference;
      Data.EFXflLateReverbDelay = EFXflLateReverbDelay;
      Data.EFXflLateReverbGain = EFXflLateReverbGain;
      Data.EFXflRoomRolloffFactor = EFXflRoomRolloffFactor;
      Data.EFXiDecayHFLimit = EFXiDecayHFLimit;
}

defaultproperties
{
      bUserDefined=False
      EFXflAirAbsorptionGainHF=0.994
      EFXflDecayHFRatio=0.83
      EFXflDecayLFRatio=1.0
      EFXflDecayTime=1.49
      EFXflDensity=1.0
      EFXflDiffusion=1.0
      EFXflEchoDepth=0.0
      EFXflEchoTime=0.25
      EFXflGain=0.32
      EFXflGainHF=0.89
      EFXflGainLF=0.0
      EFXflHFReference=5000.0
      EFXflLFReference=150.0
      EFXflLateReverbDelay=0.011
      EFXflLateReverbGain=1.26
      EFXflRoomRolloffFactor=0.0;
      EFXiDecayHFLimit=True;
      EFXAmbients=REVERB_PRESET_NONE
}

This would allow mod authors a really fine grained controll about EFX effects, like per actor/actorclass effects, or having non Zoneinfo actors which can have EFX settings like you suggested earlier.

[Smirftsch]

[split] [link=http://www.oldunreal.com/cgi-bin/yabb2/YaBB.pl?num=1421509983/0#0][splithere][/link][splithere_end]

[han]

I need some resonable EFX default values for the conveniance zones in EFX.u, like WaterZone, LavaZone, etc..

[han]

Just noticed that one could actually just go ahead and use the LocationID of the PlayerReplicationInfo to get a finer spatial control over the EFX environment.

[Smirftsch]

www.oldunreal.com/betatest/OpenAL_v1.6_UT.7z

see first post for details.

[sn260591]

After updating I noticed one problem - some voices of the player (shouts during a jump and falling from big height) began to sound very loudly.

[han]

After updating I noticed one problem - some voices of the player (shouts during a jump and falling from big height) began to sound very loudly.

Probably related to new SpeechVolume setting which affects SlotTalk. You could try setting SpeechVolume to the same value as SoundVolume in your UnrealTournament.ini

[Smirftsch]

yeah, forgot that the game isn't having a menu for that. Guess have to change something here yet.

[han]

yeah, forgot that the game isn't having a menu for that. Guess have to change something here yet.

Maybe we should add some small package like UALAudioConfigUI which adds a settings menu with ALAudio specific options. Having easy access to MusicAmplify option would be useful too.

/edit:
Another (additional) idea would be to have some setting like UseSpeechVolume, which selects whether the SLOT_Talk uses SpeechVolume or SoundVolume.

[path0gen]

hi all.
thanks for all the work on the unreal tournament updates!

i guess i should leave a report here since i can't find any existing notes on the issue i'm going to describe.

i use gog.com ut version, it's patched to v436. my system specs are: win 7 x64, phenomII x4 cpu, geforce gtx550 ti video. i have OMP0.99b patch and the latest OpenAL_v1.6 from this topic installed, as well as xc_engine.dll from ut99.org.

looks like it's impossible for me to use openal audio if i set affinity for unrealtournament.exe to a single core. the initial flyby sequence works, but the game crashes as soon as i enter main menu, and ALAudio.dll is mentioned in the crash message. when i remove affinity settings, everything seems to work fine.

the thing is, the unreal tournament installer from gog.com forces the compatibility setting for the game in windows registry, which makes unrealtournament.exe to always run on a single core. the compatibility flag is set in the following registry entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom\

i'll leave this topic at gog.com forums as a reference:

http://www.gog.com/forum/unreal_series/unreal_tournament_goty_compatibility_flags_stuck

you may want to delete the registry key with this compatibility flag manually to run ut with openal without issues, as i had to do. since quite a few people are probably going to use gog.com version of unreal tournament, or change affinity for the ut executable by other means, it's probably worth to include the info above into readme file for the current alaudio driver beta download.

i don't know how reliable it is to run ut on modern multi-core cpus without forcing it to single core mode. using the updated opengl/dx9 renderers from OMP0.99b and xc_engine.dll, i haven't noticed any immediate issues. i have run a few custom levels from operation na pali, 7 bullets and project xenome packs so far for testing purposes, they performed seemingly fine with OpenAL_v1.6 package.

[Smirftsch]

First off, welcome

Background is, OpenAL initializes a second thread for music decoding and buffering and this thread usually runs on an other core so at least this work hasn't to be done in the main core UT is running on and makes OpenAL perform better than f.e. Galaxy (made 1-2 fps on my testsystems).
Forcing to one CPU SHOULDN'T do any harm, I tested it with this config as well and it was running flawless for me- however, in version 1.6 there is still a bug causing it to eat up more CPU than necessary and I was reported already that this seems to cause trouble and crashes on some systems.
Will create a new version soon, also have to take care about the separate speech volume (anything that uses SLOT_Talk) which isn't considered in current version yet, the user is forced to set it up via advanced options.

So, now to the single core enforcement, Unreal 227 does that as well, but only for the main process not for the OpenAL thread and this is causing no trouble at all.
I have to admit at this point that I don't know (yet) how xc_engine does it or how the compatibility flag is handling it, maybe this covers child threads as well there (probably safe to assume it does).

To cut  a long story short- next version might fix the crash then, but even then it would still leave the disadvantage that the work for music decoding and buffering can't be done in a different core- no life critical issue, but still sad

Guess I need to investigate this compatibility thing. Thanks for input !

[sn260591]

xc_engine.dll doesn't matter. I tried to force a single core in the original 436 version, and this caused to crash after pressing esc while the intro. Crash stop if I chose Galaxy.

[path0gen]

@Smirftsch

thanks for the info!
xc_engine readme claims it does nothing with affinity, it says a multi core fix is still needed when using the custom dll. but i can't notice any inconsistent game speeds so far on my quad core cpu after disabling affinity fixes. don't know what to expect on other systems with the same setup.

@sn260591

yes, that sounds like the same issue i described