Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Return of the Tentacle

Sequel to the Point&Click-Adventure "Day of the Tentacle" · By catmic, pepper-mint-audio

Windows XP Compatibility

A topic by leecher1337 created Jul 22, 2018 Views: 3,495 Replies: 24
Viewing posts 1 to 14

Hi,

Any chance to make this game Windows XP compatible? It currently fails with error "InitializeCriticalSectionEx cannot be found in KERNEL32.dll". This function is only available on Vista and upward. 

Developer

Hi leecher1337,

Unfortunately, supporting XP is not possible for us. What you can try though is forcing the game to start with the OpenGL-Renderer. You can do this by running the game with the parameter "-force-opengl". If it works, fine. If it doesn't, there is nothing we can do about this.

Hi catmic,

Thank you for your support!
I now patched the UnityPlayer.dll to remove the problem with the InitializeCriticalSectionEx reference. Then I got a new error:
"GLContext: failed to create context: Die angegebene Prozedur wurde nicht gefunden.

Failed to initialize graphics.
Your Windows version seems to be Windows XP, and this
application likely does not support it (it would have to
support OpenGL rendering to work on XP).
InitializeEngineGraphics failed"

I found this article:
https://blogs.unity3d.com/2017/07/10/deprecating-directx-9/

So as my graphics driver was from 2008, I updated it and the game started fine.
However there are still issues, in the Intro, after Bernard ate his sausage,
screen goes black and the rest of the Intro is not visible anymore, also when
trying to play the tutorial, I only see a cursor on black background.



I have a GeForce 9400 GT graphics board. Altough it should be DX10 compatible, I experience these weird issues.
I guess you don't have any ideas regarding these problems, do you?
If compilation settings aren't set as mentioned in the article above, would it help to make a special build with these settings?

Developer

Great you got the app running! 

What did you do to patch the UnityPlayer.dll? 

The issue you have seems to be common with older Macs on Intel GPUs running the OpenGL rendering path. We are still looking for a way to reproduce this on our machines. If we get it fixed, it could also work on your setup.

So there may be hope... Glad to hear, looking forward to your investigations, thanks!

When looking at RotT-Win32.exe I saw that Unity engine has a workaround for checking whether InitializeCriticalSectionEx is present, so I guess, this may be a bug of UnityEngine.dll and the IAT import of this function just "slipped in". I guess it should be reported to UnityEngine vendors as I think it is unintentional.

As for the patch: Check IAT entry at raw file offset 0xF9730A reading "InitializeCriticalSectionEx". Just overwrite the "Ex" part of this string with 0x00 bytes so that it reads "InitializeCriticalSection". As the function takes 3 parameters, not one, you need to patch the 2 PUSH instructions of second and third parameter at raw file offset 0xD4FD91:  6A 01 6A 00
NOP then out by putting 90 90 90 90 in there and you are done. I can upload patched file, if needed or a patcher, if you prefer, but as you see it's very easy to patch.

(+1)

Don't know if it helps you debugging, but if I attach an opengl tracer to the application, I get the following errors:

InterceptShaderGLSL::UseProgramPre - Invalid ID 42
InterceptShaderGLSL::UseProgramPre - Invalid ID 43
InterceptShaderGLSL::UseProgramPre - Invalid ID 46
InterceptShaderGLSL::UseProgramPre - Invalid ID 56
InterceptShaderGLSL::UseProgramPre - Invalid ID 1

The error of program with ID1 is the one that surfaces when screen goes black in Intro.

glCreateProgram()=1 glBindAttribLocation(1,0,"in_POSITION0")
glGetIntegerv(GL_NUM_PROGRAM_BINARY_FORMATS,062FEADC)
glGetIntegerv(GL_PROGRAM_BINARY_FORMATS,00FAE1D0)
glProgramBinary(1,0x8e21,001C1194,6989)

Developer

Thanks a lot for providing these infos. 

It might not be preferable, but you could always try installing Linux (maybe in a VM or on a removable drive/portable hard drive?) so you can play the Linux version of the game. At least if this is fully an OS issue.

I can now hereby confirm that the problems that I encounter are related to the graphics hardware, NOT Windows XP.
I tried to play it with a Nvidia Geforce 8400GS on Windows XP and this one worked flawlessly. 
So I would suggest to incorporate my patch to the release .zip so that XP users can also play the game. Replacing the function call with the older version (InitializeCriticalSection) doesn't do any harm, as no special parameters are used anyway in the InitializeCriticalSectionEx function call.

I seem to have the same problem (Bernard eats the sausage and then it goes black except for the inventory), but on windows 10.

I got the same Problem - tidy Windows 7 Ultimate, Geforce 9800 GTX+, latest driver. After Bernard eats the sausage, the screen goes black except for the inventory and the mouseovers on the screen. Tried every setting in the options and the flag "-force-opengl". Nothing works yet.

Developer

Version 1.0.3 is out, which fixes the issue of the screen being black on older GPUs. Get it here: https://catmic.itch.io/return-of-the-tentacle

Yes, fixed it for me, thank you, great game!

This is great, thank you! Now Bernards room gets rendered correctly!
However, as soon as I leave Bernards room, game crashes. It again doesn't seem to be OS related, I also had this crash/hangup in previous version on a Windows 7 Notebook.

https://pastebin.com/6iTLPFT4
https://pastebin.com/Vq9EtVSb

Developer

Happy to see that the first scene is working for you, now! :)

Can you upload a crashlog of the issue occuring on your Windows 7 laptop? Both logs seem to be coming from XP. 

Also, can you try reducing the texture quality in the options menu?

I wonder why you want a Win7 log, isn't it even harder to analyze than XP with its ASLR? Here it is: https://pastebin.com/umY3psXx

Anyway, reducing texture quality to "HD" helped on both machines, thanks for the hint! Now let's see how far I can get... :-)

Developer

Thank you, this helps a lot. We identified the issue and will try something to improve the situation if higher textures are loaded.

Hi,
Unfortunately still a lot of crashes even at lowest resolution and texture quality:

https://pastebin.com/keH8rjvm
https://pastebin.com/HbqL2zbL
https://pastebin.com/aDm6xdLn
https://pastebin.com/qFy2tRD6

Not really playable for me currently, but looking forward to your bugfixes :)
Developer (3 edits)

For optimal performance, you will need to have roughly 1.4GB of free space in the user address space before starting the game. Is that the case for your system? 

As the crash always seems to occur once your user address space gets close to the 2GB mark (note, the game alone won't hit that mark, it is the sum of active programs running under your user space) we wonder why your OS does not make any use of the pagefile. Can you think of any reason why the pagefile stays empty? 

We tried our best to reproduce the crashes you have but even with the highest textures and AA options at FullHD, the 32 bit version works without any issues here.

(1 edit)

Hi,

I thought so, as it usually happens with mem usage around 1,7-1,8GB. So I guess you forgot to check return value of some malloc()-Alike functions (VirtualAlloc, HeapAlloc, ..), and so...

;-)

As for the Win7 system, I only booted it an started up the game, so no other applications taking up memory. Pagefile is turned on, so OS should be able to do paging. I once accidentally started ROTT on Windows XP machine twice and there I was in paging hell...

I saw that your executable is large-address-aware:

dumpbin /headers RotT-Win32.exe

....         Application can handle large (>2GB) addresses

                   32 bit word machine


But I don't use the /PAE and /3GB switches in boot.ini (or its equivalent in Win7, if there is something like that), so could that be something to try? I think it was causing some troubles for me or my drivers and also it's not really recommended to be used, so that I didn't enable it. Without PAE and 3GB switch, 2GB per-process limit is still kicking in, even if executable is LAAW. Still wondering what is sucking up so much memory, though... Paging won't help if 2GB barrier gets hit somehow.

To reproduce the error, maybe you can try to use https://github.com/lowleveldesign/process-governor and enforce a tighter memory limit on the process on your machine?

Developer

We don't get a mem usage of 1.7-1.8GB. Our game usually is somewhat between 1GB-1.2GB or 1.2-1.4GB (later on with more characters in the game).

The video is great, but as we use the Unity Engine (C#/mono), we don't do any malloc(). So it's not really our fault, though if we find a repro-case, we'd happily report this to the Unity devs or see if we can find a workaround. 

It is a mystery why the OS does not start paging but crashes the software instead if one of those processes gets close to the 2GB mark. Of course, paging won't help if the app needs more than 2GB, but your crashes seem to occur once your user address space exceeds 2GB - which is not the same. All your background apps/services run under your user address space, not just our game.

Definately try the /3GB switch. Though we didn't see our game using more than 1.4GB of RAM. Is there a scenario where the game uses more than 2GB user address space?

We tried to reproduce the error with the process governor but the first part of the game works flawlessly (max Textures, 2xAA, FullHD). When do your crashes occur and what are your settings?

The crashes always occur in BatchDeleteObjects call and always at the same location:

55BC8C8A | je unityplayer.55BC8CE0                 |
55BC8C8C | lea ecx,dword ptr ds:[eax+eax*2]        |
55BC8C8F | mov eax,dword ptr ds:[esi+11C]          |
55BC8C95 | lea edx,dword ptr ds:[eax+ecx*2]        |
55BC8C98 | mov eax,dword ptr ds:[esi+10C]          |
55BC8C9E | movzx ecx,word ptr ds:[eax+edi*2]       |
55BC8CA2 | movzx eax,word ptr ds:[edx]             |
55BC8CA5 | shl eax,10                              |
55BC8CA8 | or ecx,eax                              |
55BC8CAA | mov eax,dword ptr ss:[ebp-10]           | <-- EAX is NULL here
55BC8CAD | mov dword ptr ds:[eax],ecx              | <-- Bret Hart is right!

So may be related to this Unity bug?

https://forum.unity.com/threads/batchdeleteobjects-crash-unity-5.321080/

Someone suggested to run a manual cleanup routine. Maybe you could try that?

I tried patching it to check for a null pointer and bail out, but then next times it comes with a pointer of 0x1000000, because it probably didn't clean up properly, so this is also pointless.

On my machine, it's enough to turn on highest resolution and Ultra HD Texture quality to immediately trigger it (by i.e. loading my last saved game now or opening a new game and leaving Bernards room). This always crashes it. If you want, I can give you TeamViewer access or remote debugging session to my test machine.

Developer

The bug report does not really fit into this scenario, as it is clearly linked to mobile, has been fixed and occured in a very old version of Unity which we are not using. Also, we can't try out the workarounds from the thread because they don't apply to our setup.

We suggest on your Win7 machine you should try the 4GB-Tuning (BCDEDIT /Set IncreaseUserVa 3072) or PAE (BCDEdit /set PAE ForceEnable). We cannot help with the crashes on XP, though.

Also, we are preparing an update which allows you to reduce the scene cache size. That may help, too.

Just a little note. I found debug symbols for Unity3D and therefore was able to find out that it crashes in  crnd::crn_unpacker::unpack_dxt5

Fortunately, this code seems to be available on the net:
https://github.com/toji/webgl-texture-utils/blob/master/crunch/crn_decomp.h

bool unpack_dxt5(uint8** pDst, uint32 dst_size_in_bytes, uint32 row_pitch_in_bytes, uint32 blocks_x, uint32 blocks_y, uint32 chunks_x, uint32 chunks_y);

So pDst is an array of pointers that gets filled by the unpacker, some of them being possibly NULL because allocation failed, as you suspected. 
In line 

uint8* CRND_RESTRICT pRow = pDst[f];

there needs to be a check:
if (!pRow) return false;
to fix the crash. I can add it in assembly code, maybe the game then will at least shut down properly.

I will try the method to expand memory in the evening, nevertheless the memory management of the application should be able to trim the cache automatically in order to not hit the 2GB barrier imho. So I'm looking forward to the new version which supports reduced cache size.

I now tried it with 3GB usermode address space, and now was able to play it through. Wow, what a great game, thank you! :-)

It took approx 2.3GB of memory during playing, so we definitely hit the 2GB barrier. Nevertheless fixing missing null-pointer checks couldn't hurt, maybe file a bug report to Unity developers, now that the issue is nailed down to a function.