I.K.E.M.E.N GO on Raspberry Pi 4 [Now with an Install Guide!]

SuperFromND

So a few hours after I made my last post, Gacel pointed out that I was compiling using Go 1.11, since that's the version of Go that you get when using apt-get install. However, it turns out the latest version of Go is 1.16, so he suggested I install that instead. After a tiny bit of fiddling around with Linux (and a slight modification to the build_cmpt.sh script since, for some reason, shell scripts didn't acknowledge my manual Golang installation) I compiled the executable again and... it crashed. But it crashed slightly differently than before:

pi@raspberrypi:~/Desktop/Stuff/Ikemen-GO/bin $ sudo ./Ikemen_GO_linux 
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x6d610071 pc=0xb600be44]
 
runtime stack:
runtime.throw(0x542794, 0x2a)
	/usr/local/go/src/runtime/panic.go:1117 +0x5c
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:718 +0x224
 
goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x4a2c90, 0x2aedb90, 0x289bfb0)
	/usr/local/go/src/runtime/cgocall.go:154 +0x5c fp=0x2aedb78 sp=0x2aedb60 pc=0x52490
github.com/sqweek/dialog._Cfunc_msgdlg(0x0, 0x0, 0x3, 0x1, 0x8d2ad550, 0x0)
	_cgo_gotypes.go:404 +0x34 fp=0x2aedb8c sp=0x2aedb78 pc=0x228db8
github.com/sqweek/dialog.runMsgDlg(0x52426f, 0x5, 0x0, 0x3, 0x1, 0x2aeddcc, 0x0)
	/root/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs_linux.go:34 +0x90 fp=0x2aedbd8 sp=0x2aedb8c pc=0x228fe8
github.com/sqweek/dialog.(*MsgBuilder).error(...)
	/root/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs_linux.go:51
github.com/sqweek/dialog.(*MsgBuilder).Error(...)
	/root/go/pkg/mod/github.com/sqweek/dialog@v0.0.0-20200911184034-8a3d98e8211d/dlgs.go:61
main.main()
	/home/pi/Desktop/Stuff/Ikemen-GO/src/main.go:94 +0x58c fp=0x2aedfb8 sp=0x2aedbd8 pc=0x377750
runtime.main()
	/usr/local/go/src/runtime/proc.go:225 +0x26c fp=0x2aedfe4 sp=0x2aedfb8 pc=0x8766c
runtime.goexit()
	/usr/local/go/src/runtime/asm_arm.s:841 +0x4 fp=0x2aedfe4 sp=0x2aedfe4 pc=0xb7cbc
 
goroutine 4 [sleep]:
time.Sleep(0x989680, 0x0)
	/usr/local/go/src/runtime/time.go:193 +0x100
main.(*System).soundWrite(0x7af798)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/system.go:661 +0x354
created by main.(*System).audioOpen
	/home/pi/Desktop/Stuff/Ikemen-GO/src/system.go:649 +0xc4
 
goroutine 20 [syscall]:
github.com/hajimehoshi/oto._Cfunc_snd_pcm_writei(0x9c8836a8, 0x35a8000, 0x5be, 0x0)
	_cgo_gotypes.go:173 +0x34
github.com/hajimehoshi/oto.(*driver).TryWrite.func1(0x208e300, 0x2208000)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/driver_linux.go:143 +0xb4
github.com/hajimehoshi/oto.(*driver).TryWrite(0x208e300, 0x22080a8, 0x58, 0x7f58, 0x0, 0x0, 0x0)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/driver_linux.go:143 +0x15c
github.com/hajimehoshi/oto.(*driverWriter).Write(0x20d2060, 0x2208000, 0x100, 0x8000, 0x0, 0x0, 0x0)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/context.go:148 +0xe0
io.copyBuffer(0x5cecd8, 0x20d2060, 0x5cecec, 0x2092300, 0x2208000, 0x8000, 0x8000, 0x0, 0x0, 0x0, ...)
	/usr/local/go/src/io/io.go:425 +0x1c0
io.Copy(...)
	/usr/local/go/src/io/io.go:382
github.com/hajimehoshi/oto.NewContext.func1(0x20d04e0)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/context.go:85 +0x58
created by github.com/hajimehoshi/oto.NewContext
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/context.go:84 +0x1e8
 
goroutine 21 [select]:
io.(*pipe).Write(0x2090240, 0x21dce48, 0x16a0, 0x16a0, 0x2e48, 0x0, 0x0)
	/usr/local/go/src/io/pipe.go:94 +0x148
io.(*PipeWriter).Write(0x21c62c8, 0x21da000, 0x44e8, 0x44e8, 0x113a, 0x1, 0x0)
	/usr/local/go/src/io/pipe.go:163 +0x38
github.com/hajimehoshi/oto.(*Player).Write(...)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/player.go:60
github.com/faiface/beep/speaker.update()
	/root/go/pkg/mod/github.com/faiface/beep@v1.0.2/speaker/speaker.go:129 +0x190
github.com/faiface/beep/speaker.Init.func1()
	/root/go/pkg/mod/github.com/faiface/beep@v1.0.2/speaker/speaker.go:52 +0x18
created by github.com/faiface/beep/speaker.Init
	/root/go/pkg/mod/github.com/faiface/beep@v1.0.2/speaker/speaker.go:48 +0x1d4
 
goroutine 22 [syscall]:
syscall.Syscall(0x3, 0x0, 0x213a000, 0x1000, 0x1154ec, 0xff800000, 0x7ff)
	/usr/local/go/src/syscall/asm_linux_arm.s:14 +0x8
syscall.read(0x0, 0x213a000, 0x1000, 0x1000, 0x0, 0x1, 0x1)
	/usr/local/go/src/syscall/zsyscall_linux_arm.go:686 +0x40
syscall.Read(...)
	/usr/local/go/src/syscall/syscall_unix.go:187
internal/poll.ignoringEINTRIO(...)
	/usr/local/go/src/internal/poll/fd_unix.go:581
internal/poll.(*FD).Read(0x2070000, 0x213a000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
	/usr/local/go/src/internal/poll/fd_unix.go:162 +0x118
os.(*File).read(...)
	/usr/local/go/src/os/file_posix.go:31
os.(*File).Read(0x2010178, 0x213a000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
	/usr/local/go/src/os/file.go:117 +0x5c
bufio.(*Scanner).Scan(0x20287a4, 0x0)
	/usr/local/go/src/bufio/scan.go:214 +0x88
main.(*System).init.func1(0x7af798)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/system.go:546 +0x9c
created by main.(*System).init
	/home/pi/Desktop/Stuff/Ikemen-GO/src/system.go:544 +0x5c4

Just parsing the log, I noticed the difference (aside from some hex values and routine numbers) was from a section mentioning the intro, so I assumed the problem was related to IKEMEN's intro cutscene included in the default motif. Another fellow in the IKEMEN Discord named Amavect chimed in and told me to check Ikemen.log, thinking that it might be a problem with the LUA code that IKEMEN also uses. After opening the log, this is what I saw:

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);
} : 0:1(10): error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, 1.00 ES, and 3.00 ES
  
goroutine 1 [running, locked to thread]:
github.com/yuin/gopher-lua.(*LState).PCall.func1(0x54a358, 0x1e16000, 0x2cb5bd0, 0x0, 0x0, 0x0)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1980 +0x4fc
panic(0x4d81b8, 0x2280778)
	/usr/local/go/src/runtime/panic.go:965 +0x174
github.com/Windblade-GR01/glfont.LoadFont(0x2ca4c60, 0x23, 0x1b, 0x140, 0xf0, 0x0, 0x0, 0x0)
	/root/go/pkg/mod/github.com/!windblade-!g!r01/glfont@v0.0.0-20200825224555-fc4d8149c6a0/font.go:48 +0x2f4
main.loadFntTtf(0x2a38c30, 0x2261f98, 0x12, 0x2a504c2, 0x1e, 0x1b)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/font.go:340 +0x120
main.loadDefInfo(0x2a38c30, 0x2261f98, 0x12, 0x2cb5728, 0xffffffff)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/font.go:314 +0x370
main.loadFntV2(0x2261f98, 0x12, 0xffffffff, 0x0, 0x24b2480, 0xcaa4c)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/font.go:275 +0x25c
main.loadFnt(0x24c9f90, 0xd, 0xffffffff, 0xd, 0x8, 0x4d3110)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/font.go:49 +0x70
main.systemScriptInit.func53(0x1e16000, 0x2)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/script.go:766 +0x6c
github.com/yuin/gopher-lua.callGFunction(0x1e16000, 0x0, 0x1e69460)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:202 +0x30
github.com/yuin/gopher-lua.init.3.func26(0x1e16000, 0x7c100403, 0x1e18050, 0x0)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:817 +0x330
github.com/yuin/gopher-lua.mainLoop(0x1e16000, 0x1e18050)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:31 +0xdc
github.com/yuin/gopher-lua.(*LState).callR(0x1e16000, 0x1, 0x1, 0x17)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1203 +0x1b8
github.com/yuin/gopher-lua.(*LState).Call(...)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1959
github.com/yuin/gopher-lua.loRequire(0x1e16000, 0x2a)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/baselib.go:559 +0x46c
github.com/yuin/gopher-lua.callGFunction(0x1e16000, 0x0, 0x1e13d20)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:202 +0x30
github.com/yuin/gopher-lua.init.3.func26(0x1e16000, 0x7c500402, 0x1e18000, 0x0)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:817 +0x330
github.com/yuin/gopher-lua.mainLoop(0x1e16000, 0x1e18000)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:31 +0xdc
github.com/yuin/gopher-lua.(*LState).callR(0x1e16000, 0x0, 0xffffffff, 0x0)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1203 +0x1b8
github.com/yuin/gopher-lua.(*LState).Call(...)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1959
github.com/yuin/gopher-lua.(*LState).PCall(0x1e16000, 0x0, 0xffffffff, 0x0, 0x5ced50, 0x311e0a0)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:2022 +0xec
github.com/yuin/gopher-lua.(*LState).DoFile(0x1e16000, 0x1cb65b8, 0x18, 0x1e16000, 0xf)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/auxlib.go:396 +0x94
main.main()
	/home/pi/Desktop/Stuff/Ikemen-GO/src/main.go:87 +0x150

stack traceback:
	[G]: in function 'fontNew'
	external/script/main.lua:400: in function <external/script/main.lua:375>
	(tailcall): ?
	./external/script/menu.lua:374: in function <./external/script/menu.lua:0>
	[G]: in function 'require'
	external/script/main.lua:2123: in main chunk
	[G]: ?

While that last bit does mention LUA, the error at the very top of the log got me intrigued, so I searched for it on the IKEMEN-GO issues repository, which lead me to discover this issue, and a surprisingly detailed explanation and workaround posted by EVILEDLIBRE (great username by the way!), so I decided to give that workaround a try, and...

Windblade-GR01-IKEMEN GO on Pi 4.jpg

It got to the main menu, holy $#!&.

Interestingly, the issues that were present in LucasFebaits's fork are all here: the crashing on 32-bit Raspbian, the palette corruption, and even a brand new bug where inputs are seemingly triggering eachother (so for example, pressing down would also trigger a button press, making it impossible to navigate the menu).

But even in this largely nonfunctional, highly broken state, this is a GIGANTIC break from the constant no-hoper crash logs I kept running into, and definetly motivates me to keep pursuing this.

Addendum

Here's a quick summary of what does and does not work on Windblade's fork on a 32-bit-OS Pi 4, now that I've gotten it to compile:

Screenpack audio appears to be working just fine, surprisingly
On my wireless USB keyboard, inputs were registering eachother for some reason; on my Rock Candy X360 pad, this overlap did not occur but IKEMEN refused to read most of the buttons (the D-pad buttons were rotated 90 degrees and Left didn't work at all, but A and B seemed to work perfectly fine; it's worth noting that IKEMEN's input system experiences strange behavior even on Windows and a rewrite of that has been planned for a while)
Trying to start a fight crashes with the following log:

unexpected fault address 0x0
fatal error: fault
[signal SIGBUS: bus error code=0x1 addr=0x0 pc=0x2ae630]

goroutine 1 [running, locked to thread]:
runtime.throw(0x5243e6, 0x5)
	/usr/local/go/src/runtime/panic.go:1117 +0x5c fp=0x2adb430 sp=0x2adb41c pc=0x84d48
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:731 +0x210 fp=0x2adb448 sp=0x2adb430 pc=0x9bfc8
main.(*BytecodeStack).PushF(...)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:566
main.BytecodeExp.run(0x39ab3a8, 0x5, 0x38, 0x35e2000, 0x1c, 0xa, 0x35e2000)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:965 +0x7dc fp=0x2adb6b8 sp=0x2adb44c pc=0x2ae630
main.BytecodeExp.evalF(...)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:1858
main.mapSet.Run.func1(0x4d5201, 0x281e000, 0x1, 0x1, 0x3cc2201)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:6709 +0xd4 fp=0x2adb6e8 sp=0x2adb6b8 pc=0x3bf45c
main.StateControllerBase.run(0x39ab380, 0x35, 0x60, 0x35e2000, 0x2adb738)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:2064 +0x11c fp=0x2adb70c sp=0x2adb6e8 pc=0x2c6c80
main.mapSet.Run(0x39ab380, 0x35, 0x60, 0x35e2000, 0x0, 0x0, 0x0, 0x3ff00000)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:6704 +0x9c fp=0x2adb750 sp=0x2adb70c pc=0x2d0d88
main.(*mapSet).Run(0x295e6c0, 0x35e2000, 0x0, 0x0, 0x0, 0x7ec1e0)
	<autogenerated>:1 +0x64 fp=0x2adb774 sp=0x2adb750 pc=0x424608
main.StateBlock.Run(0x1, 0xffffffff, 0xfffffffe, 0x0, 0x3848c10, 0x4, 0x8, 0x3c608d0, 0x30fd300, 0x9, ...)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:1978 +0x188 fp=0x2adb7f0 sp=0x2adb774 pc=0x2c6468
main.StateBlock.Run(0x1, 0xffffffff, 0xffffffff, 0x0, 0x3848600, 0x6, 0x8, 0x3c608a0, 0x283d320, 0x1, ...)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:1966 +0x23c fp=0x2adb86c sp=0x2adb7f0 pc=0x2c651c
main.StateBlock.Run(0x1, 0xffffffff, 0xffffffff, 0x0, 0x3848560, 0xe, 0x10, 0x3c60780, 0x0, 0x0, ...)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:1966 +0x23c fp=0x2adb8e8 sp=0x2adb86c pc=0x2c651c
main.(*StateBlock).Run(0x3c611d0, 0x35e2000, 0x0, 0x0, 0x0, 0x8ae70500)
	<autogenerated>:1 +0x60 fp=0x2adb958 sp=0x2adb8e8 pc=0x41f1a4
main.StateBlock.Run(0x1, 0xffffffff, 0xffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x37a7d00, 0x7, ...)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:1978 +0x188 fp=0x2adb9d4 sp=0x2adb958 pc=0x2c6468
main.(*StateBytecode).run(0x2fc6000, 0x35e2000, 0xfffffffc)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/bytecode.go:7299 +0xac fp=0x2adba68 sp=0x2adb9d4 pc=0x2d1c64
main.(*Char).action(0x35e2000)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/char.go:5157 +0xe44 fp=0x2adbbd8 sp=0x2adba68 pc=0x2f2890
main.(*CharList).action(0x7b70b8, 0x0, 0x2adbc58, 0x2adbc5c, 0x2adbc54, 0x2adbc40, 0x2adf90c, 0x2adf910)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/char.go:5695 +0x80 fp=0x2adbc00 sp=0x2adbbd8 pc=0x2f6570
main.(*System).action(0x7af798, 0x2adf970, 0x2adf96c, 0x3f800000, 0x0, 0x0, 0x0)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/system.go:1196 +0x410 fp=0x2adf8f8 sp=0x2adbc00 pc=0x398764
main.(*System).fight(0x7af798, 0x3374000)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/system.go:2148 +0x10b8 fp=0x2ae1114 sp=0x2adf8f8 pc=0x39ce94
main.systemScriptInit.func54.2(0xc, 0x54a490, 0x7af798)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/script.go:878 +0x46c fp=0x2ae1808 sp=0x2ae1114 pc=0x3f2470
main.systemScriptInit.func54(0x2112240, 0x0)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/script.go:921 +0x328 fp=0x2ae1a1c sp=0x2ae1808 pc=0x3f2d84
github.com/yuin/gopher-lua.callGFunction(0x2112240, 0x0, 0x2288700)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:202 +0x30 fp=0x2ae1a4c sp=0x2ae1a1c pc=0x2772d8
github.com/yuin/gopher-lua.init.3.func26(0x2112240, 0x7c080601, 0x2252000, 0x0)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:817 +0x330 fp=0x2ae1af8 sp=0x2ae1a4c pc=0x27cc3c
github.com/yuin/gopher-lua.mainLoop(0x2112240, 0x2252000)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/vm.go:31 +0xdc fp=0x2ae1b0c sp=0x2ae1af8 pc=0x276e58
github.com/yuin/gopher-lua.(*LState).callR(0x2112240, 0x0, 0xffffffff, 0x0)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1203 +0x1b8 fp=0x2ae1b80 sp=0x2ae1b0c pc=0x269164
github.com/yuin/gopher-lua.(*LState).Call(...)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:1959
github.com/yuin/gopher-lua.(*LState).PCall(0x2112240, 0x0, 0xffffffff, 0x0, 0x0, 0x0)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/state.go:2022 +0xec fp=0x2ae1bbc sp=0x2ae1b80 pc=0x26cbc4
github.com/yuin/gopher-lua.(*LState).DoFile(0x2112240, 0x2014720, 0x18, 0x2112240, 0xf)
	/root/go/pkg/mod/github.com/yuin/gopher-lua@v0.0.0-20200816102855-ee81675732da/auxlib.go:396 +0x94 fp=0x2ae1bd8 sp=0x2ae1bbc pc=0x23f834
main.main()
	/home/pi/Desktop/Stuff/Ikemen-GO/src/main.go:87 +0x150 fp=0x2ae1fb8 sp=0x2ae1bd8 pc=0x377314
runtime.main()
	/usr/local/go/src/runtime/proc.go:225 +0x26c fp=0x2ae1fe4 sp=0x2ae1fb8 pc=0x8766c
runtime.goexit()
	/usr/local/go/src/runtime/asm_arm.s:841 +0x4 fp=0x2ae1fe4 sp=0x2ae1fe4 pc=0xb7cbc

goroutine 18 [sleep]:
time.Sleep(0x989680, 0x0)
	/usr/local/go/src/runtime/time.go:193 +0x100
main.(*System).soundWrite(0x7af798)
	/home/pi/Desktop/Stuff/Ikemen-GO/src/system.go:661 +0x354
created by main.(*System).audioOpen
	/home/pi/Desktop/Stuff/Ikemen-GO/src/system.go:649 +0xc4

goroutine 6 [runnable]:
github.com/hajimehoshi/oto._Cfunc_snd_pcm_writei(0x9c6f9b98, 0x2a98000, 0x5be, 0x5be)
	_cgo_gotypes.go:173 +0x34
github.com/hajimehoshi/oto.(*driver).TryWrite.func1(0x200d200, 0x209e000)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/driver_linux.go:143 +0xb4
github.com/hajimehoshi/oto.(*driver).TryWrite(0x200d200, 0x209e028, 0xd8, 0x7fd8, 0x0, 0x0, 0x0)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/driver_linux.go:143 +0x15c
github.com/hajimehoshi/oto.(*driverWriter).Write(0x207c300, 0x209e000, 0x100, 0x8000, 0x0, 0x0, 0x0)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/context.go:148 +0xe0
io.copyBuffer(0x5cecd8, 0x207c300, 0x5cecec, 0x205e5a0, 0x209e000, 0x8000, 0x8000, 0x0, 0x0, 0x0, ...)
	/usr/local/go/src/io/io.go:425 +0x1c0
io.Copy(...)
	/usr/local/go/src/io/io.go:382
github.com/hajimehoshi/oto.NewContext.func1(0x200e8e0)
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/context.go:85 +0x58
created by github.com/hajimehoshi/oto.NewContext
	/root/go/pkg/mod/github.com/hajimehoshi/oto@v0.5.4/context.go:84 +0x1e8

goroutine 7 [select]:
io.(*pipe).Write(0x2054340, 0x22400d8, 0x4410, 0x4410, 0xd8, 0x0, 0x0)
	/usr/local/go/src/io/pipe.go:94 +0x148
io.(*PipeWriter).Write(0x2161338, 0x2240000, 0x44e8, 0x44e8, 0x113a, 0x1, 0x0)
	/usr/local/go/src/io/pipe.go:163 +0x38
... (32 lines left)

The palette corruption described in the OP regarding LucasFebaits's fork is also in effect here
Fullscreen works, but does not revert to normal resolution on exit and crashes outright on composite-output mode

And the two major ingredients (it seems) to getting Windblade's IKEMEN GO to compile on the Pi 4 are:

Using Go 1.16.4 instead of apt-get install's 1.11. No idea how this would be accomplished using a RetroPie script module (as I've never seen a scenario where a dependency like go was obtained through anything other than apt-get install)
Forcing the executable to be ran with MESA_GL_VERSION_OVERRIDE=4.3, as IKEMEN GO was designed with GL 2.1 features, and the default version of GLES ran seems to cause compatiability issues with it; this could be accomplished very easily in a shellscript:

#!/bin/sh
MESA_GL_VERSION_OVERRIDE=4.3 ./Ikemen_GO_linux

MrRussellgro

This looks like some sweet progress. Hope it works well! I'm stoked to see how I.K.E.M.E.N looks like on RetroPie.

Troopaking

@superfromnd
Hello so I have been working on getting mugen to run on pi 4 . I have a had really good success using box86/wine and Lutris on TwisterOS .
Will be releasing a precompliled mugen image titled M.I.M.P (mimp is mugen pi) semi soon. Hopefully launching multiple mugens from emulationstation or pegasus frontend.
Glad to see others with similar ideas .
Good luck I have been trying since day one of owning a pi 4 . Just now made good progress.

MrRussellgro

@troopaking That's awesome! I am pleased to hear you got something going on as well.

SuperFromND

Haven't made any progress on this, but I'm posting because it turns out that a fellow on Reddit managed to get MUGEN running using Box86 and Wine, not unlike Troopaking's post above.

This isn't really helping IKEMEN GO's case at all, but I thought it was worth mentioning at least. :D

Troopaking

@superfromnd
Check this
https://retropie.org.uk/forum/topic/28528/box86-and-wine-on-rpi4/333

We've been working hard and have a how to add to any build in it . All old windows games ikemen would work loaded over 30 mugens and tested already

joamjoamjoam

@SuperFromND Hey I just found out about Mugen last week and I need more of it lol. I think Ikemen and Retropie are a perfect match and so I wanted to step in and help as much as I can. Ive been trying to port Ikemen to the pi over the past couple days and i ran across this gem of a thread and i wanted to add my progress and hopefully we can get this thing built into retropie at some point.

Anyways Using the LucasFebatis branch of Ikemen-Go-Plus I was able to compile and run a match using the Retropie prebuilt 32-bit image.

I was getting the infamous SIGBUS error which is because some of the OPCodes (mainly just OC_float) in bytecode.go:run() is trying to convert some bytes from the stack into an address but this address is not valid hence the SIGBUS. To get around this i replaced the line:

sys.bcStack.PushF(*(*float32)(unsafe.Pointer(&be[i])))

with

sys.bcStack.PushF(0);

This fixed the sigbus error on match load and got me into matches. Where to my surprise i found no pallette bug. I wasn't able to find the pallette character you were using but i did try to fight with the one and only Ronald Mcdonald to produce the below screenshot.
No Pallette Error.png

The only bug i ran into now is that because the OC_Float opcode is used to convert float numbers in the boolean expressions that move characters from state to state in their .def file, by hard coding the address of 0 the characters get stuck in states that they cannot get out of. This leads to issues like KFM looks like he's falling forever and cant be hit since that state ignores hits. So if we can see why these addresses are coming up wrong when read in the OC_float case in bytecode.go:run() we should be able to actually play matches.

If you'd like me to send anything of what I have so far let me know ill keep monitoring this thread.

joamjoamjoam

Oh and some stats about what I'm using night help recreate my results:

GO version (default installed from apt-get)
go 1.11.6 linux/arm

Pi Model (from /proc/cpuinfo):
Raspberry Pi 4 Model B Rev 1.1

Retropie version 4.6:

my Run.sh

#!/bin/sh
export GOPATH=$PWD/go
export DISPLAY=192.168.0.106:2.0
echo Using Display $DISPLAY
go fmt ./src/.go
MESA_GL_VERSION_OVERRIDE=4.3 go run ./src/.go

joamjoamjoam

So a little more digging into the issue led me to the fact that there is a byte alignment issue with the bcStack.

The address of be[i] when processing the OC_float op code is misaligned sometimes meaning its not a multiple of 4 like a pointer address needs to be. Not sure yet if this is related to a go unsafe pointer quirk or if we need to fix the alignment in the struct definitions.

This would be the reason why the 64bit OS doesn't have this SigBus Issue. The good news is that if i ported the code i have over to raspbianx64 this should be fully functioning now. Ill have to verify this still but with these alignment quirks caused by the use of 64 bit types (especially float64) on a 32bit opearting system the sigbus should sort itself out.

SuperFromND

Woahhh, stellar work joam! This was a very pleasant thing to wake up to this morning :D

I can't really help out too much on this specifically since low-level instructions and byte-alignment stuff is far out of my realm of expertis, but if you do need me for anything else (testing stuff, etc.) then let me know!

(oh, and the character I was using was the original Donald by Kishio, which can be found here; not that you'll really need it seeing as the palette issues apparently didn't occur for you at all.)

SuperFromND

I just forwarded these posts to the IKEMEN devs over on the Discord (which is probably a good idea for you join, by the way; it'll probably help being able to talk with the devs directly), and Gacel stated he's gonna look into adding these changes into the main IKEMEN GO fork (that's the Windblade-GR01 fork, not the LucasFebaits one you seem to be using).

Since I know how to compile and run that fork now, that would theoretically make it possible to compile directly from the main IKEMEN GO fork, meaning we'd always have the newest version of IKEMEN GO available for folks to compile!

If the changes are made and it turns out to work, I could probably (finally) start working on a scriptmodule for this. :D

joamjoamjoam

Glad i can help. I joined the discord and ill start getting acquainted with everyone this week. I think Gacel's could be invaluable in helping to align the structures. Luckily Alignment issues usually only affect ARM based systems (other compilers/arch are good at padding things for you) so in theory the padding should only affect these devices.

I gave it a go for like 6 hours last night trying to figure out what needed to be aligned but couldn't get a working build though my results mentioned below with the 64 bit Raspbian tell me that the structures are properly 8-Byte Aligned when using the 64 bit types. So that just means its really close already.

Thanks for the character ill load that one in just to make sure its not that character causing issues and i just got lucky with my character choice.

Also i started with the LucasFebatis repo cause you seemed to be having better results with it but i see that its a little over 1000 commits behind so before we start to byte align things for the 32 bit OS ill migrate up to that version.

Good News! I was waiting on an SD Card to load the 64 bit OS which arrived today and i was able to verify that on the 64bit Beta Raspbian I was able to play the game without any crashes. As far as i can see everything works. Also the performance was pretty good.

Unfortunately I did notice however that when using the X server on the Pi itself i saw the pallette issue but using the external xserver on my PC everything drew up just fine. this makes me think that the Xserver is to blame here. Though it is possible that the rendering is done on the PC side and replaces whatever bugs may on the pi side.

I think the byte alignment issue is a technicality so it shoouldnt be a showstopper on getting Ikemen on the Pi, it will just take some to sort out.

The pallette bug on the other hand seems like it demands attention so i think ill continue my testing on the 64 bit Raspbian and try to see if i can figure that one out but I think ole Lucas was onto what i saw also. He mentions that the XServer may have issues processing gamma ramp so i may start with finding an alternative XServer.

"For Got b'X11: RandR gamma ramp support seems broken"

TLDR

Current State: (Lucas Febatis)
32 bit Retropie OS:
Menus work good
Crashes in Match due to an Alignment Trap processing OC_float in bytecode.go (be[i] is not 2, 4, or 8 byte aligned)
When using an External X Server on PC palletes show correctly
Using Pi as the XServer the palette bug exists.

64 bit Raspbian OS:
Everything works except for the palette bug when using pi as the XServer
When using an External X Server on PC palettes show correctly.

joamjoamjoam

@SuperFromND

More progress updates on the 32 bit crashing when entering matches. I found a workaround for the Alignment trap by reading the array myself reallocating a slice and then dumping the resulting float32 in the stack where it belongs.

With this simple "fix" I am able to match the 64 bit OS functionality (Lucas Febatis repo) where you can play through matches and everything works as it should. The palette issue still exists as the only bug i can find so that's next on the todo list.

Maybe we can make a "Infection" Ikemen game so the palette issues become a feature lol.

Anyways ill port the "fix" in to the official windblade branch and test it there but since it was the same sigbus you were receiving this should fix that issue.

Fix for sigbus Alignment error on arm32

replace the line below from src/bytecode.go(line 898 ish or line 968 in WIndblade Repo) in Run() for OC_float case

sys.bcStack.PushF(*(*float32)(unsafe.Pointer(&be[i])))

to

arr := make([]byte, 4)
arr[0] = byte(be[i])
arr[1] = byte(be[i+1])
arr[2] = byte(be[i+2])
arr[3] = byte(be[i+3])
flo := Float32frombytes(arr)
sys.bcStack.PushF(flo)

Im off to compile the main fork be back later ...

Aaaand I'm back. Thank to your great tutorial i was able to compile the windblade for (which has a lot more stuff in btw) and confirmed that with the above "fix" I was able to get complete a few matches on the Retropie distro and had no crashes anywhere.

Note: The windblade branch was missing a function and an import for "encoding/binary":

func Float32frombytes(bytes []byte) float32 {
bits := binary.LittleEndian.Uint32(bytes)
return math.Float32frombits(bits)
}

Added a pull request for the windblade repo for this workaround. Ill leave the above explanation for history.
https://github.com/Windblade-GR01/Ikemen-GO/pull/319

SuperFromND

Great news, the PR above that joamjoamjoam submitted just got merged, and I can confirm it DOES compile! As you can see by this gameplay footage I recorded the palette issues still persist on Pi (According to joam's posts above, there's something in the Pi's Xserver that breaks it for whatever reason), but aside from that it's basically fully functional.

Fun side note: that weird input bug I mentioned earlier? Turns out that was just a fluke; my Bluetooth keyboard just doesn't play well with IKEMEN for whatever reason, and plugging in my usual USB keyboard worked perfectly fine (though my X360 pad still had a rotated D-pad by default, this can be easily fixed by just modifying config.json and all the other buttons work fine).

I guess it's time to start writing a scriptmodule then!

SuperFromND

Another update from me, I have managed to create an almost fully-functioning RetroPie scriptmodule for IKEMEN GO! Keyword there being almost, because while it can indeed download, compile and install IKEMEN GO, and while said build can be started, it hangs when trying to load.

There's a really odd quirk, though I'm not sure if it's the fault of IKEMEN or a consequence of xinit, but for whatever reason the engine fails to find LUA script files (that it needs) if you try to run it from anywhere other than the directory Ikemen_GO itself is installed in. So for example, if you ran IKEMEN GO from /foo/bar/ but it needs a file from/the/monkey/paw.png, it'll try to find the file at /foo/bar/paw.png! Thankfully this can be fixed with a very simple shellscript to manually change the directory to IKEMEN GO's and run that through XINIT: like so:

#!/bin/bash
cd /opt/retropie/ports/ikemen-go
MESA_GL_VERSION_OVERRIDE=4.3 ./Ikemen_GO

There's also something rather strange I encountered: when running IKEMEN GO from runcommand (making use of XINIT:, which is used in a few other scriptmodules like uqm and ags), it hangs on a black screen (assuming that the LUA issue mentioned above is solved already). It's not just refusing to run, as it will crash out if you have certain controllers plugged in when starting the engine up, but once it has started it just hangs indefinitely, leaving you with a black screen.

It's not just displaying to the wrong screen either; even grabbing a keyboard and spamming the Esc key to try and quit IKEMEN GO doesn't do anything, it's just flat-out frozen. There's actually been at least one other project that has gotten this black screen issue through XINIT:, though sadly the thread never elaborated on it nor provided a solution.

However, manually starting xinit and then running it... works perfectly fine! This seems to suggest that I might just need to tweak the launch command more, so perhaps someone more savvy and experienced with XINIT: related stuff in RetroPie could come and assist (paging @mitu perhaps?)

I should mention that there's a second way of running stuff that requires xinit in RetroPie, and that's using xinit -e 'command'. Unfortunately, trying that instead crashes due to xinit not having permission to access /dev/tty0, crashing before we even get a chance for IKEMEN GO to run. Now, there is a fix for this, and I confirmed that it DOES allow IKEMEN GO to run from runcommand.

The only problem is that the fix is this:

# a very, VERY bad idea, especially for a game with user-made content
ikemen-go = "sudo xinit -e '/opt/retropie/ports/ikemen-go/ikemen-go.sh'"
default = "ikemen-go"

For those not super savvy with how Linux works, sudo is essentially the Linux equivalent of running a program as an administrator in Windows, and is really only supposed to be used as a last resort, and not for general use like this.

I actually ran into this exact same conundrum back in 2018 while trying to get Flash and Java games running on RetroPie, and I did technically find a solution that didn't require sudo xinit. That solution was using a chmod command on Xorg to allow it to run from a script:

sudo chmod ug+s /usr/lib/xorg/Xorg

Of course, since as you can see this also makes use of the sudo command, it's not a safe or elegant solution to this problem either.

So to recap:

Running IKEMEN GO manually works fine
Running IKEMEN GO from XINIT: hangs at a black screen
Running IKEMEN GO from xinit -e isnt possible without a huge security risk

Thankfully, aside from the palette issues joam described above, and the controller bug mentioned earlier in this thread that's planned to be remedied soon anyways, this is the last major issue that needs to be fixed before IKEMEN GO could be feasibly added to RetroPie. And given the circumstances and the fact that running source ports through XINIT: is clearly possible already, this could very well be ready for testing soon. We're in the endgame.

joamjoamjoam

@SuperFromND Nice work!! It’s really coming along now.

A small update in the palette corruption issue. I’ve narrowed it down to being one of 4 things:

A bug in the shaders that only shows on arm.
A bug in the v3D driver (Mesa) when drawing textures
A bug with the Go glfw pacakage or GLFW itself when running on the pi.
A bug in the Ikemen_GO source that’s is causing the textures drawn from the sprites/palettes to be messed up on the pi only.

I think one of the first 3 is most likely since a remote c server shows no issues and OpenGL 2.1 support for the pi is relatively new.

Things I’ve tried to no avail:

Printing palettes being read from SFF files and looking for discrepancies from what’s is defined in fighter factory.
using Mesa 20.3 v3D drivers for OpenGL for the pi.

We also would need to rewrite the shaders in openGLES 2 if we wanted to support other Pi devices as the pi4 is the only pi that can handle OpenGL 2.1.

SuperFromND

I found something that works with XINIT:! This is probably not the ideal way (I'm sure that either mitu or Jools will point out if there's a better way to handle it), but I found out that chaining the launch commands into xterm will cause IKEMEN GO to boot correctly from EmulationStation:

ikemen-go = "XINIT:/opt/retropie/ports/ikemen-go/ikemen-go.sh"
default = "ikemen-go"

#!/bin/bash
export MESA_GL_VERSION_OVERRIDE=2.1
xterm -g 320x240+0+0 -e 'cd /opt/retropie/ports/ikemen-go && ./Ikemen_GO'

So all that's left is for me to clean up this scriptmodule a tiny bit, maybe adding some symlinks to intergrate it a bit better with RetroPie's folder structure, and then we can have people test it!

h2805270

It will be pretty interesting to see a highly customizable fighting game engine be used on RetroPie for various fighting games.

Speaking of which, I haven't heard from the OpenBOR board in a couple of months. I wonder if they are still active...

joamjoamjoam

A little bit more info on the palette issue. The issue is definitely caused by the shaders. For some reason the OpenGL texture mapping for the 1d texture palette is not mapping correctly when running in the pi hardware. I verified that palettes being read from sff files match on both the pi and my windows PC.

I think the issue is related to the difference in texture precision on the two devices. Unfortunately I think this is as far as I can take it unless there’s someone on the Dev team who knows what these shaders are doing and are willing to play around with some of the texture types for the pi to get more precision.

Edit: we’ll nvm after about 3 days of no progress I went to document what I found and what line was causing it in case someone smarter than me wanted to look at it.

In render.go there’s a line in the fragment shader around render.go:70 that maps the pallet texture to the 2d sprite.

Line 70
Vec4 c = texture1D(pal, r*0.9961)

Simply tweaking the constant from .9961 to .9966 yielded the below results.

It stood out to me cause it had a hard coded constant by tweaking the constant by small amounts all the palettes lined up from the elecbyte logo to the characters in a match.

Also Ignore Gandalf's staff being transparent. That's just me being bad at editing sprites with Fighter Factory. All the characters I dint touch match exactly to how they play on Windows.

texturesFixed (Small).jpg

SuperFromND

@joamjoamjoam Nice work! Really interesting that a single constant value was all that it took to break (and now fix) palettes, kinda makes me wonder how exactly that bit of code came about in the first place. Once again, a massive thank you for your help!

Also, I just now finished my first draft of the scriptmodule:

#!/usr/bin/env bash

# This file is part of The RetroPie Project
#
# The RetroPie Project is the legal property of its developers, whose names are
# too numerous to list here. Please refer to the COPYRIGHT.md file distributed with this source.
#
# See the LICENSE.md file at the top-level directory of this distribution and
# at https://raw.githubusercontent.com/RetroPie/RetroPie-Setup/master/LICENSE.md
#

rp_module_id="ikemen-go"
rp_module_desc="I.K.E.M.E.N GO - Clone of M.U.G.E.N to the Go programming language"
rp_module_licence="MIT https://raw.githubusercontent.com/Windblade-GR01/Ikemen-GO/master/License.txt"
rp_module_help="Copy characters, stages, screenpacks, etc. to $romdir/ports/ikemen-go"
rp_module_section="exp"

function depends_ikemen-go() {
    getDepends golang-go libgl1-mesa-dev xinit xorg xorg-dev libopenal1 libopenal-dev libgtk-3-dev libasound2-dev freeglut3-dev
}

function sources_ikemen-go() {
    gitPullOrClone "$md_build" https://github.com/Windblade-GR01/Ikemen-GO.git
}

function build_ikemen-go() {
    go clean
    go mod tidy
    make TAGS='-tags al_cmpt' linux
    # grabs default screenpack and content required for the game to run; note that the screenpack has a CC-BY-NC 3.0 license
    make elecbyte
    md_ret_require="$md_build/Ikemen_GO"
}

function install_ikemen-go() {
    cp 'elecbyte/LICENCE.txt' 'ScreenpackLicense.txt'
    mkdir save sound

    md_ret_files=(
        'Ikemen_GO'
        'License.txt'
        'ScreenpackLicense.txt'
        'data'
        'save'
        'sound'
        'font'
        'external'
        'elecbyte/chars'
        'elecbyte/stages'
        'elecbyte/data'
        'elecbyte/font'
    )
}

function configure_ikemen-go() {
    mkRomDir "ports/ikemen-go"
    addPort "$md_id" "ikemen-go" "I.K.E.M.E.N GO" "XINIT:$md_inst/ikemen-go.sh"

    moveConfigDir "$md_inst/chars" "$romdir/ports/ikemen-go/chars"
    moveConfigDir "$md_inst/stages" "$romdir/ports/ikemen-go/stages"
    moveConfigDir "$md_inst/data" "$romdir/ports/ikemen-go/data"
    moveConfigDir "$md_inst/external" "$romdir/ports/ikemen-go/external"
    moveConfigDir "$md_inst/font" "$romdir/ports/ikemen-go/font"
    moveConfigDir "$md_inst/sound" "$romdir/ports/ikemen-go/sound"
    moveConfigDir "$md_inst/save" "$configdir/ports/ikemen-go"

    cat >"$md_inst/ikemen-go.sh" << _EOF_
#!/bin/bash
export MESA_GL_VERSION_OVERRIDE=2.1
xterm -g 1x1+0+0 -e 'cd /opt/retropie/ports/ikemen-go && ./Ikemen_GO'
_EOF_
    chmod +x "$md_inst/ikemen-go.sh"
    chown -R $user:$user "$md_inst"
}

As you can see there's still some weirdness that should be sorted out (specifically the wall of moveConfigDirs could probably be reduced, chown -R $user:$user "$md_inst" may be over-scoped, and make elecbyte probably should go in a game_data_ function), but this is still good enough to install IKEMEN GO in a way that works well with RetroPie's file structure.

If you know how to install a scriptmodule into RetroPie manually, this should be testable! Just in case you don't though, here's a super-quick rundown of the procedure:

If you haven't already, enable SSH on RetroPie.
Open up whatever SSH program you prefer (I use PuTTY) and log into your Pi.
Navigate to /home/pi/RetroPie-Setup/scriptmodules/ports using the cd command.
Start up a text editor with elevated priveleges using sudo nano ikemen-go.sh.
Paste the contents of the scriptmodule above (in PuTTY, this can be accomplished by first copy-pasting the scriptmodule's contents in this post, and then simply right-clicking the PuTTY window), then press: Ctrl-X, then Y, then Enter / Return to save the file and exit nano.
If done correctly, there should be a new file called ikemen-go.sh present (You can verify this by running ls ikemen-go.sh). You can now exit your SSH program.
From here, you can access and run the scriptmodule like any other; by going into RetroPie Setup and going to "Manage Packages". IKEMEN GO will be under "Experimental".

Addendum: Just for funsies, I made a launching.png image in the style of the Pixel theme's launching images, themed after the default screenpack in IKEMEN: