NeoGeo and NeoGeoCD Emulation crashes

[alocacoc]

Dear friends,
I tried to use Raine on my Arch Linux machine.

I use the latest AUR 'raine' packet and it installes just fine.

I can start the emu and play games like Street Fighter II or other CPS games without any problem.

But NeoGeo and NeoGeoCD titles crash. Some crash very fast quickly after the bios boot, some crash, like Samurai Spirits IV, after you choose your fighter. They always crash at a quite similar point in the game. Firstly I thought they crash once playing a certain audio sample, but I'm not sure.

The interesting part is, the exact same bios/roms/images work well on the Windows Version of Raine.

Any clue could be helpful, I might miss something like a libary, but I don't know.

Thank you

[Tux]

Hey thanks for the info, I use arch too and didn't even think about checking raine package in aur !

It's a little outdated, still using 0.64.16 here, but I didn't tag git for 0.91 yet, and there are big changes in the way it's built for 0.90 so it's no big surprise.

Well I'd say it's probably a build problem actually there since as you say the windows version works well here, if it was only neocd I would say a problem with sdl_sound, but since there is neogeo also in it, I am not sure...

Eventually drop a message to the maintainer of the package and you can tell him to post here if he needs.

(I'd like to give a link to the aur package on the download package, but I'll avoid to do that if it crashes on things like that... I'll eventually try it, but it's an optimized build without debug symbols so it's hard to guess what went wrong here.)

edit : I tested it, and I confirm the crash, I would say it seems linked to the sound, but not sure without a debug build, there is no message to see, just a crash as soon as the game tries to emit a sound (after the neogeo bios logo). I'd say rebuild in debug mode and run it from gdb, but here you can't do that with that binary, post to the maintainer then... I can ony confirm it shouldn't happen.

 

edit 2 : found the cause, I looked into the build directory, it's just that he forces an optimization for "generic" cpus, and apparently there is something there not appreciated in the build. Actually this file is forced to pentium3 in git since 2016... and it was even in the source archive he used, I checked. He used x86_64, which is not a good idea, 0.64.16 is 32 bits only ! Anyway he should just have used the default cpuinfo instead of trying to change it.

I can attach the fixed binary to this post, but you should really send a message to the maintainer... and he is behind by quite a few builds already, this 0.64.16 is from december 2018 ! More than 1 year late. Oh well I will give you instructions on how to fix it rather than attach the binary : just go to the directory where you have the PKGBUILD and all the other files, type :

cd src/raine-0.64.16

edit the cpuinfo file so that it should be like this :

_MARCH=-march=pentium3 -mtune=pentium3
CPU=pentium3

then type

make clean
make -j8

(-j followed by your number of cores). It will make a new binary, now just copy the raine binary you will get to /usr/bin, you are done.
Or alternatively you can edit the PKGBUILD file, and remove these 3 lines :

  # 'detect-cpu' script does not recognize most recent cpus, use generic optimizing
  echo "_MARCH=-march=${CARCH/x86_64/x86-64} -mtune=generic" > cpuinfo
  echo "CPU=generic" >> cpuinfo

then save, and delete the pkg and src directory and the xz file, re-run makepkg -si and it should be ok this time !

Edited May 3, 2020 by Tux

[alocacoc]

Thank you for your detailed research.

I contacted the package maintainer to fix it and gave him the link to this forum to find the information you provided to us.

I feel its better he fix it in the main pkgbuild for everybody, rather I fix it only for myself.

I'll post a message here once its working with the official pkgbuild.

Thank you so much.

[alocacoc]

The maintainer seems to have abandoned the package.

I didn't bother installing the 32Bit version, I'm not sure if it's better, but it gave me a CRC error at the checksum check (after manually entering the version number) and the 64Bit version not.

Your new pkgbuild works well if its installed with:

yay --editmenu -S raine

and changed the line:

pkgname=raine64

to

pkgname=raine

Thank you for your help and all your great efforts.

[Tux]

Ah some feedback at last !

Thanks, yeah the guy seems to auto build a lot of packages, probably too busy to reply to almost anything !

Well no version is better, but they are really different, I mostly use the 32 bit one because it's fast even for a debug build without optimization.

why didn't you try to install the .tar.xz files ? They are not signed but it shouldn't matter. I don't know this --editmenu flag, I'll take a look later, thanks for the feedback anyway ! (normally installing the xz file is done using pacman -U file.tar.xz simply).

and why not using simply makepkg -si to install the pkgbuild file ? yay is useful to install automatically packages from aur, but here there is no repository so there is not much point in using yay...

and edit 2 : the package name has no errors : raine is the name of the 32 bit package because it's the default version, the one which exists since 1998. raine64 is the new 64 bit version using C cpu emulators and C video functions instead of asm. Since they both share the same data files it was a little awkward, I thought about making the data files an external package but since there is no repository it wouldn't be very convenient. It's the best way I found so far...

Edited June 18, 2020 by Tux

[alocacoc]

I think there have to be 2 packages, raine and raine64. Both have to be exclude the other in the pkgbuild in the 'Conflicts:' line, so you can only use one at a time. 

I think the goal is not to install this package for me or for you, but to have two aur entries that fit into the pacman manager database for everybody.

Many people like to use the Raine build, but they don't, because they don't spent the time to manually fix the pkgbuild. They even don't get to the idea to search on the website or forum to fix it. Or they don't know anything about pkgbuild (like me).

They just use a different emulator that is more easy to install, because the most games are emulated by other emulators the same. I just insist to use Raine because of NeoGeo CD and because I used and liked it before.

Even multiple Retroarch libretro cores provide NeoGeo CD emulation by now and its very cross platform. Most people like to use Retroarch over individual emulators nowadays, because its availible on so many platforms and one GUI and one set up for all cores.

But I'm not sure if Raine can easily be ported to a libretro core.

Edited June 18, 2020 by alocacoc

[Tux]

I wouldn't want to port it to libretro, libretro is good for emus which run their games with a minimum of options, raine has a swarm of options !

so no, forget it.

And for aur, yeah well it would mean trouble for me, because signed packages, make the package to be accepted and so on. For now I chose the easiest path for me, sorry if it's too hard for some ppl... !

[alocacoc]

I understand that, at least everybody who is willing to spend some efforts can make it work in AUR with your new pkgbuilds.

You're really dedicated, thank you.