Is Yabasanshiro emulator coming on retropie?
-
@NecFan said in Is Yabasanshiro emulator coming on retropie?:
SSF is notoriously the best Saturn emulator.
There are many criterias for "best emulator" : speed, compatibility, enhanced features (like improving original gfx), ...
SSF is well-balanced : it's fast (but yabasanshiro might be even faster with its dynarecs & gpu acceleration ?), it's compatible (iirc ~92%, only second behind mednafen/beetle at ~95%), but afaik it doesn't have any enhanced feature.On a raspberry pi i think it's a really good prospect, but i wouldn't call it the"best Saturn Emulator" since imho there are superior choices if you aren't playing on a toaster.
-
sum vulkan news https://www.raspberrypi.org/blog/vulkan-update-now-with-added-source-code/
Join us on irc.freenode.net, #videocore channel. For specific questions like the issue we have here
-
@grant2258 has this news been added to every thread or something? I've had 4 notifications from it just from threads I've been involved in, and I've seen it in at least 2 others!
Everyone is probably already aware from the existing topic on it.
-
this was posted 3 days ago cant control other threads where else is it posted? what you point here did you post the same question in every other thread it in. Im a little confused on your picking this thread alone.
-
@steeeb yabasanshiro doesn't support vulkan anyway... furthermore i think fixing gles support should be a priority instead of adding support for another gfx api...
-
@barbudreadmon said in Is Yabasanshiro emulator coming on retropie?:
@steeeb yabasanshiro doesn't support vulkan anyway... furthermore i think fixing gles support should be a priority instead of adding support for another gfx api...
Vukan is the way forward it wil be the defacto standard in time
-
@grant2258 said in Is Yabasanshiro emulator coming on retropie?:
Vukan is the way forward it wil be the defacto standard in time
While i agree with that, support still has to be added to the emulators, and fixing current issues should be a priority over implementing new stuff.
-
@barbudreadmon said in Is Yabasanshiro emulator coming on retropie?:
While i agree with that, support still has to be added to the emulators, and fixing current issues should be a priority over implementing new stuff.
Its been said before to get this resolved you need to identify the issue and report it in a way that is meaningful to devs.
Its the same when A bug appears in libretro users are asked to provide enough information to work with. If the devs know the specifics they can work on fixing it. Is there more than one emulator suffering from this issue? afaik its just here i could be wrong.
-
@grant2258 said in Is Yabasanshiro emulator coming on retropie?:
Is there more than one emulator suffering from this issue?
No idea, the only thing i know is that the pi4 is the only arm+gles3 device having this issue with yabasanshiro.
Can you define meaningful report ? Is reporting how to reproduce this issue on their forum not sufficient ? I consider myself lucky when i get that much in a bug report.
-
@barbudreadmon said in Is Yabasanshiro emulator coming on retropie?:
No idea, the only thing i know is that the pi4 is the only arm+gles3 device having this issue with yabasanshiro.
Can you define meaningful report ? Is reporting how to reproduce this issue on their forum not sufficient ? I consider myself lucky when i get that much in a bug report.No not really your asking a dev to dig through a whole emulator. Your not singling out or narrowing the problem.
You cant tell them where it fails what layer is causing it and what function is only a real dev with real experience with this core and gles can report a bug effectively.
Its like saying look linux crashes with this app a fix it. The dev from the app awould need to identify the suspected cause and report it to gles team where its failing. Asking gles folks to work out if its your apps issue or there themselves is a big ask. Im sure someone with more experience will report the issue one day in a way that will get it fixed. It would actually be good to have more fails else where to help narrow the issue down in all honesty
-
@grant2258 i think https://www.raspberrypi.org/forums/viewtopic.php?f=68&t=270359&p=1641195&hilit=yabasanshiro#p1641195 is already providing some nice information though, i would be very happy if i ever had a bug report with that much details in any project i'm involved with...
-
I dont see any definitive info there. It could still be a core or driver bug at this point. Its a start though anyway dont want a 1000 posts on this again. A solid report with concrete info will sort this issue wherever it is.
https://github.com/libretro/RetroArch/issues/10711 was assumed to be gcc 10 an it wasnt the truth is stranger than fiction sometimes
-
@grant2258 said in Is Yabasanshiro emulator coming on retropie?:
https://github.com/libretro/RetroArch/issues/10711 was assumed to be gcc 10 an it wasnt the truth is stranger than fiction sometimes
More recent version of compilers being sometimes more sensitive to program bug is nothing new, and the whole bug looks like something that would have been totally avoided from the beginning whatever the compiler if the coder used something like ASAN. This bug can't be compared to a bug where one program work properly on every known gles3 devices minus one.
-
i don't think there's much more to be said about the bug - detailed info is here: https://github.com/devmiyax/yabause/issues/737 - without someone who understands GLES/shader code to look at it (eg, devyimax), no amount of more info will help.
-
Anyone have success building this on Raspberry PI OS 64bit beta? I've apparently gotten all the dependencies covered but build is failing with:
Linking CXX executable yabasanshiro /usr/bin/ld: firebase-cpp-sdk/external/src/curl-build/lib/libcurl.a(asyn-thread.c.o): in function `gethostbyname_thread': /home/pi/yabause/build/src/qt/firebase-cpp-sdk/external/src/curl/lib/asyn-thread.c:315: undefined reference to `Curl_ipv4_resolve_r' /usr/bin/ld: firebase-cpp-sdk/external/src/curl-build/lib/libcurl.a(asyn-thread.c.o): in function `Curl_resolver_getaddrinfo': /home/pi/yabause/build/src/qt/firebase-cpp-sdk/external/src/curl/lib/asyn-thread.c:594: undefined reference to `Curl_ipv4_resolve_r' collect2: error: ld returned 1 exit status make[3]: *** [src/qt/CMakeFiles/yabause-qt.dir/build.make:1674: src/qt/yabasanshiro] Error 1 make[2]: *** [CMakeFiles/Makefile2:380: src/qt/CMakeFiles/yabause-qt.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:392: src/qt/CMakeFiles/yabause-qt.dir/rule] Error 2 make: *** [Makefile:264: yabause-qt] Error 2Any thoughts on what could be the cause?
-
about the cause no , about a quick and dirty hack i would edit asyn-thread.c and remove the reference to Curl_ipv4_resolve_r at line 315 & 594, the emu doesn't need to go online anyway
-
@grant2258 Just confirming this addition worked. Got the retro_arena GUI and even started Sega Rally. Did not have the patched shaders so graphics were not correct and crashed just before the race began, but this is progress.
Note I'm working on this using Rasberry Pi OS 64bit beta.
Only other change I've made was to rp64.cmake:
set(CMAKE_SYSTEM_PROCESSOR arm)
to
set(CMAKE_SYSTEM_PROCESSOR aarch64) -
@myzar Yes, I did that and got further but in the end I've switched over to the retro_arena GUI and now I can at least start Sega Rally.
I already use QT for app development on Android and iOS. I really don't want to use it when I'm trying to have some fun.
-
@acidtech said in Is Yabasanshiro emulator coming on retropie?:
@grant2258 Just confirming this addition worked.
Are you referring to the SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES); if so thats good news!
-
@grant2258 Yes, SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.