Is Yabasanshiro emulator coming on retropie?

dankcushions

@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.

BuZz

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?

notthesame

@dankcushions is it okay to post from another website?

notthesame

https://www.raspberrypi.org/forums/viewtopic.php?f=68&t=266652
this is where we posted the issue

notthesame

@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?

dankcushions

@notthesame said in Is Yabasanshiro emulator coming on retropie?:

https://www.raspberrypi.org/forums/viewtopic.php?f=68&t=266652
this is where we posted the issue

hmm, assuming _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...

BuZz

@dankcushions I can confirm that's not the issue. (That define is set in my test case).

dankcushions

thanks @BuZz!

@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!)

notthesame

@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.

notthesame

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 doom broken.jpg
before progress doom fix.jpg
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"

thanks

BuZz

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.

notthesame

@BuZz thank you

notthesame

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

dankcushions

@notthesame interesting! is devyimax aware of your findings? i think you should update https://github.com/devmiyax/yabause/issues/704 - maybe the solution is obvious now to them

notthesame

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

@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.

notthesame

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.

notthesame

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
Shaderlog:
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.

dankcushions

@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?

notthesame

hey, i can build the lr-yabasanshiro then post, i think it does have a build shader error,
git clone https://github.com/libretro/yabause.git -b yabasanshiro
in terminal of course, then
cd yabause
go to makefile /home/pi/yabause/yabause/src/libretro/makefile and
add LDFLAGS += -latomic save and then
make -C yabause/src/libretro ARCH_IS_LINUX=1 FORCE_GLES=1 HAVE_SSE=0 DYNAREC_DEVMIYAX=1 USE_ARM_DRC=1

maybe you guys can mess with it, i really dont know what else is wrong here

okay heres not compiling the log when compiling lr-yabasanshiro, that wont compile cos its giving a error, i found this by looking at some alexa compile on the pi also(wasnt easy hehe) so i found the code

the reason i place the broken compile is might be the wrong way of compiling and the second so it might be corrrect but something needs to be fixed.

LDFLAGS += -latomic

place right on the top inside of makefile near the other commands then compile paste below HAVE_FSEEKO = 0 then save and compile it then should compile

this is the compile that works, ill also look at the error code and this code that compiles the emulator okay but it does have its errors
fixed compile

it is interesting, but in the shaders file i see this

#if defined(_OGLES3_)
"#version 300 es \n"
"precision highp float;\n"
"precision highp int;\n"
#else
"#version 330 \n"
#endif

version 330 and 300 for es, if we have es 300 then should it work for that, or is it looking for 330 version?
but im not familiar with that.

hope you find something, fixing theses color fixes is gonna be amazing sega saturn game play on pi4, i want to play cotton cos mame plays it slow, advance wont save my game configures, but this emulator is amazing on the pi4, with pi4 stage, im sure we will get full speed on saturn once we have better support, all games ran at almost 60fps, a few 3d at 34 or 40, but over all i am really impressed, but once color is fixed this wont effect how it ran with this bad colors.
im sorry for the mess im not good setting up a step by step mostly right now i just got up hehe.
thanks again for your support dankcusions good luck and i hope you do find a way to fix this :)