The Forum

[quote="FINITO"]If you have more than one monitor then that is likely the issue. I have to manually create patches for different Windows versions and there is too many to cover them all (I only create patches for versions I have myself or for versions of files that players have sent me).[/quote]

[quote="FINITO"][quote="SOMAWIZARD"]Fin There are normally two yearly mainstream releases of windows 10 with 1803 being the most recent (excluding special builds like LTSB and insider builds). It would be nice to understand how and why technically soma is affected by a change in the windows build, maybe there is something the community can help with, even if it means getting you the files in an automated way so when a new release drops via windows update that a patch can be deployed as soon as practically possible. [/quote] Any time that they update GDI32, Soma obviously uses the 32bit version of it. A major release of Windows 10 split GDI32 into gdi32.dll and gdi32full.dll (gdi32full.dll is the one patch is applied to). It is not just major releases that it gets changed and it is a problem in every Windows version that Soma currently supports so Windows XP, Vista, 7, 8, 8.1, and 10. Still don't know exactly what causes the issue have only been able to patch the gdi32 code loaded by Soma at runtime to null the effect (for some reason the code ends up in a loop for long periods of time causing the stalls). For GDI32full.DLL Version 10.0.16299.98 Windows 10 the offsets for code to NOP is at gdi32+94D10h and gdi32+94D1Ch. [b]The assembly is usually something like this:[/b] 55815D10 0F85 ED000000 JNZ gdi32f_1.55815E03 ; [b]NOP this[/b] 55815D16 F7C3 00000100 TEST EBX,10000 55815D1C 0F84 E1000000 JE gdi32f_1.55815E03 ; [b]NOP this[/b] Or: 7D697F0B . 0F85 C1A00000 JNZ gdi32_1.7D6A1FD2 ; [b]NOP this[/b] 7D697F11 . 855D F8 TEST DWORD PTR SS:[EBP-8],EBX 7D697F14 . 0F84 B8A00000 JE gdi32_1.7D6A1FD2 ; [b]NOP this[/b] [b]Full block of assembly code that I use to find it in various versions of the dll across windows versions:[/b] 7645731F . 0F85 E7E90000 JNZ GDI32.76465D0C 76457325 . 8B58 04 MOV EBX,DWORD PTR DS:[EAX+4] 76457328 . 85DB TEST EBX,EBX 7645732A . 0F84 646F0400 JE GDI32.7649E294 76457330 . 8B4D F4 MOV ECX,DWORD PTR SS:[EBP-C] 76457333 > 8B43 20 MOV EAX,DWORD PTR DS:[EBX+20] 76457336 . 0B43 24 OR EAX,DWORD PTR DS:[EBX+24] 76457339 0F85 396F0400 JNZ GDI32.7649E278 ; [b]NOP THIS JNZ[/b] 7645733F F7C1 00000100 TEST ECX,10000 76457345 0F84 2D6F0400 JE GDI32.7649E278 ; [b]NOP THIS JE[/b] 7645734B > D943 28 FLD DWORD PTR DS:[EBX+28] 7645734E . 8B55 0C MOV EDX,DWORD PTR SS:[EBP+C] 76457351 . D982 B8000000 FLD DWORD PTR DS:[EDX+B8] 76457357 . DAE9 FUCOMPP 76457359 . DFE0 FSTSW AX 7645735B . F6C4 44 TEST AH,44 7645735E . 0F8A 266F0400 JPE GDI32.7649E28A 76457364 . D943 2C FLD DWORD PTR DS:[EBX+2C] 76457367 . D982 C4000000 FLD DWORD PTR DS:[EDX+C4] 7645736D . DAE9 FUCOMPP The problem is in a function called by GetFontRealizationInfo and GetTextMetrics. So it is something to do with calculating the size of fonts. I have not yet debugged the code while using only a single monitor which is something I need to do to try see if I can notice what the difference is in execution of the code between single monitor and multiple.[/quote]