Hi ! I am pretty much new to this community so sorry if this post has been made before. I purchased 4coder 4.1 yesterday and it worked just fine. Booted my pc up this morning and it just won't stop crashing when I launch it. Sometimes it will seem like it's opened up correctly but crashes as soon as I move my cursor over to it. Any ideas on what's going on ?

(Windows x64 build btw)

Did you modify any file from the custom layer ?

Did you try starting up from scratch (extracting the archive to a new folder) to see if it works ?

Can you build the custom layer, and try adding a breakpoint in the function custom_layer_init ?

If it crashes before reaching the breakpoint, you may want to report the issue on github and/or ask for help on the 4coder discord (the author of 4coder will most likely reply to you there).

If it reaches the breakpoint, let the application continue to see where it crashes, and we might be able to help you more with that information.

Hi. I have not modified anything regarding the custom layer. Extracting it from the zip and running it as new also seems to crash in the same manner. I'll try the breakpoint method and report back.

I added the breakpoint, saved the file and debugged the executable with Visual Studio and here is the result ;

Image

I have also noticed that the name of the exception is somewhat similar to what this community member had about 30 days ago on Github ;

https://github.com/4coder-editor/4coder/issues/306

This looks like an issue with the nvidia OpenGL driver (or how 4coder uses it). You should comment on the issue on git hub with your computer specs, and try to contact Allen Webster (twitter, discord or e-mail).

Yeah will do. I am going to upgrade my gpu drivers and check again.

Upgraded my gpu drivers (GTX 1080ti) rebooted and it's still the same. Debugged the program again and it still crashed on the same breakpoint. I don't understand why though as it worked fine the day that I bought it.

I used to work in a department full of developers going around bugs in OpenGL drivers for our 50000000 customers all day long without any end in sight. A game of whack-a-mole that didn't end until I wrote assembly code that was faster than the GPU and never broke down.

The fix is easy, just use memcpy instead of OpenGL for faster GUI rendering without crashes. There's really nothing to be gained from 3D accelerated hardware API's for a 2D interface. Doing nothing will always be faster than redundant number crunching (x = clamp(round(interpolate(multi-sample(rasterize(triangulate(x))))))) on beefy hardware.

Is there any way that I could actually implement that change on 4coder ?

Download this archive: https://download.qt.io/developmen...engl32sw-64-mesa_11_2_2-signed.7z
Extract and rename opengl32sw.dll to openg32.dll and place it next to 4ed.exe. DO NOT place it in C:\Windows\System32 folder. Place it only NEXT to 4ed.exe. This dll is from Mesa library that provides software implementation of OpenGL.

If you do not trust that dll, you can build it from source with instructions here: https://gist.github.com/mmozeiko/82ab8ddf349b70beee18a21f2ef0577c

Thank you for that. I have added the .dll in the folder of 4coder right where the executable is and it seems to have changed something but it still crashes. It takes a moment to do so and does not crash right away. I debugged it with the breakpoint added to the custom_layer_init and here is what I got ;

Image

EDIT - ignore this part
I would say that it like a bug with how 4coder uses OpenGL API - like not properly loading extension function pointer, or providing incorrect/uninitialized memory as input or similar. There's not much you can do unless you have 4coder source to debug it.
/EDIT

I missed part in screenshot where it shows error from nvoglv64.dll. That's still nvidia opengl. Either 4ed is not using opengl32.dll you provided, or this is some unrelated crash..

When crash happens - check Modules window in debugger. Does it show opengl32.dll from the location next to 4ed.exe?

Indeed. I exctracted the x64 again, put the .dll in the folder with it and tried to launch it only to find that it does the same thing. Although something interesting that I discovered is that the x86 version appears to be working fine after adding the .dll. I will work on it for a bit and report back if it crashes or behaves weirdly.

Oh, ok I will check that right now.