Is Yabasanshiro emulator coming on retropie?
notthesame last edited by notthesame
@dankcushions hey there not sure if your interested in helping out fix this emulator to run on retropie/rpi4? thanks for your time
@notthesame i had the same colour issue with standalone libretro yabause, but i've not tried yabasanshiro. i saw within the source code there were some hooks for the retroarena project, which i was hoping to leverage. are you saying it has the same colour issue?
we have reported this to raspberry pi foundation, not sure when will it be fixed
are you sure it's a raspberry problem? it would seem strange to only have this colour issue in this particular emulator. it sounds like a yabause problem.
I've got a module for this but have the issue with the bad colours etc. Not got further than that. I also reworked a lot of the libretro kronos shaders to get them to compile but ran into an issue when compiling them and running out of registers.
Please can you link me to where it was reported upstream to RPI?
@dankcushions is it okay to post from another website?
this is where we posted the issue
@dankcushions i tired the retroarena yabasanshiro and has the same issue, can i post a image on here how it looks or is this enough information?
this is where we posted the issue
_OGLES3_is set during compile, it looks like highp is set:
#if defined(_OGLES3_) "#version 300 es \n" "precision highp float;\n" "precision highp int;\n" #else "#version 330 \n" #endif
maybe a build log, see if OGLES3 is set? not sure if it's part of the initial build or inferred later on...
@dankcushions I can confirm that's not the issue. (That define is set in my test case).
@notthesame you could try posting this info to your other thread. i'm not sure if the precision being set for float and int is enough to rule out their theory about it being a precision thing.
has this been raised with devyimax over at yaba-sanshiro?
(edit: i see they're the one who posted over at the Rpi forums!)
@dankcushions hey there again, yes
ill post this info over there and see what they say, maybe with this info they dig to see what it is.
thank you guys again and for your time.
im not familiar with theses codes they are openGl shaders, i changed the code 255.0 to 255.1 here are a bit of progress
after, this is 255.1 not sure how to fix the other layers.
ill keep trying heres the code
" vec4 txcol = texelFetch( s_color, ivec2( ( int(txindex.g*65280.0) | int(txindex.r*255.0)) ,0 ) , 0 );\n"
See the reply on raspberry pi forum. I believe the issue is the texture width is too big. As @gizmo98 mentioned to me, it would need to be changed to be a 256x256 texture size or so.
@BuZz thank you
im back with some progress, very exciting, btw the 256x256 i cant get it to work, not sure if i can use the x or do i need to use *, i tired color codes with theses codes, maybe 1.0 is dark and white make a gray color, but i cant to seem to understand it, the best thing was just to fiddle around and get some progress going.
i did run into some trouble like 3d games would cut off i was using numbers to high with that 255.0 or whatever it does, i thought it also used width, but i couldnt tell, it only changed colors.
i had to change a few things to get proper color, as you can see in the images, i have alot of ideas but i cant reproduce them and i did write them down, which help get all colors but i think didnt let me play 3d games,sega rally, but now it has no textures but a green looking something, but is a racing car, so far all games almost that i played run close to 50fps or at 60fps this color issue sh ouldnt effect performance, also im not overclocked so image what games are gonna run nice :).
for now no gameplay is gonna happen, until i fix thoses issues thank you
thanks, see if he looks into it, ill post what needs to be changed, which is odd, but also i reported the drivers to raspberry pi foundation, it seems that uniform and attribute state do not save.
its like putting water in the radiator cos it has a whole, everytime we try to drive the car it leaks but here the colors and shaders leave as soon as we load up the game, i couldnt advance anymore so thats it not sure where else to change or look just took the idea from devyimax.
i did report this to raspberry pi foundation but the way i see it, they havent look at the first question we had for about 1 month going to 13 days or so, im not a dev but if we have to we can try to fix this our selfs, i know i didnt fix yabasanshiro but it was a try, also i atleast tired to get sprites,text,animations to show, but something is reversed so atleast we can play that games, boy ill tell you and every saturn fan pi4 will be able to run theses nice and sweet, tho a few games like dead or alive, maybe viruta cop 1, will run a bit slow, but with more updates and fixes, vulkan i do think 1 day saturn will run really well on this pi4, which is all i really need to complete my gaming on pi, its something always wanted, thats my goal right now, mostly cos we have time hehe.
thanks again for posting lets see what he gets out of it, i know he might need to do a few things but best thing for now is if he can point the drivers to another again fly cast used piplineshaders https://github.com/libretro/flycast/commit/37cc00ed73f50f96da5d28352a6fb7dfb290826f
quicksilver last edited by
@notthesame it's possible that the post on the raspberry pi forums isn't getting a lot of views. It looks like the opengl ES section of that forum is barely used.
yeah that is the thing, but ill keep trying to post stuff, it will get fixed sometime, but i wish it get fixed now since we are at home, thats why i had the time to try to fix this emulators, i didnt sleep for almost 24hours hehe, thanks for your support everyone here and hope something comes up.
hey guys me again, okay i got 3 emulators that are saturn, 1 yabause qt, yabasanshiro, yabasanshiro qt, so i turned on log on the only 1 i could, they didnt wnat to show video, i think maybe cos its the same issue, or i didnt turn off software when i compiled not sure how to do this,
heres the log ```
GL_FRAMEBUFFER_BINDING = 0PG_NORMAL
Compile error in vertex shader. 1
0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.00 ES, 3.00 ES, and 3.10 ES
so i dont know if i should post this or if this can help with the issue. if anyone wants to try theses emulator let me know, they are for for desktop, now i seen people use the standalone in retropie not sure how to do this? anyways thats all information i got for this episode.
@notthesame oh interesting. GLSL 3.30 is the GLSL found in open gl 3.3. however, we typically compile for GLES support (the GL equivalent for mobile GPUs). i know that yaba-sanshiro supports mobile GPUs, so it sounds like a problem with the build, assuming you are getting this error with yaba-sanshiro? how are you building it? do you have a build log?