Yes, I only saw stutters in bios on switch so far… hence suspicion that its low spec issue. Which is still an issue
Windows 10 x64
Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
32 GB RAM
NVIDIA GeForce STRIX-GTX1080-A8G-GAMING (driver 565.90)
I tested the same games (Chrono Cross and Fighting Force) with shaders completely disabled, and the stuttering and lag were gone, even during the BIOS animation.
I use a preset by koko-aio-slang as the global shader for all my games in RetroArch - specifically the tv-slotmask-bloom.slangp preset with some additional features disabled (screen curvature, vignetting, etc.).
For testing, I loaded a lighter version of the shader from koko-aio (less scaling and fewer passes) - in Chrono Cross, the stuttering in the menu disappeared; in Fighting Force, stuttering during object destruction remained but was reduced.
I’m not complaining; I’m simply describing my tests and observations. With the full tv-slotmask-bloom.slangp shader preset, I haven’t observed similar issues on other PSX cores on my system, meaning the performance is quite sufficient.
1 Like
2 games you mention do change video mode… fighting force is emulating shake by changing geometry few pixels back and forth (although proper dev would probably say that its doing ticks variation or something like that). Chrono cross is using high res+60fps in the menu, while it’s normal with 30fps in game
I suspect this could be due to the way we allocate FBO based on geometry of the game rather than the output res. If we use output res then some shader blow out the GPU mem requirements because they need to work with multiple of that FBO thingy
Anyway. No one thinks you’re complaining, your reporting works helps a lot. Same goes to everyone else BTW. Thanks everyone. This is getting harder and harder heh. Not giving up though
3 Likes
I think you’ve done an absolutely amazing job over the past month, transforming a project originally designed exclusively for Linux into a cross-platform solution with extensive configuration options and functionality.
It would be foolish to give up now that we’ve achieved such incredible results. I’m truly impressed by your work!
2 Likes
https://codeberg.org/hueponik/goosestation-builder/src/tag/v0.5.1
I’m bumping the latest release to v0.5.1. Here’s what’s new since v4.0 (doy)
- Shaders on switch, slow but working (choose slang)
- Lightguns: GunCon/Justifier. Use provided overlay cfg for mousepointer-as-crosshair
- Controllers: fixed libretro input mapping for GunCon, Justifier, Mouse, DD Go, JogCon, NeGcon/NeGconRumble; DualShock analog-mode toggle combo
- Boot/AV: coreless boot (BIOS shell via Start Core);
- Stability: fixed Windows close-content crash
- Libretro cheats API (retro_cheat_set/reset);
- Build-time compat gamedb with recommended settings
Let me know if you notice any regressions (there’s always something)
3 Likes
Been playing quite a few titles, no issues so far. Where are we supposed to drop the lightgun overlay in Retroarch?
1 Like
Just logged to say that this works perfectly on my GNU/Linux systems.
I got it to build with and without docker, and it’s a breeze to use.
Upstream is a behemoth when it comes to dependencies, but this is in turn so lightweight, thanks! Many thanks for this, hueponik! 
1 Like
I just placed it in the root of the RetroArch\overlays folder, and then, with the game running, I selected the cursor_only.cfg preset from the “Overlays” section in the quick menu; it only works if RetroArch is in full-screen mode, in windowed mode, the cursor is already visible.
2 Likes
FYI. Thank you. I was able to play Point Blank by selecting Guncon in the core options, and used my normal TV overlay, I just had to select “Show mouse cursor with overlay”. I did not need this other “cursor_only.cfg” file.
2 Likes
@hueponik I have just noticed that selecting the Vulkan renderer in the core options, the games don’t run: they sound but RetroArch doesn’t even create a window. OpenGL works fine. This is on GNU/Linux + Wayland (no X11). OpenGL renderer works perfectly well, and of course software mode works perfectly too. So, is this a current/known limitation of Goosestation? Maybe it’s not been tested under pure Wayland yet?
1 Like
That’s what I use normally, pure Wayland where possible. It should work, what are your specs/GPU?
I’m on Debian Testing, with Radeon 780M graphics, labwc Wayland compositor (based on WLRoots).
The problem is now clear, looking at the RetroArch logs with verbose output enabled:
[libretro ERROR] [GooseStation] GPU: VP: CompileDisplayPipelines failed: Failed to load shaderc: Loading libshaderc_shared.so failed: libshaderc_shared.so: cannot open shared object file: No such file or directory
[libretro ERROR] [GooseStation] VideoThread: Failed to create presenter: Failed to load shaderc: Loading libshaderc_shared.so failed: libshaderc_shared.so: cannot open shared object file: No such file or directory
Thing is, I installed the libshaderc package, so I have the lib on the system:
manuel@debian:~$ find /usr -name libshader*
/usr/share/doc/libshaderc-dev
/usr/share/doc/libshaderc1
/usr/lib/x86_64-linux-gnu/libshaderc.so
/usr/lib/x86_64-linux-gnu/libshaderc.so.1
/usr/lib/x86_64-linux-gnu/libshaderc_combined.a
/usr/lib/x86_64-linux-gnu/libshaderc_static.a
However, GooseStation seems to be looking for libshaderc_shared.so instead of libshaderc.so. Any idea on why? Isn’t libshaderc.so the standard library file name?
I mean, libshaderc_shared.so seems redundant since it’s an .so, so of course it’s a shared library 
Hm, no, no idea. But you could build linux-static instead of linux target
Looking in goosify.sh, I see this block:
if(ENABLE_VULKAN AND NOT TARGET Shaderc::shaderc_shared)
find_path(_shaderc_inc shaderc/shaderc.hpp
HINTS ${CMAKE_PREFIX_PATH} PATH_SUFFIXES include REQUIRED)
find_library(_shaderc_lib shaderc_shared
HINTS ${CMAKE_PREFIX_PATH} PATH_SUFFIXES lib REQUIRED)
add_library(Shaderc::shaderc_shared SHARED IMPORTED)
set_target_properties(Shaderc::shaderc_shared PROPERTIES
IMPORTED_LOCATION "${_shaderc_lib}"
INTERFACE_INCLUDE_DIRECTORIES "${_shaderc_inc}"
INTERFACE_COMPILE_DEFINITIONS "SHADERC_SHAREDLIB")
unset(_shaderc_inc CACHE)
unset(_shaderc_lib CACHE)
endif()
PATCHEND
mkdir -p 'CMakeModules'
# Add: CMakeModules/GooseLibretroLinking.cmake
cat > 'CMakeModules/GooseLibretroLinking.cmake' <<'PATCHEND'
# Static-link shaderc and spirv-cross into libretro cores on Android, macOS,
# Windows mingw, and the Linux `linux-static` target. dlopen is impractical on
# Android (RetroArch loads cores with RTLD_LOCAL, Play Store sandbox makes
# shipping extra .so files awkward); on macOS/Windows nobody installs
# shaderc/spirv-cross system-wide; and for the static Linux core the whole
# point is to not depend on the host's libshaderc_shared.so / spirv-cross
#
# GOOSE_LIBRETRO_STATIC_DEPS is set by the linux-static Makefile target; it both
# enables this static-link path and (via the compile definition below) flips the
# matching #if branches in gpu_device.cpp from dlopen to direct symbol binding.
Isn’t that setting the use of libshaderc_shared.so?
Try building latest master. Apparently, google is being POS even in the library naming, insisting “shared” in the name of the lib which is against the debian’s standards. Anyway it should work now, let me know how it goes
Thanks for looking into it. Current GIT master still has the same problem apparently (note I am building it manually without Docker: copy the goosify.sh script into the pointer upstream commit sources, run it, and build).
So, still getting this with the Vulkan renderer:
[libretro ERROR] [GooseStation] GPUDevice: Failed to load shaderc: Loading libshaderc_shared.so failed: libshaderc_shared.so: cannot op
en shared object file: No such file or directory
[libretro INFO] [GooseStation] GPU: VP: passthrough vertex shader FAILED
[libretro ERROR] [GooseStation] GPU: VP: CompileDisplayPipelines failed: Failed to load shaderc: Loading libshaderc_shared.so failed: l
ibshaderc_shared.so: cannot open shared object file: No such file or directory
[libretro ERROR] [GooseStation] VideoThread: Failed to create presenter: Failed to load shaderc: Loading libshaderc_shared.so failed: l
ibshaderc_shared.so: cannot open shared object file: No such file or directoryAh, found the problem. I set this line: https://codeberg.org/hueponik/goosestation-builder/src/commit/31dfdcdc077c5b2caaeafc157a52504749f7831e/goosify.sh#L22323 …to be like this instead:
if (!lib.Open(DynamicLibrary::GetVersionedFilename("shaderc").c_str(), error))
…And Vulkan works because the core now loads libshaderc.so instead of searching for that google-absurd libshaderc_shared.so
Can you modify it on your repository, please? Unless there’s something wrong with that modification, of course.
1 Like
I’ll take a look, we don’t want to break other distros so I have to test first
Of course! Keep me updated, please
I have taken notes for my own builds anyway, so whatever you do in the end will not be a problem.
Try latest master, it should work
1 Like