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

[MrRussellgro]

@superfromnd BTW, when I tried to overwrite or change the path for the screenpack it gives me an error.

[TheSnackist]

good news: got it running on Pi3b

bad news: OMG it chuuuuuugs so bad

I had some success with changing the resolution to lowest it has a preset for: 320 x 240

I am also running into a Fullscreen issue. shouldn't the Fullscreen option resize the game, not just leave it at the low resolution in the corner?

[TheSnackist]

@thesnackist said in I.K.E.M.E.N GO on Raspberry Pi 4:

good news: got it running on Pi3b

bad news: OMG it chuuuuuugs so bad

I had some success with changing the resolution to lowest it has a preset for: 320 x 240

I am also running into a Fullscreen issue. shouldn't the Fullscreen option resize the game, not just leave it at the low resolution in the corner?

okay using runcommand I got it into... somewhat working shape

if anyone else wants to try this on a pi 3b - the key was charging the resolution in IKEMEN to as low as it would allow (320x240) and then use runcommand to adjust on the framebuffer res to match... once you have done that picking a video mode on the same aspect radio will result in something semi-decent

now to do all the regular MUGEN config stuff!!

[MrRussellgro]

@superfromnd So yeah, remember when I said my screenpack wasn't working? Apparently I was just an idiot and forgot the stage wasn't working as the game launched with a error message before I could proceed to the title menu. It's working now.

[TheSnackist]

a new IKEMEN GO version, 0.98 was just released - will we be able to update using the same script we use to install?

[SuperFromND]

@thesnackist The script compiles from source, so it should be able to update just fine. I haven't tested the script with the new release yet, though.

[TheSnackist]

happy to report the update seems to work without a hitch!!

(though I did learn the importance of making a separate folder for any tinkering you are doing with system.def, select.def etc., DOH)

didn't se any immediate improvements in the lag/chugging but will have to do more testing

[retro-devil2]

@superfromnd Great to see such progress. Last time I tryed this install failed that was 6 months ago . Will try again tomorrow.
A few questions :
-how are you guys handling controller input ?
-how well does it play ?
-got online pvp working?

Thanks for what you do .

[SuperFromND]

@retro-devil2 said in I.K.E.M.E.N GO on Raspberry Pi 4:

A few questions :
-how are you guys handling controller input ?
-how well does it play ?
-got online pvp working?

• Right now, we're just relying on the native controller support IKEMEN GO gives us. Depending on exactly what controller you have, that might be a problem, but I can at the very least say it works well with wired X360 controllers.
• Depends a ton on what exactly you have as your content; in my experience some traditional characters and stages (e.g. your Street Fighter 2s and KOFs and SVC2s and content along those sorts of lines) pretty well, with only the occasional mild stutter. Definetly a bit of a RAM hog though; I'd recommend a 2-gig or 4-gig Pi 4 if you plan on having a massive roster.
• Nobody's tested it yet on the Pis to my knowledge; apparently according to Gacel cross-architecture netplay isnt possible due to floating-point stuff. (AKA you can't play a PC player against a Pi player).

[retro-devil2]

@superfromnd
Awesome
-so seen the mugen installer? We use qjoypad in bash scripts to map keyboard to mugen . In v3 it autoloads a layout with same name as exe .
-cool on performance good to know.
I will try and test pvp with another Devil soon

[retro-devil2]

@superfromnd
Hello again I installed everything went fine.
But I don't understand how you guys are adding/launching screenpacks .
I tried
/home/pi........ikemen go.sh -r big
this loads ikemen fine but not the big motif . As expected
And
./Ikemen_GO path/to/motif/select.def
This gives me "no such file etc " error .

I am not familiar with adding screenpacks and stuff to ikemen only mugen .
Thier instructions are ./Ikemen_GO -r motif/path/select.def

I also tried my Xbox one and off brand ps3 controllers neither worked in Ikemen .
This could be solved using qjoypad before ikemen or autoloading qjoypad with same as ikemen game/motif. Thats what mugen installer on pi does layout same name as exe.
I just unaware of ikemen gos launch command. I feel thats the issue with motifs and using qjoypad .

I am also curious how we will launch more than one ikemen motif/game from a retropie .

[SuperFromND]

@retro-devil2 Rather late on this reply, sorry! The .sh file doesn't take any arguments; if you want to supply arguments to IKEMEN Go, you'll have to modify the script directly:

#!/bin/bash
export MESA_GL_VERSION_OVERRIDE=2.1
xset -dpms s off s noblank
xterm -g 1x1+0-0 -e 'cd $md_inst && ./Ikemen_GO -r big' #<== this part!

[retro-devil2]

@superfromnd
Hello again so
-we tried pvp . Could be slow net but didn't work.
-We are gonna try and implant this with qjoypad soon. That way most controllers work with it .
-Thanks for input on screenpack adding . So you can only have one ikemen go installed to launch ? Example i want mvc and regular ikemen . And both to appear in retropie .

[SuperFromND]

@retro-devil2 said in I.K.E.M.E.N GO on Raspberry Pi 4:

-Thanks for input on screenpack adding . So you can only have one ikemen go installed to launch ? Example i want mvc and regular ikemen . And both to appear in retropie .

At the moment yes, you can only configure the script to launch one at a time. Theoretically it should be possible to have a bunch of them installed at once and then launch individual ones using either RetroPie's runcommand settings or the -motif argument (perhaps passing motif names to the argument the same way runcommand passes ROM names to an emulator?), but that would result in storing ALL of the games merged with eachother, with the motifs picking out which characters and what menu layouts to use. While this would work, it's not exactly elegant for managing multiple games as you'd have to know exactly which games use what, and the possibility of conflicting file names is a very real possibility (a lot of MUGEN content, namely screenpacks, have a really bad tendency to overwrite existing core files instead of placing them in a subdirectory).

Another idea I had was having a script that created a temporary symlink to a folder containing a game's content that would be deleted once the game was closed, though I don't know if this would work because of permissions shenanagains on Linux. This would be somewhat similar to how RetroPie handles DOSbox, which has a similar problem with how its file system works.

[retro-devil2]

@superfromnd
So i don't know how you'd do it atm. . .
But a lot of syste s accepts zips so retropie does as well. You could make each one a zip . All be it that sounds crazy

[SuperFromND]

Hey folks, I just updated the ikemen-go.sh setup script to account for a change in IKEMEN GO's Makefile that resulted in the screenpack not being able to download.

Make sure to grab the updated script before you try to install or update!

[janderclander14]

@SuperFromND Thanks for the updated script. I can confirm that it builds fine but when trying to load HyperDBZ it throws the following error:

Error while loading the config file.
json: cannot unmarshal string into Go struct
field configSettings.FontShaderVer of type unit

The game was working fine with verion 0.97. I see the latest release 0.98.2 (from 6 days ago) introduced a number of 'breaking changes' that may be the cause for this?

https://github.com/Windblade-GR01/Ikemen-GO/releases

Any ideas?

[SuperFromND]

@janderclander14 This may sound weird, but try deleting/renaming config.json and then relaunching the game.

[janderclander14]

@SuperFromND Great, that did the trick, thanks! Performance seems to be improved from version 0.97. The game no longer lags after a while : )

[SuperFromND]

Wall of text incoming!

So for a little while, I've been thinking over how to set it up so that you can install multiple MUGEN/IKEMEN fullgames, as that's the primary advantage the Box86 + Wine MUGEN method has over IKEMEN. Just so all of us are on the same page, let me provide a quick and dirty overview of the whole situation:

The Problem[s]

RetroPie's file structure is as such: the directory /home/pi/RetroPie/roms/[system_name] is used for storing game data (mostly ROM files for emulators as the name implies, but in the case of source ports like DOOM or Quake 3 it stores their game data), while the actual executables are stored in a separate location: /opt/retropie/ports/[game_name]. The reason for this, best I can tell, is to ensure the user doesn't accidentally delete an executable while managing their games. This isn't a problem for most of RetroPie's supported programs (read: emulators and source ports), as most of them can be supplied a single file from any directory without problem, or have a command line argument/setting file that can be used to point to a specific directory containing multiple files if need be.

IKEMEN however, being a game engine, has a very different expectation when it comes to file structure. The engine expects there to be several folders in the same directory as itself, several files within those folders, and much content relies on relative-paths and failsafes of said relative-paths that all rely on files being exactly where they are in relation to the executable itself. IKEMEN needs to be in the right place, and the files need to be in the right place as well.

With that knowledge, this presents a problem: IKEMEN's file structure expects both game data and executable to be all in the same location, but RetroPie wants game data and executables in separate locations. Furthermore, /opt/retropie/ports/ is set to be read-only by RetroPie for security reasons, so if IKEMEN is installed into that directory, the game crashes due to not being able to write anything there, and obviously the user couldn't do anything with the engine without some sudo-flavored bruteforcing (not to mention not being able to see the folder via Samba shares, a common way of getting game files onto RetroPie). I wanted to be able to have users add stuff or install a fullgame, but also maintain RetroPie's file structure so that an IKEMEN installation shell-script could be added officially.

My first workaround for this discrepency was fairly simple: by moving the aeformentioned data folders to /home/pi/RetroPie/roms/ports/ikemen-go/[various folders like chars, data, sound, etc] and setting up some symlinks in /opt/retropie/ports to point to there, I was able to get IKEMEN to conform to RetroPie's file structure while still allowing for a user to easily customize the game's files. This works, but it has a few problems.

The main problem: with this setup, you can only have one IKEMEN-engine game installed at a time. This is seen as a deal-breaker for many, with some instead opting for the hacky solution of copying over fullgames verbatim (.exes and all), and then running the original executables using a combination of Box86 and Wine. While this does work, this method probably won't ever be officially incorporated into RetroPie due to its janky nature and conflicting with RetroPie's file structure ethos.

That's not the only problem, either: since we're creating fixed symlinks, this also poses a problem for any IKEMEN fullgame that happens to use non-standard folders (Famicom Fighters is an example of one that does), either in addition to or replacing the standard ones. Since IKEMEN is only able to look in its own directory (which is what the symlinks work around), any files or folders that didn't have a symlink already created will not be found by IKEMEN, leading to a crash or otherwise undesirable behavior. Sure, you could ask the user to manually create those symlinks, or try to automatically generate those symlinks at runtime using scripting (which would probably just cause headaches for security), but ultimately it's still a wonky solution to a problem that really shouldn't have to exist.

My Idea for a Solution

I've pondered for some time on an elegant way to alleviate all of this, and I think I've devised a solution that makes sense and solves all of this jank. Here's what the new file structure would look like:

• /home/pi/RetroPie/roms/ports/ikemen-go/ would now contain a bunch of subfolders, with each one of those subfolders containing the files of a fullgame. These subfolders would ideally have short and simple names: black-heart, gensokyo-reloaded, hyper-dbz, etc. This is similar to how some other source ports function in RetroPie, such as Daphne or ScummVM.

• /home/pi/RetroPie/roms/ikemen-go/, a new directory, would contain dummy ".igo" files - blank files whose names would correspond to the subfolders in the above directory. This would have the side-effect of allowing for a dedicated MUGEN/IKEMEN section in EmulationStation, instead of just being an option in the Ports menu.

• /opt/retropie/ports/ikemen-go would contain the IKEMEN executable and a script file, ikemen-go.sh, that would handle launching these different fullgames.

In order for my idea to work, one small addition would have to be made to IKEMEN: the addition of a new argument to change IKEMEN's working directory. Essentially, this would tell IKEMEN to act as if it was being ran from the directory provided in the argument; this is something that's not currently possible (the -motif argument comes somewhat close), but theoretically it shouldn't be too hard to add (gotta love FOSS!) and wouldn't interfere with normal IKEMEN usage. I'll submit a feature request to the IKEMEN Github (which has moved to an organization on Github since last post, I should mention) and see if this can get added.

Assuming the above issue gets fufilled, the order of operations would go something like this:

• We launch a game from EmulationStation. As an example, let's use black-heart. The file we're launching is called black-heart.igo, and is stored in /home/pi/RetroPie/roms/ikemen-go/.
• Runcommand.sh is told we're launching from system ikemen-go with a %ROM% value of black-heart.igo. Using %BASENAME%, the extension gets stripped, leaving us with black-heart. Runcommand passes %BASENAME% to the ikemen-go.sh script file in /opt/retropie/ports/ikemen-go.
• That script would then take the %BASENAME% value and format it into this new argument, giving us something like "/home/pi/RetroPie/roms/ports/ikemen-go/black-heart".
• The script would then launch IKEMEN with that newly-formatted argument: ./Ikemen_GO -dir “/home/pi/RetroPie/ports/ikemen-go/black-heart”
• IKEMEN would see the -dir argument and set its working directory to /home/pi/RetroPie/ports/ikemen-go/black-heart, and from there, load The Black Heart as if it was launched from that directory to begin with.
• Optionally, you could make a small script to read the subfolder names in /home/pi/RetroPie/roms/ports/ikemen-go/* and automatically generate the .igo files if they aren't present, meaning all a user would have to do is create a folder (or possibly multiple folders), drag in the fullgame's contents, and run the script.

I tried to make a diagram to describe the above in a more intuitive way, but it came out looking more like the ramblings of a scientist gone mad: here it is anyways!

So yeah, that's my plan for this. I'll keep you folks updated as this wild chicanery continues.

TL;DR: Gonna request a feature to IKEMEN that would potentially allow multi-fullgame launching in RetroPie if it gets added.