I just downloaded the Alien Breed: Impact Demo from Steam, let the first time setup do it's magic, just to be presented by a "has encountered an error and needs to be closed" error.

It seems you did same error Gearbox did with Borderlands. In the nvtt.dll is a SSE2 flag which results in requiring a AMD Athlon 64 or Pentium IV as these are the first CPUs to support SSE2.

But you said every 2GHz Single Core CPU. My AMD Athlon XP 3200+ is running on 2,2GHz, so in theory i meet the system requirements.

The good thing is, back then, when Borderlands was new, someone compiled a new nvtt.dll without the SSE2 flag and all AMD Athlon XP users were happy playing Borderlands. The same nvtt.dll even works with Alien Breed: Impact and the demo ran fine without any lags or other problems.

For these that run into this error:
nvtt . dll with no SSE2 (unofficial Athlon XP fix) - Gearbox ... (Link) (http://gbxforums.gearboxsoftware.com/showthread.php?t=85817)

Just download the .dll and replace the original one. You may want to backup it first.

Let's hope Team17 is willing to fix that issue without relying on fan base made fixes.

Actually the issue is with the fact that the NVIDIA are just bad at compatibility, no idea why so many developers (in this case Epic Unreal 3 Engine) still use them on release products.

The issue doesn't actually steam from SSE2 either, but the fact that the DLL itself has no check to see if the functionality it's using is supported by the hardware... honestly it's typical NVIDIA programming, if it works on the development hardware ship it and believe it'll work for everyone. What makes it even more confusing to me is that Unreal 3 (for cooked runtimes) only uses DXT unless being shipped to Mac/Linux/PS3.

But ranting aside, would point out that the current release of Unreal 3 / UDK includes an updated variant of the NVTT.dll which provides better support. Would also recommend (if Team17 aren't already using it) that they utilise the Unreal Development Kit over the Unreal 3 SDK as it provides much better support and is being actively updated where-as the SDK isn't.

Although I could see why they wouldn't update given how much of a pain Lightmass is to impliment on maps that were developed using U3 SDK.

Bioware was able to avoid this crap in Mass Effect 2 (they use the .dll too) and they don't even support CPUs without SSE2. They don't even support Single Core CPUs. They state that the game needs at least a Dualcore CPU to run the game.

And it runs fine on my unsupported AMD Athlon XP 3200+ (well, with the 1.01 patch applied).

Yet this game does not run on an supported CPU. They clearly say: "Processor: 2.0+ GHZ Single Core Processor"

Well, mine runs on 2,2GHz and is a Single Core CPU, so i meet the requirements. Didn't they test their games on a minimum setup? Or did they just test on a Pentium IV?

Let me see if i understand this correctly:

* Team17 say their game will run on any single core 2GHz processor or better.
* There is an nVidia graphics driver component that has a bug in it.
* The aforementioned bug stops the game working on Athlon XP chips that meet requirements.
* There is an unofficial replacement dll that fixes this problem.

I doubt this will be a question of whether Team17 are willing to patch it, but one of whether they are allowed to roll out a patch via Steam with an unofficial nVidia dll in it. You may have to make do with the fan-based fix as i reckon Team17's hands are most probably tied on this one.

It appears the problem isn't down to the CPU hardware. You have said that it runs fine on your CPU with a software fix, so whilst not working "out of the box" in some cases, the hardware requirements are correct.

Thankyou for explaning the problem and posting a link to the fix. Can i suggest one of the moderators renames this thread to "Fix for Athlon XP CPU's" and stickies it?

The nvtt.dll affects everyone even someone with a ATI videocard and only a AMD Athlon XP. The DLL requires the SSE2 processor supplementary instruction set. So yes, it's a CPU thing, not a nVidia thing.

They just have to use an different nvtt.dll which is supplied by nVidia. Bioware was able to do that too. They use version 2.0.3.0 in Mass Effect 2.

And unless they change the system requirements to something like 2GHz Intel Single Core or AMD64 (which supports SSE2), it's a bug. I am meeting the system requirements and am unable to play the game without replacing game files with third party ones.

Ah i see, there is an official replacement dll that works? An official patch is infinitely more possible then.

I was never suggesting it wasn't a valid bug by the way, just that the hardware requirements are correct due to it being a software bug causing the problem.

Look at it a different way - there are two ways Team17 may choose to solve this; either alter the hardware requirements and stop supporting Athlon XP chips, or fix the software and release a patch. I'm merely pointing out to 'anyone reading' that it's a software bug ;).

Cathulhu, thanks for your report - I'm afraid that's something that never showed up in our Beta test, and all of our hardware here supports SSE2. We are currently tied to a specific version of the Unreal 3 Engine for various technical reasons, and the nvtt.dll file we ship is provided to us by Epic as part of that version.

I've entered this issue as a bug in our database and we'll address it as soon as time allows.

Cheers,
Charles

Well, it's a start. And there is already a working workaround with no side effects, so i can't really complain.

Hope you're able to figure something out to provide a more compatible version of the nvtt.dll in the future. I don't like workarounds.

While I agree that if CPUs that don't support SSE2 and are able to run the game fine, I don't agree to simply building the DLL without SSE2 optimizations(namely using that instruction set).

By rebuilding it without using SSE2 instructions you are lowering the performance of computers with cpus that DO support it. And I don't want to loose frame rate just because someone is still using his ancient computing device, no offense but thats the truth.

Wait, i didn't say anything about removing SSE2. Just removing the flag that enforces the use of SSE2. That's a difference. Modern games are able to use SSE2 if a CPU supports it without requiring it to run.

I agree that the SSE2 support should not be removed. That would be silly. I just want the requirement of SSE2 removed. Just a step back so that SSE is a requirement, which is supported by every 2GHz CPU. That's all.

That's why is said that i hope Team17 is able to fix that without the third party fix, that removes SSE2. Works fine for me, but less for others.

You can't build ONE .dll which will both support SSE2 and not support it.

There is a difference in supporting and requiring. You can support SSE2, without requiring it.

You'd need two separate .dll to do that.

Just as an additional information. I bought the game and tried it with the Mass Effect 2 nvtt.dll and it resulted in a crash, it seems they are not that easily exchangable as i thought. Using the workaround for Borderlands i mentioned above still works.

You'd need two separate .dll to do that.
No you wouldn't.

You'd need two separate .dll to do that.

Ever heard of IF and THEN?

Ever heard of instruction sets? You can't remove the instructions and then think that just because the cpu thats running the code will magically add all the instruction sets that it supports.

To repeat myself, i never said anything about removing SSE2 support. Just removing the enforced use of it. And don't come me with "one dll one instruction set" bullcrap.

Are you implying that Mass Effect 2, a game targeted for dualcore CPUs, does not support SSE2 just because it runs on my old rig? That is a just plain stupid thought.

Please read about how compilers work.

Please read about how compilers work.
I read about how compilers work, and discovered they translate high level program code into low level machine code instructions. I also found out there is a machine code instruction that's been on every x86 chip since before the first Pentium called "cpuid" that tells you about any available instruction extensions such as SSE2 in the "ecx" and "edx" registers, and there is also an instruction to jump the execution pointer to different sections of code based upon conditions being met, such as what's in these registers.

Based upon this, it certainly appears possible to have one dll that can detect what instruction sets are available and run different code based upon that.

I also read that modern Microsoft compilers pre-compile code to an intermediary "byte code" language, and did the "proper" compilation upon first run of the program when it knows what instructions are available on the CPU it is running on.

I've also noticed that when i download software there aren't a plethora of different download links depending on what CPU i have, the only difference i've noticed is that some have seperate versions for 32bit and 64bit. Does this mean developers use a "lowest common denominator" of instructions, or that they are doing that pre-compiled byte code thing i mentioned, or what?

I've followed the advice in your previous post, and it seems to back up what Cathulhu is saying. Could you please explain properly why this can't be done?

Hi,

I thought I'd just clear a few things up...

It IS possible to write code that detects whether an SSE2 capable processor is available and run different code accordingly.

The nvtt.dll was written by NVidia and is provided to us as part of the Unreal Engine 3 license.

We have the source code, and despite the fact that the compiler is set to only generate SSE (not SSE2) code, there are specific assembly instructions that have been injected into the C/C++ that are SSE2. So, the compiler isn't generating SSE2 instructions from the C/C++, but NVidia are specifically calling those instructions anyway.

There is support in the code for switching back to SSE instructions, or even turning off the advanced processor support entirely, although performance would obviously be degraded.

Cathulhu, I will contact you privately with a recompiled DLL to see if we can get a solution working. If this is possible, we will include it if/when we release an update to Alien Breed: Impact.

Cheers,
Charles

I read about how compilers work, and discovered they translate high level program code into low level machine code instructions. I also found out there is a machine code instruction that's been on every x86 chip since before the first Pentium called "cpuid" that tells you about any available instruction extensions such as SSE2 in the "ecx" and "edx" registers, and there is also an instruction to jump the execution pointer to different sections of code based upon conditions being met, such as what's in these registers.

Based upon this, it certainly appears possible to have one dll that can detect what instruction sets are available and run different code based upon that.

I also read that modern Microsoft compilers pre-compile code to an intermediary "byte code" language, and did the "proper" compilation upon first run of the program when it knows what instructions are available on the CPU it is running on.

I've also noticed that when i download software there aren't a plethora of different download links depending on what CPU i have, the only difference i've noticed is that some have seperate versions for 32bit and 64bit. Does this mean developers use a "lowest common denominator" of instructions, or that they are doing that pre-compiled byte code thing i mentioned, or what?

I've followed the advice in your previous post, and it seems to back up what Cathulhu is saying. Could you please explain properly why this can't be done?

Indeed it is possible to detect what instruction sets the cpu supports, that does not mean it will automagically use them if the assembly isn't compiled specifically telling the compiler that it can use them.

As for the intermediate language, thats .NET land of managed code which does indeed take advantage of every possible performance enhancement, however thats .NET land and has nothing to do with unmanaged C/C++.

Well, with the DLL that Charles sent me, it works like a charm.

Any news for an update?

We're hoping to fix as many issues as possible before we release an official update. I'm glad the DLL I sent you fixes the initial problem, however, it seems to be the cause of a crash on other configurations (PC compatibility testing is a nightmare). Issues like this need thorough testing before we release as we don't want to rush into sending something out that causes more issues than it fixes.

Be assured that we are are working hard behind the scenes.

Cheers,
Charles

Hi,

I thought I'd just clear a few things up...

It IS possible to write code that detects whether an SSE2 capable processor is available and run different code accordingly.

The nvtt.dll was written by NVidia and is provided to us as part of the Unreal Engine 3 license.

We have the source code, and despite the fact that the compiler is set to only generate SSE (not SSE2) code, there are specific assembly instructions that have been injected into the C/C++ that are SSE2. So, the compiler isn't generating SSE2 instructions from the C/C++, but NVidia are specifically calling those instructions anyway.

There is support in the code for switching back to SSE instructions, or even turning off the advanced processor support entirely, although performance would obviously be degraded.

Cathulhu, I will contact you privately with a recompiled DLL to see if we can get a solution working. If this is possible, we will include it if/when we release an update to Alien Breed: Impact.

Cheers,
Charles

Now that's what I call customer service. Recompiling a core library for a single user? Not many people do that. Good show, T17.

Yeah, i agree that there shouldn't be many left with such an old PC (i plan to replace mine soon) but as long as it's a bug, it has to be fixed. Although, it wasn't that hard to fix from that description. And they hit it on the head on the first try. Game runs like a charm now. That is one of the games where my XBox pad really shines.

We're hoping to fix as many issues as possible before we release an official update. I'm glad the DLL I sent you fixes the initial problem, however, it seems to be the cause of a crash on other configurations (PC compatibility testing is a nightmare).
Was to good to be true. There's always a downside that bites you in the ass.
Issues like this need thorough testing before we release as we don't want to rush into sending something out that causes more issues than it fixes.
I prefer a polished product, not a rushed one. So i agree. Not like the game "The Saboteur" from Pandemic that crashed on nearly all ATI videocards and it took them months to patch that. That was a massive blunder. How did that get through QA?

Be assured that we are are working hard behind the scenes.

Cheers,
Charles
That's all i wanted to hear. I don't regret buying this game with this kind of support.