Suggestions for ports

shavecat

@tpo1990
Any chance to get capatinclaw ruining on the pi4 plz ?<3

ExarKunIv

@shavecat it does, but till someone makes a script

you have to read how to compile it yourself.
i got it to work, but have not messed it much other then making sure it starts

shavecat

@ExarKunIv
How do i do that ?
is it hard :)?
thanks :)

shavecat

@VictimRLSH
Got really hard to do that,try it with my desktop windows didnt really work at all dont know also how to put the claw working in the pi4.
can u give a a step by step Gide by any chance for captain claw :)

ExarKunIv

@shavecat
it can be a little confusing when you first start out. but its not that bad.
you do need to find a data file on your own since its not included. which is a reason why i dont think anyone will be making a script for it.

that data file is needed to build the game.

shavecat

@ExarKunIv
Shame so i guess i wont get it for now :(
thanks

tpo1990

@shavecat It depends on if you can get it to run correctly with SDL renderer. Also it can be really helpful to get more people to learn how to compile. That would help both RetroPie community and me a lot.

@ExarKunIv is probably closer to getting Captain Claw to actually work on the Pi 4.

As far as my testing goes with the Pi 4 and ports, is that it appears there are some sort of issue with getting the screen to renderer correctly with SDL. The solution at the moment to this is by using Dispmanx. For that it means that the scriptmodules needs a small change to allow use of Dispmanx

shavecat

@tpo1990
Just show me how step by step will love it :)

tpo1990

@shavecat It will take a lot of your time doing so and it will be trial and error as you will notice by trying to compile into a working binary. It will not always work and you will need to look into understanding how the scriptmodules works for RetroPie and its directories in the file system of it.

That is if you want to create scriptmodules for other users here and share your work. I can recommend doing so as it will strengthen the RetroPie community and I know a lot of the people here will appreciate it.

You did however gave me the idea that I could create a new topic here for a beginners guide to compile. It will take me some time doing so. Let me know if you still want this. :-)

retropieuser555

@tpo1990 Hey if I can jump on the bandwagon here, I would definitely be interested in a rough guide on how to compile.

tpo1990

@retropieuser555 It seems more are interested in this. Alright then I will do such a guide. Hopefully it will help you and others getting into compiling and making your own scriptmodules. :-)

It might take som time before it will be here, but I will do my best and it will be in another topic so that it doesn't vanish into this topic.

shavecat

@tpo1990
Sure i will love a guide , not sure if will make it right :)
but i will try and sure will love to get it work and share it :))

tpo1990

@shavecat Great I will make sure to give an example of a game we easily can compile in the guide and also a more difficult one.

shavecat

@tpo1990
make an example of captain claw ;)) <3

SuperFromND

@TappedOut said in Suggestions for ports:

Ikemen GO Plus
Uses Golang to interpret M.U.G.E.N files and characters
Repo: https://github.com/Windblade-GR01/Ikemen_GO

I decided to try getting this to compile, and I'd like to document my findings.

Checking the compilation instructions for Linux I noticed that it requires you to install no less than six dependencies. After installing them (which costed about 180MB of disk space by the way), I got up to the part where it asks you to run a shell script named get.sh before I ran into an error:

Package gtk+-3.0 was not found in the pkg-config search path.

A quick Google search lead me to find that I needed to install the apt-get package libgtk-3-dev... which costs an additional 141MB due to a ton of additional packages. Not a problem, I've got a 64GB SD card with plenty of space.

So I installed that, and then proceeded with the IKEMEN compilation process from there: running get.sh and then build.sh. I did recieve an error when running build.sh, but it simply said that it wasn't able to copy a folder to the bin folder (which is where the compiled IKEMEN binary would be created). Checking the build.sh file, the copy folder command that failed was after the commands that actually compiled IKEMEN, so I simply ignored this error and tried to run the game, only to be greeted with yet another error:

Gtk-WARNING **: cannot open display:

A telltale sign that an executable requires X. You can probably guess what this means: another dependency install, this time for the package xinit. I already messed with xinit before for running Flash and Java games on a Pi, so I wasn't too bothered by this, but that's still yet another dependency to install.

Once it was done, I booted up xinit and ran this command to start IKEMEN:

root@retropie:pi/home/pi/RetroPie-Setup/tmp/build/Ikemen_GO/build $ sudo ./Ikemen_GO_linux

And after all of that effort, I was met with another error message, about the worst possible error you could possibly get if you aren't a programmer yourself:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x14 pc=0x206894]

A segmentation violation. Now, I'm not the first person to try to compile IKEMEN GO on a Pi, there's even an issue on the Github where someone got a SIGBUS error instead. It was upon reading this issue that I noticed an interesting reply from one of the repo maintainers:

danielporto commented on Apr 23, 2019:
Good. I have built one
please download it here: https://github.com/danielporto/Ikemen_GO/releases/tag/19.04.2019>

They had compiled a binary for the Pi! Granted, it was back in April of 2019, but it was still an IKEMEN GO binary for the Pi! I quickly downloaded the binary, and after waiting an agonizingly long time for WinSCP to copy the binary over to my Pi, I gave it a run. It gave me a new error, but this time it was something tangible:

panic: open script/main.lua: no such file or directory

Aha! It's looking for that script folder that it didn't copy from earlier. Thankfully, that folder was just sitting outside of the bin folder, so I copied it into the bin folder and ran the binary again. Another error:

panic: script/main.lua:14: attempt to call a non-functional object

Checking line 14 of script/main.lua, we can see this:

--One-time load of the json routines
json = (loadfile 'external/script/dkjson.lua')()

Okay, so it's trying to check for the dkjson.lua file in the script folder (which we already copied to the bin directory), but it's expecting that script folder to be contained within an external folder (which it was in the repo). In other words, IKEMEN wants both external/script/*.lua and script/*.lua to exist in order to run.

So alright, I'll just copy over all of external, folder and all, to bin. Wasteful, but if it's what the IKEMEN orders, it's what the IKEMEN gets. One copy later, I run the binary again:

panic: script/main.lua:256: attempt to index a non-table object(nil)

Checking line 256, we can see this (--motif is the 256th line):

--motif
main.motifDef = config.Motif
if main.flags['-r'] ~= nil or main.flags['-rubric'] ~= nil then
	local case = main.flags['-r']:lower() or main.flags['-rubric']:lower()
	if case:match('^data[/\\]') and main.f_fileExists(main.flags['-r']) then
		main.motifDef = main.flags['-r'] or main.flags['-rubric']
	elseif case:match('%.def$') and main.f_fileExists('data/' .. main.flags['-r']) then
		main.motifDef = 'data/' .. (main.flags['-r'] or main.flags['-rubric'])
	elseif main.f_fileExists('data/' .. main.flags['-r'] .. '/system.def') then
		main.motifDef = 'data/' .. (main.flags['-r'] or main.flags['-rubric']) .. '/system.def'
	end
end

As you can probably infer by the way this post is written, I was pretty much completely exasperated by the time I got to this error, and seeing that wall of regex-heavy text was my breaking point. I'm sure that someone out there could go through the paces and debug every single little error that gets thrown their way, but this is where I throw in the towel for this particular port.

As an aside: I should mention that IKEMEN GO is actually a rewrite of the original IKEMEN, which might be worth looking into. Unfortunately, I was completely unable to find any instructions on how to compile it, ~~and the files in the repository don't really give any clues.~~ It appears to require Visual Studio to compile IKEMEN, so that's an immediate "no" for that.

There's also a possiblity that you might be able to run the game through Box86, but I haven't tried this yet.

TL;DR: This probably could work, but I couldn't get it to, and it would probably be experimental at best due to the sheer number of dependencies it needs. Still, I would love to be able to play some form of MUGEN on the Pi someday.

Addendum (9/24/2020)

I attempted to compile Ikemen-GO on both a regular install of Raspbian and the 64-bit version released fairly recently, and ended up getting the same SIGSEGV error. I've opened up an issue on the Ikemen-GO Github about this error and all of my reproduction steps, so hopefully in due time I can figure out how to fix it and (hopefully) get the game running.

I also found out that I was missing an additional package, libasound2-dev, which wasn't specified by Ikemen's build instructions but throws up an error if you try to compile without it.

Addendum (9/28/2020)

I was browsing around Github and found this fork of Ikemen GO that mentions it was "For Raspberry Pi 3". Despite the fact that the repository was quite old (last commit was on July of last year, and it was about 500 commits behind Ikemen GO's repo) and the fact that it specified needing another package (freeglut3-dev, thankfully this one isn't all that large), I still figured it would be worth a shot to try and compile for the Pi 4. This time, I was able to get an executable that actually started!

Unfortunately, this build ended up having some rather severe graphical issues. The repo does state For Got b'X11: RandR gamma ramp support seems broken, so I'm assuming that this is something on Go's end and not IKEMEN's. Here's a few comparisons between the Pi running this IKEMEN GO fork and my main machine running IKEMEN GO's "canon" builds.

The title screen has some mild graphical issues, mostly on the left side of the M and the right side of the N. You might also notice that the menu options are different between the two, which makes sense as this build is quite outdated compared to the current build of IKEMEN GO.

The options menu lacks a darkbox, making it harder to read the options. (This is made even worse as a screenshot, it's slightly easier to read when the background is constantly moving.) The Audio. Gameplay, and Engine settings also don't exist in this build.

More graphical glitches! It appears that, at the least, the second color of a given palette gets broken to either black or transparent. (for those who aren't technically savvy about how MUGEN palettes work: the first color of a palette will be treated as transparent, and the rest should all be treated as opaque.)

Despite what all of these graphical glitches might have you think, the rest of the game functions just fine. No audio issues, no characters glitching out (well, glitching out because of a broken IKEMEN engine anyways), and no crashes that I was able to get in my (rather meager) testing. It does run a little bit slow when there's a lot of stuff happening on screen, but depending on exactly what characters you have this might or might not be an issue.

Next time I need to update this post, I'll just split it off into it's own thread.

ADDENDUM: 10/6/2020

A bit late on saying this, but I've split off my IKEMEN stuff into it's own thread.

tpo1990

@shavecat @retropieuser555

I have now started building my guide in a new topic. Take note that it is not finished yet as it will require a great part of my limited spare time, however i do believe it will help you as it will help me with sharing the work of getting more source ports in to working games for the Raspberry Pi.

https://retropie.org.uk/forum/topic/27939/guide-beginners-guide-to-compile-from-source

zerojay

@SuperFromND said in [Suggestions for ports]

Unfortunately, this build ended up having some rather severe graphical issues. The repo does state For Got b'X11: RandR gamma ramp support seems broken...

https://github.com/kitao/pyxel/issues/40

Might have a fix here or some additional info.

shavecat

Any chance pi4 can run
Oni
https://en.wikipedia.org/wiki/Oni_(video_game)
Or
Enter the Matrix
https://en.wikipedia.org/wiki/Enter_the_Matrix
used too love this games :))

ExarKunIv

@shavecat if someone makes a port for it so it can work with retropie, maybe on the pi4.

otherwise you would have to try it with the Win10 very for the Pi and even then its a maybe.

retropieuser555

So I was messing around trying to compile Falltergeist, https://github.com/falltergeist/falltergeist

I installed the dependancies, cloned the github, built it, added my critter.dat and master.dat files and booted it...

And it loads surprisingly:- The intro video plays nicely, the menus are all quick, you come into the game and it's basically a debug mode they have setup.

I'm not sure, but based on the github it doesn't look like it's being worked on significantly which is a shame. But who knows maybe someone will take up the reigns on it someday and finish it... Or maybe not.

Also it's listed on their proper website as a fallout1 & 2 engine. But I could only get it to load the fallout2 .dat files.