VOGONS

Common searches


First post, by Expack3

User metadata
Rank Member
Rank
Member

I recently managed to get a modern Blitz3D game, SCP - Containment Breach, running on my Windows 10 machine. The strange thing, though, is I had to manually add LAA (Large Address Aware) support to the EXE per PCGamingWiki's advice. Given this is a DX7-based engine designed to run on retro hardware, it confuses me as to why forcing LAA got the game running. The only thing I could think of is the game hits an edge case in how WoW's (Windows on Windows) 32-bit support works, which forcing LAA somehow bypasses.

If someone knowledgeable in Windows compatibility could help explain why this works, I'd appreciate it.

Reply 1 of 9, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

Could it be that the game is doing some sort of available memory check and the Win10 computer has more RAM than the check allows for (variable type in the code) and so the value the game is seeing is some negative number?

That's the only reason I can think of right now that would cause it to work by adding LAA support.

Actually, it wouldn't even have to specifically be a memory check. It could just be a routine that allocates RAM for something. If it isn't LAA, it is going to freak out when it tries to allocate RAM because the allocation routines automatically do a check to make sure enough RAM is available. If the amount of available RAM overruns the variable type that is used for the allocation routine check, the game is probably going to crash when it is trying to load.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK

Reply 2 of 9, by Expack3

User metadata
Rank Member
Rank
Member
cyclone3d wrote:

Could it be that the game is doing some sort of available memory check and the Win10 computer has more RAM than the check allows for (variable type in the code) and so the value the game is seeing is some negative number?

That's the only reason I can think of right now that would cause it to work by adding LAA support.

Actually, it wouldn't even have to specifically be a memory check. It could just be a routine that allocates RAM for something. If it isn't LAA, it is going to freak out when it tries to allocate RAM because the allocation routines automatically do a check to make sure enough RAM is available. If the amount of available RAM overruns the variable type that is used for the allocation routine check, the game is probably going to crash when it is trying to load.

That last part actually makes a lot of sense. I don't recall Blitz3D being a popular game engine, so perhaps, unlike other, more popular games and engines which use similar checks, I bet Microsoft didn't add a compatibility flag to prevent or correct the type overflow.

....Which gets me thinking: is there a Microsoft Application Compatibility Toolkit (ACT) compatibility flag which corrects RAM check or allocation overflows for 32-bit apps? I'll check this myself, of course, but it'd save myself time if possible if you or someone else knows.

Reply 4 of 9, by UCyborg

User metadata
Rank Member
Rank
Member

It doesn't call those memory size functions. When I started it via OllyDbg, it did issue a bunch of calls to CloseHandle with an invalid handle. Such condition raises exception with a debugger attached. Maybe it can happen that it accidentally closes handles to objects it shouldn't instead of cleaning up after itself. If it does make decisions based on VRAM size, you can try the game with dgVoodoo (MS DirectX version), which defaults to emulating 64 MB VRAM.

Does it crash right on startup? I've read about that, but doesn't happen on my end. I also tried enabling DEP for all processess (default is for Windows processes only) to see if that would make it crash, but it didn't.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 5 of 9, by Expack3

User metadata
Rank Member
Rank
Member
UCyborg wrote:

It doesn't call those memory size functions. When I started it via OllyDbg, it did issue a bunch of calls to CloseHandle with an invalid handle. Such condition raises exception with a debugger attached. Maybe it can happen that it accidentally closes handles to objects it shouldn't instead of cleaning up after itself. If it does make decisions based on VRAM size, you can try the game with dgVoodoo (MS DirectX version), which defaults to emulating 64 MB VRAM.

Does it crash right on startup? I've read about that, but doesn't happen on my end. I also tried enabling DEP for all processess (default is for Windows processes only) to see if that would make it crash, but it didn't.

The game crashes with a generic "Memory access violation" error whenever I try to start a new game without LAA. Doesn't matter whether I use dgVoodoo2. In fact, the game runs significantly faster using my native integrated Intel GPU (the only GPU my laptop has) than with dgVoodoo2.

Reply 6 of 9, by UCyborg

User metadata
Rank Member
Rank
Member

Now it crashes for me too. I tested in windowed mode at low resolution the first time. It's just a badly written game. Not really retro PC friendly, though it uses retro rendering APIs. It runs slow on my NVIDIA either way, dgVoodoo or not. It allocates lots of memory, eventually hitting the usual limit for 32-bit processes and crashing. The real limit is actually below 2 GB due to factors like memory fragmentation. So it makes sense that making it Large Address Aware helps.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 7 of 9, by Expack3

User metadata
Rank Member
Rank
Member
UCyborg wrote:

Now it crashes for me too. I tested in windowed mode at low resolution the first time. It's just a badly written game. Not really retro PC friendly, though it uses retro rendering APIs. It runs slow on my NVIDIA either way, dgVoodoo or not. It allocates lots of memory, eventually hitting the usual limit for 32-bit processes and crashing. The real limit is actually below 2 GB due to factors like memory fragmentation. So it makes sense that making it Large Address Aware helps.

Based on your analysis, what could the developers do to sensibly allocate memory based on what the game does?

Reply 8 of 9, by UCyborg

User metadata
Rank Member
Rank
Member

No idea, I've only dealt with simpler programming problems. I wonder, are the generated levels really huge or just the way they're stored is less optimal. Judging by CPU usage, it seems to take a lot just to render simple room. Maybe it renders invisible geometry?

I played Amnesia games few years ago, kept a couple of saved games of interesting places. Going from my memory, game deleted older saves, so you had to make copy of older saves if you wanted to keep them. The saves are basically big text XML-like files. I accumulated whopping 2 GB of them! Compressing them with 7-Zip reduced the size to about 10 MB. Though the reason for that magic is a lot of repetitive data.

Some old school game engine programmer could probably give good insights regarding memory consumption. There's also a remake in the Unity Engine. There's only 64-bit executable, needs more RAM, it's prettier and aims to expand on the original idea.

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 9 of 9, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

It is fairly easy to write a program to allocate the proper amount of RAM based on what the program does.

You have to do nothing special for variables. The only real thing you have to worry about is arrays, but that is pretty simple as long as you know what the program is going to do and how much memory it actually needs.
Newer compilers/languages do pretty good automatic memory cleanup while older stuff sometimes has issues or all memory cleanup is left to the programmer handling everything.

It is actually not that difficult to calculate exactly how much RAM you need to allocate even if you are running a program with a potential of thousands of threads.

As a programmer, you should be able to calculate exactly how much RAM everything needs and then write the code so the program can automatically calculate the total amount of RAM that needs to be allocated.

Sounds to me like the game just has horrible memory management.

If it just keeps using more and more RAM, it has was is referred to as a memory leak.

I don't know of a Microsoft compatibility toolkit that checks/helps with this type of thing.. but I haven't even looked into it either.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK