Odroid XU4 MAME Performance?

barbudreadmon

@loggahead said in Odroid XU4 MAME Performance?:

Maybe its a rom version?

Roms for mame/fba must match the emulator version, 99.99% of the time they won't load at all if you pick a random rom on internet. I've serious doubts this is your issue since the game is loading. It's not an issue with the CPU overclock option either since raiden2 don't use it. Are you 100% sure you are using latest lr-fbalpha ? Not lr-fbalpha2012 or pifba ? Those 2 are full of bugs.

Loggahead

@barbudreadmon said in Odroid XU4 MAME Performance?:

Roms for mame/fba must match the emulator version, 99.99% of the time they won't load at all if you pick a random rom on internet. I've serious doubts this is your issue since the game is loading. It's not an issue with the CPU overclock option either since raiden2 don't use it. Are you 100% sure you are using latest lr-fbalpha ? Not lr-fbalpha2012 or pifba ? Those 2 are full of bugs.

I'm just using the stock lr-fbalpha which came loaded with the 4.3 build? I never loaded any optional versions of fba that I know of.

Heres a pic of what the first boss does. Notice his upper right and lower left legs are emulated properly but his upper left and lower right are messed up.

alt text

Also, every now and again, sprites will jump to a different location on the screen. This happens sometimes picking up power ups. You go to get it and will all of a sudden jump to a different spot and start floating around again. Some enemies do this too. But this happens rarely.

Anyways, not a deal breaker, I've just been assuming I was going to need a newer emulator to properly play Raiden II.

I also ended up loading Raiden Project on PSX which has Raiden 1 and 2, but the FBA version looks better imo other than the glitches.

barbudreadmon

@loggahead Actually you are right, there is an issue with 2 out of the 4 legs but it's not happening on my x86_64 computer (which i used it at first to look for your glitch). I'll look into the code and let you know if i find a fix.

barbudreadmon

@loggahead my guess about raiden2 : the rpi3 is struggling with it and some timer is going haywire because of this. If you get your hands on a odroid xu4 or a rpi3b+ (you can overclock the new model to 1.6Ghz easily from what i read) i would be curious to see if the issue persist.

Loggahead

@athman8 said in Odroid XU4 MAME Performance?:

Several MAMEdevs have an ODroid-C2, including Micko and myself. The problem is that there is no accelerated video for it yet; no GLES, not even baseline X11 acceleration. So while MAME shows gaudy Pi-crushing numbers in "-video none" benchmarks, you can't actually play it at a decent speed yet.When that changes, it should pretty quickly become the best-supported ARM board for MAME.

Cool! Thanks for the update! Being someone who got his first taste of emulation back around 2003, I love how much it has evolved and am excited to see where it goes in the future.

Loggahead

@barbudreadmon said in Odroid XU4 MAME Performance?:

i would be curious to see if the issue persist.

Roger that and thanks for checking! I'll keep that in mind in the future. I'm not in any hurry to pick a new board just yet. I've been having so much fun with what I've got.

On a sidenote, I've been playing Raiden II on the PSX rom "Raiden Project" which I actually do own. It plays well enough but isn't quite arcade perfect.

barbudreadmon

@loggahead Actually the issue is not with the rpi3 struggling. I think i figured the fix, just waiting for upstream advice before committing it since i'm worried about potential side effects. If everything goes well, it will be available later today.

@dankcushions @mediamogul :
As a side note, i'm not sure how retropie handle cflags for lr-fbalpha (the installation script at https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-fbalpha.sh seems really outdated, profile has been deprecated 2 or 3 years ago and platform will generally handle the right cflags if set with the appropriate value), but i noticed this game performs a lot better on my rpi3 when "--ffast-math" is enabled, probably because the driver uses a lot of arythmetics.

mitu

@barbudreadmon What would your recommend to change for the build step in the package ? Some optimization flags could be added via CFLAGS/CPPFLAGS, like the --fast-math directive.

barbudreadmon

@mitu replacing build_lr-fbalpha by something like this would probably be ok :

function build_lr-fbalpha() {
make -f makefile.libretro clean
local params=()
if isPlatform "rpi2"; then
params+=("platform=rpi2")
elif isPlatform "rpi3"; then
params+=("platform=rpi3")
fi
make -f makefile.libretro "${params[@]}"
md_ret_require="$md_build/fbalpha_libretro.so"
}

If you got something to detect if the platform is x86 and 32 bits, you could probably also add the FASTCALL=1 parameter

mitu

@barbudreadmon The RetroPie script already has some CFLAGS set by platform when compiling. For the PI3 they are

-O2 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -pipe

When running the compile with make -f makefile.libretro platform=rpi3 (and disabling the RP script CFLAGS), the flags added by the build detection are

 -O3 -marm -mcpu=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ffast-math

They're more or less equivalent in terms of cpu/arch specifications, what's missing is the -ffast-math and the FASTCALL for the x86 arch. For reference, these are set here.

barbudreadmon

@mitu iirc, -ffast-math includes -funsafe-math-optimizations, -O3 includes -ftree-vectorize, also -O3 will be included whatever you do when building lr-fbalpha, i think it's safe to build with both -O2 and -O3 (the later should override the first) but i'm not 100% sure.
-march=armv8-a+crc -mtune=cortex-a53 is the recommended setting for rpi3 in 64bits mode, i'm not sure what happens with performance when you use it in 32bits mode. With gcc-6.x i know you can also use -march=native in 64bits mode.

barbudreadmon

@loggahead btw, the fix was commited yesterday, now raiden2 runs flawlessly with lr-fbalpha on arm devices. You'll probably need to update from source to see those changes.

Loggahead

@barbudreadmon said in Odroid XU4 MAME Performance?:

now raiden2 runs flawlessly with lr-fbalpha on arm devices

YES !!! You and all involved ROCK !!! Thanks so much!!!

I just have to update the lr-fbalpha package right? I also plan to re-image and upgrade to 4.4 this weekend, I take it after I upgrade, I'll need to update fba again?

barbudreadmon

@loggahead said in Odroid XU4 MAME Performance?:

I just have to update the lr-fbalpha package right?

If you mean from binary, probably not. As said above you'll probably have to update from sources.

Loggahead

@barbudreadmon said in Odroid XU4 MAME Performance?:

As said above you'll probably have to update from sources.

K. Ill give it a shot tonight! Thanks again!

Loggahead

@barbudreadmon said in Odroid XU4 MAME Performance?:

@loggahead said in Odroid XU4 MAME Performance?:

I just have to update the lr-fbalpha package right?

If you mean from binary, probably not. As said above you'll probably have to update from sources.

This worked! Thanks so much again!