Bug with Font Shaders on many Intel Graphics Chips

[EVILEDACCOUNT]

When I try to launch the engine, it now errors out with the fallowing message.

failed to compile #version 150 core

//vertex position in vec2 vert;

//pass through to fragTexCoord in vec2 vertTexCoord;

//window res uniform vec2 resolution;

//pass to frag out vec2 fragTexCoord;

void main() { // convert the rectangle from pixels to 0.0 to 1.0 vec2 zeroToOne = vert / resolution;

// convert from 0->1 to 0->2 vec2 zeroToTwo = zeroToOne * 2.0;

// convert from 0->2 to -1->+1 (clipspace) vec2 clipSpace = zeroToTwo - 1.0;

fragTexCoord = vertTexCoord;

gl_Position = vec4(clipSpace vec2(1, -1), 0, 1); }\00: 0:1(10): error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, 3.00 ES, and 3.10 ES \00\00 goroutine 1 [running, locked to thread]: github.com/yuin/gopher-lua.(LState).PCall.func1(0xdddce8, 0xc0000b8630, 0xc0006fd8d8, 0x0, 0x0, 0x0) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/state.go:1975 +0x633 panic(0xcb1a40, 0xc000aac670) /usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2 github.com/K4thos/glfont.LoadFont(0xc0004ae5d0, 0x23, 0xc000000024, 0x140, 0xf0, 0x0, 0x0, 0x0) /code/go/pkg/mod/github.com/!k4thos/glfont@v0.0.0-20200628105132-91535547d8eb/font.go:48 +0x330 main.loadFntTtf(0xc0004b0080, 0xc0008d2160, 0x12, 0xc0008bc202, 0x1e, 0xffffffff) /code/src/font.go:345 +0xcb main.loadDefInfo(0xc0004b0080, 0xc0008d2160, 0x12, 0xc0006fcf30, 0xc0ffffffff) /code/src/font.go:320 +0x3fb main.loadFntV2(0xc0008d2160, 0x12, 0xffffffff, 0x0, 0xc46360, 0x599d01) /code/src/font.go:278 +0x301 main.loadFnt(0xc000773140, 0xd, 0xc0ffffffff, 0xd, 0x10, 0xc45f60) /code/src/font.go:49 +0xa7 main.systemScriptInit.func46(0xc0000b8630, 0x16ddbe0) /code/src/script.go:743 +0x87 github.com/yuin/gopher-lua.callGFunction(0xc0000b8630, 0x0, 0xc0002aa300) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/vm.go:202 +0x40 github.com/yuin/gopher-lua.init.3.func26(0xc0000b8630, 0xc07c140403, 0xc0001e50a0, 0x0) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/vm.go:817 +0x3ae github.com/yuin/gopher-lua.mainLoop(0xc0000b8630, 0xc0001e50a0) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/vm.go:31 +0xf0 github.com/yuin/gopher-lua.(LState).callR(0xc0000b8630, 0x1, 0x1, 0x15) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/state.go:1202 +0x248 github.com/yuin/gopher-lua.(LState).Call(...) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/state.go:1954 github.com/yuin/gopher-lua.loRequire(0xc0000b8630, 0xc0002bcec8) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/baselib.go:559 +0x567 github.com/yuin/gopher-lua.callGFunction(0xc0000b8630, 0x0, 0xc00027e4c0) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/vm.go:202 +0x40 github.com/yuin/gopher-lua.init.3.func26(0xc0000b8630, 0xc07c480402, 0xc0001e5000, 0x0) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/vm.go:817 +0x3ae github.com/yuin/gopher-lua.mainLoop(0xc0000b8630, 0xc0001e5000) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/vm.go:31 +0xf0 github.com/yuin/gopher-lua.(LState).callR(0xc0000b8630, 0x0, 0xffffffffffffffff, 0x0) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/state.go:1202 +0x248 github.com/yuin/gopher-lua.(LState).Call(...) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/state.go:1954 github.com/yuin/gopher-lua.(LState).PCall(0xc0000b8630, 0x0, 0xffffffffffffffff, 0x0, 0xe998e0, 0xc000e22c80) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/state.go:2017 +0x136 github.com/yuin/gopher-lua.(LState).DoFile(0xc0000b8630, 0xc000114800, 0x18, 0x0, 0x0) /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200603152657-dc2b0ca8b37e/auxlib.go:396 +0xb8 main.main() /code/src/main.go:487 +0x1b12

stack traceback: G: in function 'fontNew' external/script/main.lua:326: in function 'create' ./external/script/menu.lua:366: in function <./external/script/menu.lua:0> G: in function 'require' external/script/main.lua:1827: in main chunk

I also tried the 64-Bit windows 10 release and it works over there; but often crashes on start up; requiring about ten or so attempts to get the engine to open and stay open.

Otherwise, I am very happy to see that we can no go back with the Game-Pad and Arcade Sticks that use the Game-Pad with the new Pause Menu System. I have been looking forward to that. But, sadly, these two new launch problems exist.

[Orochikyocr]

You should change the title to your Linux distribution because new version 0.95 is working just fine in Ubuntu 19.04 and 20.04, also other Linux users in the discord server are just reporting the engine is working fine on their ends, so it is broken in your PC/Distro. When report any Linux trouble use your distro and the version for better bug tracking.

[EVILEDACCOUNT]

Trisquel GNU/Linux 9.0 test release.

It's based on Ubuntu 18.04 LTS. They just rip everything proprietary out.

The version of IKEMEN GO from about two months back ran just fine. So, it's something they've done sense May.

[EVILEDACCOUNT]

[Windblade-GR01]

So the issue is withe the GLFont dependency. I will get it fixed soon.

[EVILEDACCOUNT]

So, some updates.

1: This issue is not contained to just Trisquel 9.0. I recently installed Parabola on my systems and the same issue remains. Parabola is a rolling release based on Arch, but with proprietary software stripped out. As such, it is not an issue of software on my end being outdated as with a rolling release the software is constantly updated to be the newest versions.

2: This leads me to believe that the bug is instead centered around Intel Integrated Graphics. My specific chip set for my Desktop is the "Intel® HD Graphics 4600 (HSW GT2)."

3: I have changed the name of the topic to reflect the nature of the issue better.

4: I think Windblade and others are correct in that it is a GL Font Shaders issue due to the new pause menu being implemented. As the old release that I archived from back in May before the addition of the pause menu worked perfectly fine on Trisquel 9 and on Parabola wherein the new version crashes on both.

5: I am not using any custom screen packs currently and am downloading the version directly from AppVeyor as Ikemen Go still fails to compile from source on my machine when I fallow the instructions; error out when it runs get.sh. I am have had to rely on downloading the binaries manually. I'm simply unzipping the engine, running it, and it crashes. I'm not even adding stages or characters or anything. The vanilla download instantly crashes.

6: I just tried the newly rolled out AppVeyor release from ~19 hours ago just now and it still does the same thing.

I'm not sure what else that I can say to help with this. Gacel said he knew what the problem was and would be fixing it soon in the forums. I was hoping for a fix the next time AppVeyor rolled out an update. But, it didn't work.

[EVILEDACCOUNT]

Update.

1: Problem still persists in new version released from ~ 2 days ago.

2: I am even more convinced now that it is the GL Font Shaders combined with Intel and not the specific Operating System because there is a different user who posted in the forum who has the same bug in a system that is "for the most part based in Vista." To collaborate that, when I tried to launch the engine in windows 10 it took about ten launch attempts to get it to stay open once without crashing. I am not currently running windows 10 as I often try for the most part to avoid non-free, proprietary software and thus try to stay off windows as much as I can manage to. But, back when I had windows 10 installed, it still didn't launch reliably on windows 10 either.

[EVILEDACCOUNT]

New Version not modified.

New version modified.

Older version working. V0.94 from May 18Th 2020. Select Screen.

Older version working. V0.94 from May 18Th 2020. Game Play.

[EVILEDACCOUNT]

The issue seems centered around my Desktop's chip and or driver and changes made between May 18Th 2020 and July 13Th 2020. IKEMEN GO does run on my newer Intel Chip on my Laptop.

[averagehat]

I get the same error with the latest Macos binaries Macbook Pro Mojave 10.14.6

Intel Iris Plus Graphics 640 1536 MB

panic: failed to compile #version 150 core

//vertex position
in vec2 vert;

//pass through to fragTexCoord
in vec2 vertTexCoord;

//window res
uniform vec2 resolution;

//pass to frag
out vec2 fragTexCoord;

void main() {
   // convert the rectangle from pixels to 0.0 to 1.0
   vec2 zeroToOne = vert / resolution;

   // convert from 0->1 to 0->2
   vec2 zeroToTwo = zeroToOne * 2.0;

   // convert from 0->2 to -1->+1 (clipspace)
   vec2 clipSpace = zeroToTwo - 1.0;

   fragTexCoord = vertTexCoord;

   gl_Position = vec4(clipSpace * vec2(1, -1), 0, 1);
}: ERROR: 0:1: '' :  version '150' is not supported
ERROR: 0:1: '' : syntax error: #version

goroutine 1 [running, locked to thread]:
github.com/yuin/gopher-lua.(*LState).PCall.func1(0x45a9b18, 0xc0001c60b0, 0xc001ccb918, 0x0, 0x0, 0x0)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1980 +0x633
panic(0x4503700, 0xc001661ee0)
    /usr/lib/go-1.13/src/runtime/panic.go:679 +0x1b2
github.com/Windblade-GR01/glfont.LoadFont(0xc000256060, 0x23, 0x24, 0x140, 0xf0, 0x0, 0x0, 0x0)
    /code/go/pkg/mod/github.com/!windblade-!g!r01/glfont@v0.0.0-20200825224555-fc4d8149c6a0/font.go:48 +0x3bf
main.loadFntTtf(0xc001712880, 0xc001e3ea60, 0x12, 0xc0001e0202, 0x1e, 0x24)
    /code/src/font.go:346 +0x152
main.loadDefInfo(0xc001712880, 0xc001e3ea60, 0x12, 0xc001ccaf70, 0xc0ffffffff)
    /code/src/font.go:320 +0x3fb
main.loadFntV2(0xc001e3ea60, 0x12, 0xffffffff, 0x0, 0x44ac120, 0x40cff01)
    /code/src/font.go:278 +0x301
main.loadFnt(0xc00067c2d0, 0xd, 0xc0ffffffff, 0xd, 0x10, 0x44abd20)
    /code/src/font.go:49 +0xa7
main.systemScriptInit.func46(0xc0001c60b0, 0x4988d00)
    /code/src/script.go:743 +0x87
github.com/yuin/gopher-lua.callGFunction(0xc0001c60b0, 0x0, 0xc0002f8f80)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:202 +0x40
github.com/yuin/gopher-lua.init.3.func26(0xc0001c60b0, 0xc07c140403, 0xc0001ed0a0, 0x0)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:817 +0x3ae
github.com/yuin/gopher-lua.mainLoop(0xc0001c60b0, 0xc0001ed0a0)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:31 +0xf0
github.com/yuin/gopher-lua.(*LState).callR(0xc0001c60b0, 0x1, 0x1, 0x15)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1203 +0x248
github.com/yuin/gopher-lua.(*LState).Call(...)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1959
github.com/yuin/gopher-lua.loRequire(0xc0001c60b0, 0xc00030b7a8)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/baselib.go:559 +0x567
github.com/yuin/gopher-lua.callGFunction(0xc0001c60b0, 0x0, 0xc0002bb1c0)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:202 +0x40
github.com/yuin/gopher-lua.init.3.func26(0xc0001c60b0, 0xc07c480402, 0xc0001ed000, 0x0)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:817 +0x3ae
github.com/yuin/gopher-lua.mainLoop(0xc0001c60b0, 0xc0001ed000)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:31 +0xf0
github.com/yuin/gopher-lua.(*LState).callR(0xc0001c60b0, 0x0, 0xffffffffffffffff, 0x0)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1203 +0x248
github.com/yuin/gopher-lua.(*LState).Call(...)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1959
github.com/yuin/gopher-lua.(*LState).PCall(0xc0001c60b0, 0x0, 0xffffffffffffffff, 0x0, 0x464f6a0, 0xc001b40000)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:2022 +0x136
github.com/yuin/gopher-lua.(*LState).DoFile(0xc0001c60b0, 0xc0001c8700, 0x18, 0x1, 0x2)
    /code/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/auxlib.go:396 +0xb8
main.main()
    /code/src/main.go:481 +0x195e

stack traceback:
    [G]: in function 'fontNew'
    external/script/main.lua:326: in function 'create'
    ./external/script/menu.lua:366: in function <./external/script/menu.lua:0>
    [G]: in function 'require'
    external/script/main.lua:1827: in main chunk
    [G]: ?

goroutine 1 [running, locked to thread]:
main.main()
    /code/src/main.go:488 +0x2519

[averagehat]

I tried the solution posted here: https://mugenguild.com/forum/msg.2487639

of editing save/config.json: to "FontShaderVer": "130 core" this didn't fix the error (though it did change the error output to show that it tried #130)

I use 150 and other opengl versions all the time with no problems. If I am experiencing this with the standard mac intel chipset then the build probably isn't working for most macos users.

[averagehat]

@Windblade-GR01 Windblade-GR01

I tried different GLSL versions and rolling back glfont library changes, as well as different versions of go-gl. I have also tried building the older version which @EVILEDLIBRE mentioned as well as @K4thos 's version. None of these work (I had to try building them because I could find no pre-built binaries for them for mac). Also the lack of meaningful commit messages makes it harder.

Are there any previous mac binaries, or a way of toggling off glfont?

Please reopen this issue.

[Windblade-GR01]

I think I can add a way to toggle off GLFont.

[sodomon2]

@Windblade-GR01 Hi, I am running Ikemen-GO on AlpineLinux (musl) and I have the same problem

and wanted to know if there is already a solution

[MelodicCrypter]

Hi, @Windblade-GR01 , any solution to this one? I'm experiencing this on my mac version: 10.14.5

[EVILEDACCOUNT]

I think I can add a way to toggle off GLFont.

Has there been a solution made to this issue? Or, the ability to toggle off GLFont?

[EVILEDACCOUNT]

I have the fix! At least a workaround.

So, the problem is that Ikemen Go is a "context-unaware application." Which, from my understanding, means that it's not programmed to actually check which version of OpenGL you're running.

As a result, either the program (or maybe the OS?) defaults to running a version below what the Ikemen Go engine actually needs.

This means that even though you have a graphic card that can run the program, the program doesn't check to see if that's true and just assumes you don't and then reports a false error message instead because it's trying to run the program as OpenGL 3.0 for "maximum compatibility." Which is ironic, because that breaks the program.

So, here is what you actually need to do. You need to open the program through a Terminal and add this string in front of the program to force the program to realize that your card can actually run it.

So, first, navigate your Terminal to the folder your Ikemen Go binary is stored in.

cd /home/username/Downloads/Ikemen_Go_Linux

Or, you know, wherever you have your program stored.

Then, run the fallowing command in Terminal.

MESA_GL_VERSION_OVERRIDE=4.3 ./Ikemen_GO_linux

For mac people, you'll have to edit this line to tell it to open the mac binary.

This will force the engine to open with OpenGL 4.3 instead of 3.0 and the engine will open without crashing and run perfectly fine. At least, that's what fixed it for me.

I was able to just use 4.3 like in the example to get it working. You might have to poke around with versions until you find something your card supports and Ikemen Go can run on.

I don't know programming, but what needs to be done now on the programming side of things is to tell the engine to actually check which version of OpenGL you have so that it can run. I don't know if there is a way to have it probe the OS and get that information or what. But, something about Ikemen Go doesn't bother to check, apparently.

This is where I sourced the solution from.

https://askubuntu.com/questions/850900/why-is-my-opengl-version-stuck-at-3-0-despite-new-hardware-software

[EVILEDACCOUNT]

I have found a solution to this problem that works for me. Maybe it will work for you too.

"export MESA_GL_VERSION_OVERRIDE=4.5

If the problem is solved, store this for the user in ~/.bashrc or system wide in /etc/profile If saving changes is not sufficient, use rootcopy. Check if being set with printenv"

I found it from here.

https://forum.porteus.org/viewtopic.php?t=9109

So, here is what I did. I did not do user, instead I did system.

I did sudo nano /etc/profile

Then, at the very bottom, I added the line "export MESA_GL_VERSION_OVERRIDE=4.3"

I did 4.3 instead of 4.5 because 4.3 is what was working for me in Konsole.

I then restarted my computer.

IKEMEN GO now launches when double clicked within its folder without having to open it from Terminal with "MESA_GL_VERSION_OVERRIDE=4.3" in front of it every time because the whole system is now told to open programs in 4.3 as default instead of 3.0. Minetest also runs under 4.3 instead of 3.0 now. This is how I know it's for the whole system. IKEMEN GO now launches, where before it didn't. Minetest did launch, and still does. But, once in Minetest, the top of the window shows what version of Open GL it's running and now it says 4.3 instead of 3.0.

I don't know if this will work for mac computers. I don't know if this is caused by IKEMEN GO or the Operating System or the Driver.

I will say that this is an important issue to fix as it lets people run the program on GNU + Linux Operating Systems and older hardware that is completely capable of running it.

My best guess, at this point, is that for whatever reason the modern OS or graphic driver doesn't really understand by default what these older Intel Chips are capable of graphically and so chooses to run under 3.0 for "maximum compatibility" even thought the chip is actually capable of far more.

So, again, the solution for me was simple. Simply add that line to /etc/profile at the bottom and reboot and the entire system now forces programs to open in Open GL 4.3 instead of the 3.0 default.

I don't know if anything can be done IKEMEN GO side to probe the system and correct this. But, considering it's an OS default that is getting in the way I don't have high hopes that there is anything that can be done. If I remember correctly, I think the Konsole itself would report 3.0 as the version by default because of the badly chosen default. So, even if IKEMEN GO did or does probe the OS, the OS is lying to it and telling it 3.0 when higher versions work just fine. So, maybe the only solution to this is to manually set a system level override like I did. Or, a user level one like I didn't try yet.

[Windblade-GR01]

I'll investigate to see what could be done to fix it

[Engooneer]

I have the fix! At least a workaround.

So, the problem is that Ikemen Go is a "context-unaware application." Which, from my understanding, means that it's not programmed to actually check which version of OpenGL you're running.

As a result, either the program (or maybe the OS?) defaults to running a version below what the Ikemen Go engine actually needs.

This means that even though you have a graphic card that can run the program, the program doesn't check to see if that's true and just assumes you don't and then reports a false error message instead because it's trying to run the program as OpenGL 3.0 for "maximum compatibility." Which is ironic, because that breaks the program.

So, here is what you actually need to do. You need to open the program through a Terminal and add this string in front of the program to force the program to realize that your card can actually run it.

So, first, navigate your Terminal to the folder your Ikemen Go binary is stored in.

cd /home/username/Downloads/Ikemen_Go_Linux

Or, you know, wherever you have your program stored.

Then, run the fallowing command in Terminal.

MESA_GL_VERSION_OVERRIDE=4.3 ./Ikemen_GO_linux

For mac people, you'll have to edit this line to tell it to open the mac binary.

This will force the engine to open with OpenGL 4.3 instead of 3.0 and the engine will open without crashing and run perfectly fine. At least, that's what fixed it for me.

I was able to just use 4.3 like in the example to get it working. You might have to poke around with versions until you find something your card supports and Ikemen Go can run on.

I don't know programming, but what needs to be done now on the programming side of things is to tell the engine to actually check which version of OpenGL you have so that it can run. I don't know if there is a way to have it probe the OS and get that information or what. But, something about Ikemen Go doesn't bother to check, apparently.

This is where I sourced the solution from.

https://askubuntu.com/questions/850900/why-is-my-opengl-version-stuck-at-3-0-despite-new-hardware-software

I use a MacBook Air, and I tried all of this and it still returned with the same error. the error that shows for me is as follows:

failed to compile #version 150 core

//vertex position in vec2 vert;

//pass through to fragTexCoord in vec2 vertTexCoord;

//window res uniform vec2 resolution;

//pass to frag out vec2 fragTexCoord;

void main() { // convert the rectangle from pixels to 0.0 to 1.0 vec2 zeroToOne = vert / resolution;

// convert from 0->1 to 0->2 vec2 zeroToTwo = zeroToOne * 2.0;

// convert from 0->2 to -1->+1 (clipspace) vec2 clipSpace = zeroToTwo - 1.0;

fragTexCoord = vertTexCoord;

gl_Position = vec4(clipSpace * vec2(1, -1), 0, 1); }

(sorry if I'm bad at formatting the error, I'm new to GitHub)

[EVILEDACCOUNT]

I have the fix! At least a workaround. So, the problem is that Ikemen Go is a "context-unaware application." Which, from my understanding, means that it's not programmed to actually check which version of OpenGL you're running. As a result, either the program (or maybe the OS?) defaults to running a version below what the Ikemen Go engine actually needs. This means that even though you have a graphic card that can run the program, the program doesn't check to see if that's true and just assumes you don't and then reports a false error message instead because it's trying to run the program as OpenGL 3.0 for "maximum compatibility." Which is ironic, because that breaks the program. So, here is what you actually need to do. You need to open the program through a Terminal and add this string in front of the program to force the program to realize that your card can actually run it. So, first, navigate your Terminal to the folder your Ikemen Go binary is stored in. cd /home/username/Downloads/Ikemen_Go_Linux Or, you know, wherever you have your program stored. Then, run the fallowing command in Terminal. MESA_GL_VERSION_OVERRIDE=4.3 ./Ikemen_GO_linux For mac people, you'll have to edit this line to tell it to open the mac binary. This will force the engine to open with OpenGL 4.3 instead of 3.0 and the engine will open without crashing and run perfectly fine. At least, that's what fixed it for me. I was able to just use 4.3 like in the example to get it working. You might have to poke around with versions until you find something your card supports and Ikemen Go can run on. I don't know programming, but what needs to be done now on the programming side of things is to tell the engine to actually check which version of OpenGL you have so that it can run. I don't know if there is a way to have it probe the OS and get that information or what. But, something about Ikemen Go doesn't bother to check, apparently. This is where I sourced the solution from. https://askubuntu.com/questions/850900/why-is-my-opengl-version-stuck-at-3-0-despite-new-hardware-software

I use a MacBook Air, and I tried all of this and it still returned with the same error. the error that shows for me is as follows:

failed to compile #version 150 core

//vertex position in vec2 vert;

//pass through to fragTexCoord in vec2 vertTexCoord;

//window res uniform vec2 resolution;

//pass to frag out vec2 fragTexCoord;

void main() { // convert the rectangle from pixels to 0.0 to 1.0 vec2 zeroToOne = vert / resolution;

// convert from 0->1 to 0->2 vec2 zeroToTwo = zeroToOne * 2.0;

// convert from 0->2 to -1->+1 (clipspace) vec2 clipSpace = zeroToTwo - 1.0;

fragTexCoord = vertTexCoord;

gl_Position = vec4(clipSpace * vec2(1, -1), 0, 1); }

(sorry if I'm bad at formatting the error, I'm new to GitHub)

Then I am sorry for you. I researched and developed the work around on a GNU + Linux system. I do not own any macs. My hope was that the process that worked for me would be similar enough to work on a mac. Thank you for letting me know that it didn't.

Maybe try researching how to override the GPL version of a program when you launch it on a mac. There might be different instruction for how to do this. Otherwise, maybe try different versions of OpenGL instead of just 4.3?

[K4thos]

@EVILEDLIBRE, can you compile engine if I provide you all the necessary files? I can't compile it for you since I'm on windows (changing environment variables to GOARCH=amd64, GOOS=linux, results in compilation errors on my pc and I'm not going to install linux just to test it) There is a chance that these changes will fix this problem with Intel Graphics Chips on linux/mac.

[EVILEDACCOUNT]

@EVILEDLIBRE, can you compile engine if I provide you all the necessary files? I can't compile it for you since I'm on windows (changing environment variables to GOARCH=amd64, GOOS=linux, results in compilation errors on my pc and I'm not going to install linux just to test it) There is a chance that these changes will fix this problem with Intel Graphics Chips on linux/mac.

@K4thos

I can try. But, I only know how to do basic compile. So, you'd have to guide me through what to do.

1: Which source code will I be compiling? The stable version from Windblade release 0.97.0 or The source Master from your repo or the source master from the Windeblade repo? Does it matter which one?

2: All I do to compile is the fallowing. I use Konsole to move into the build directory. Then I run 'bash get.sh' and then I run 'bash build.sh' Then I copy the generated binary from the bin folder out into the main folder. Then I move the screen pack from the screen pack repo into the main folder and then I run the engine.

3: You mention changing the environment variables. Is that something that you do from your side or that I do? If I do this, where do I do it? In the Konsole command or in the source code somewhere? My best guess is in the Konsole command, but I have no idea how that would be formatted. Could you provide an example please?

Would it look something like this?

bash GOARCH=amd64 GOOS=linux build.sh

Or this?

bash build.sh GOARCH=amd64 GOOS=linux

I don't really know how to program so I don't really understand a lot about compiling. I mostly compile so that I can build from source and so that I can try out the newest updates before they are declared stable. But, I don't know anything about programming or how to change environmental variables.

Please advise so that I can see if this works. Thank you.

[K4thos]

I can try. But, I only know how to do basic compile. So, you'd have to guide me through what to do.

I'm not a linux user, so won't be able to guide you. If you don't have experience with compiling than let's wait for Gacel to prepare linux build for testing (he already has files with those changes). I hoped to test it before 0.98 hits but in this case, even if those changes would work, they will have to wait for next one anyway (0.98 is expected to come out today), so there is no need to rush it.

[EVILEDACCOUNT]

@K4thos

I don't have experience compiling outside of a direct way.

I tried compiling all 3 code bases (stable, your master, and Gacel's master) and none of them have the problem fixed by default. The engine still crashes unless told to work manually with "MESA_GL_VERSION_OVERRIDE=3.0 ./Ikemen_GO_Linux" and then they work fine like always.

I don't think I will have to change "GOARCH=amd64 and or GOOS=linux" because I am already on a AMD64 Computer running a GNU + Linux Operating System. So, my default environment is already what I'm compiling for.

So, if you're asking me if compiling the newest versions of your repo or Gacel's repo fixes the problem; then the answer is no. None of the changes either of you have made have fixed the problem in any way at all.

https://github.com/Windblade-GR01/Ikemen-GO/issues/299

xx1182 Has what might be the answer to this problem at the bottom of this issue page that I linked. It appears Ikemen doesn't actually have a "Max Core Profile Version" and this might be why it's defaulting to wrong settings when ran. This is the most promising suggestion I've heard for where to start to look into this problem and have wondered if anyone else has tried looking into this.

I mean, fundamentally, the problem isn't 'with the engine' in a broad sense. The engine opens and runs just fine. The problem is that the engine picks the wrong GLSL OpenGL settings and lies to the Operating System about it. Because of this, the engine then crashes because it falls for the trick of its own lies. So, it's not that the engine can't run. It's that the engine is lying to the OS and confusing itself into thinking that it can't run when it so very clearly and easily can run just fine and dandy.

So, what fallows it my best guess at all of this from looking into the profile settings xx1182 has pointed out (or, rather, the lack there of, of the profile settings) and realizing that this may very well be the answer to the problem. The engine isn't told what to do for this, and tells the OS nothing because nothing is entered. The OS then tells the engine 'Well, sense you don't know what you need to run, try running the lowest supported version of OpenGL that your little graphic chip can run.' Because of this, the old Intel chips crawl way back to versions of OpenGL that can't support Ikemen and tell the engine to try running that. The engine does, fails, and then lies to the user and says it can't run and has a core dump.

This is so clearly a profile mismanagement issue because when told what profile to load with manually, the engine opens up and runs just fine. So, somehow, somewhere in Ikemen's code it doesn't know how to figure out what profile to launch into. I think xx1182 is right in that the engine itself just leaves this variable blank and that this might very well be what's causing the issue. These older graphic chips support older standards and default too far back when the engine fails to supply any profile variable at all. This is why it only effects these old / low end chips. Because newer chips don't default back far enough to be too old to run Ikemen while these chips do.

This is why my modern Intel chip works just fine without any manual intervention. The chip itself probably depreciated the older profiles that nobody uses anymore. Whereas my old Desktop can still run these ancient profiles. Given no direction from Ikemen for which profile to use, it tries the oldest one it knows and falls over itself. That's the same thing happening on newer chips and cards too, it's just the oldest thing they know is new enough to run Ikemen. But, in either situation, all chips are trying the oldest thing they know because Ikemen doesn't tell them what to try.

[K4thos]

I tried compiling all 3 code bases

These changes are not in master branches (it's test branch on my repo, using modified glFont library also hosted on my github).

It appears Ikemen doesn't actually have a "Max Core Profile Version" and this might be why it's defaulting to wrong settings when ran.

I don't know if we can do much about it from within app since as far as I know context profiles can be defined only for OpenGL 3.x+ and we're aiming for OpenGL 2.1 support.

Anyway I've installed ubuntu on virtual machine, so was able to prepare linux build for you. Try this:

1. Download: Ikemen_GO_test.zip
2. Start the engine from terminal (don't change any config.json setting beforehand). If it crashes (most likely it will) paste here what is printed in terminal for following strings (should show up before the error):
   • OpenGL version
   • OpenGL shading language version
3. open save/config.json, change "FontShaderVer": 150 to "FontShaderVer": 120 - if it works start the match, select kfm, open pause menu and see if command list is rendered correctly (it uses glFont library that is cauing the crash)
4. Even if 120 setting will work also try one printed by "OpenGL shading language version" - for example if it's 1.40 than use "FontShaderVer": 140

[EVILEDACCOUNT]

@K4thos

Answer to Step 2:

OpenGL version 3.0 Mesa 21.1.6 OpenGL shading language version 1.30

Answer to Step 3:

The change to Font Shader Version 120 fixes the issue and allows Ikemen to open. I think the command list is rendering correctly. Here are screen shots of it.

Answer to Step 4:

Version 130 works. Version 140 does not work.

Version 130 matches my version 1.30 print out from Step 2.

Additional Information: Thank you for looking into this. This is directly related as this issue did not exist before the Pause Menu was added. If you look back at my old posts, I detail that fact with screen shots. I love the Pause Menu and it needs to stay. But, I think this is exactly what the issue is.

I hope that the information I have provided helps solve this issue for everyone. If you need any more testing done please let me know and I will try to help. Thank you.

[EVILEDACCOUNT]

@K4thos

I just downloaded, compiled, and ran the new version from your main repo where you fixed the glFont shader. It works perfectly! Thank you so much for fixing this! This will allow a lot more people to play now.

I do not know if I should close this issue page yet or not; because I don't know if this has fixed everything for the mac people or not. I think that it should. But, it would be nice if some of the mac people here can try it out and see if it works for them too now.

I don't own any macs so I am not able to test this.

[K4thos]

np, thanks for testing. Yeah, some confirmation from mac user who had this problem, once 0.98 is released, would be nice.

[EVILEDACCOUNT]

Thank you for fixing this. It was no problem at all helping. If you need help testing more things I could try that too. I'll leave this post open for now; that way we can wait to see if this fixes it for the mac people too.

[Christian-Nerd]

https://i.imgur.com/wcbgjFj.png The problem isn't solve on my macbook air 2017(Version 12.6.5) you get this error.