• 1
  • 164
  • 165
  • 166(current)
  • 167
  • 168
RetroPlayer Test Builds (updated for Nexus)
The fixes for bugs #1, #2, #3 and #4 rebased on Omega (21.0) are here: https://github.com/KOPRajs/xbmc/commits/...haders-v3/

I've also done some testing and have confirmed #5 and #7 in Omega (I've added screenshots to the previous post). The #6 is not confirmed in Omega yet (hopefully it is fixed already, but we'll see).
Reply
I've added a new fix: https://github.com/KOPRajs/xbmc/commits/...haders-v3/

e0eb7bf - fixes bug #5 (@garbear, this time please double check if I choose good place for the check if the game has changed resolution)
Reply
Love seeing this progress! I borrowed time from this weekend to do some v21 final builds that I need to upgrade my main installs from v20. I'll include your fixes and test later when I'm able to.
RetroPlayer releases: https://github.com/garbear/xbmc/releases

Donations: eigendude.eth
Reply
It has turned out that my first try to fix #5 has worms in it: e0eb7bf

I haven't noticed that m_sourceRect.Width() returns float and comparing between int and float is a really bad idea. It worked for some resolutions, but for some emulators or display modes it was comparing 224 != 223.4 and it caused the shader preset to reload every frame which caused performance issues.

I've updated the fix here: 0b3f523

The check was moved to a different function so it can compare int to int. It works better now (no performance issues), but there is still one minor issue which happens randomly and that I haven't found the reason for yet. Sometimes it renders black screen after the game has changed the resolution until you open the Video filter selection GUI (that fixes it). This issue doesn't happen when the game is started from a savestate, only when the emulator is started as a new game and only if it is changing the resolution (like e.g. Beetle PSX does). Also it is worth mentioning that the issue #5 is not OpenGL specific. I've successfully reproduced it on Windows 21.0 rc2 build as well. I can't test the fix on Windows, but in theory it should fix the issue for every renderer including the WinRenderer.

The issue only affects emulators which change the resolution during the gameplay and looks like this:

Image

The c009275 was updated as well. This one should not change any functionality, it is just an optimization and a clean up of useless glUseProgram() calls.
Reply
I noticed the Kodi 21 flatpak includes a game, MrBoom, but it crashes kodi when attempting to run it.
This is on Linux, ubuntu 23.10, Intel N100. Using GBM windowing (no X11/wayland)

Are there others running into the same problem?

The last few lines of the crashlog are:

crashlog:
2024-04-12 01:11:30.712 T:1032     info <general>: Skipped 2 duplicate messages..
2024-04-12 01:11:30.712 T:1032  warning <general>: CreateLoader - unsupported protocol(thumb) in thumb://None/
2024-04-12 01:11:31.240 T:1032    error <general>: Could not find suitable input format: x-directory/normal
2024-04-12 01:11:37.935 T:7        info <general>: RetroPlayer[PROCESS]: Created process info for GBM
2024-04-12 01:11:37.949 T:7       error <general>: Create - Error creating /app/share/kodi/addons/game.libretro.mrboom/resources/system
2024-04-12 01:11:37.950 T:7        info <general>: AddOnLog: game.libretro.mrboom: retro_variable (SYSTEM)    { 'mrboom-teammode', 'Team mode; Selfie|Color|Sex|Skynet' }

2024-04-12 01:11:37.950 T:7        info <general>: AddOnLog: game.libretro.mrboom: retro_variable (SYSTEM)    { 'mrboom-nomonster', 'Monsters; ON|OFF' }

2024-04-12 01:11:37.950 T:7        info <general>: AddOnLog: game.libretro.mrboom: retro_variable (SYSTEM)    { 'mrboom-levelselect', 'Level select; Normal|Candy|Penguins|Pink|Jungle|Board|Soccer|Sky|Aliens|Random' }

2024-04-12 01:11:37.950 T:7        info <general>: AddOnLog: game.libretro.mrboom: retro_variable (SYSTEM)    { 'mrboom-aspect', 'Aspect ratio; Native|4:3|16:9' }

2024-04-12 01:11:37.950 T:7        info <general>: AddOnLog: game.libretro.mrboom: retro_variable (SYSTEM)    { 'mrboom-musicvolume', 'Music volume; 100|0|5|10|15|20|25|30|35|40|45|50|55|60|65|70|75|80|85|90|95' }

2024-04-12 01:11:37.950 T:7        info <general>: AddOnLog: game.libretro.mrboom: retro_variable (SYSTEM)    { 'mrboom-sfxvolume', 'Sfx volume; 50|55|60|65|70|75|80|85|90|95|100|0|5|10|15|20|25|30|35|40|45' }

2024-04-12 01:11:37.997 T:7        info <general>: GAME: ------------------------------------
2024-04-12 01:11:37.997 T:7        info <general>: GAME: Loaded DLL for game.libretro.mrboom
2024-04-12 01:11:37.997 T:7        info <general>: GAME: Client:              Mr.Boom (Bomberman)
2024-04-12 01:11:37.997 T:7        info <general>: GAME: Version:             5.3.0.157
2024-04-12 01:11:37.997 T:7        info <general>: GAME: Valid extensions:
2024-04-12 01:11:37.997 T:7        info <general>: GAME: Supports VFS:        true
2024-04-12 01:11:37.997 T:7        info <general>: GAME: Supports standalone: true
2024-04-12 01:11:37.997 T:7        info <general>: GAME: ------------------------------------
2024-04-12 01:11:37.997 T:7        info <general>: RetroPlayer[PLAYER]: Opening standalone
2024-04-12 01:11:37.998 T:7       error <general>: AddOnLog: game.libretro.mrboom: HARDCODED_RETRO_SERIALIZE_SIZE=SIZE_SER+13*8

2024-04-12 01:11:37.998 T:7        info <general>: GAME: ---------------------------------------
2024-04-12 01:11:37.998 T:7        info <general>: GAME: Game loop:      true
2024-04-12 01:11:37.998 T:7        info <general>: GAME: FPS:            60.000000
2024-04-12 01:11:37.998 T:7        info <general>: GAME: Sample Rate:    48000.000000
2024-04-12 01:11:37.998 T:7        info <general>: GAME: Region:         NTSC
2024-04-12 01:11:37.998 T:7        info <general>: GAME: Savestate size: 18408
2024-04-12 01:11:37.998 T:7        info <general>: GAME: ---------------------------------------
2024-04-12 01:11:37.998 T:7        info <general>: AddOnLog: game.libretro.mrboom: Mr.Boom: Plugging device 1 into port 0.

2024-04-12 01:11:37.998 T:7        info <general>: AddOnLog: game.libretro.mrboom: Mr.Boom: Plugging device 1 into port 1.

2024-04-12 01:11:37.998 T:7        info <general>: AddOnLog: game.libretro.mrboom: Mr.Boom: Plugging device 1 into port 2.

2024-04-12 01:11:37.998 T:7        info <general>: AddOnLog: game.libretro.mrboom: Mr.Boom: Plugging device 1 into port 3.

2024-04-12 01:11:37.998 T:7        info <general>: AddOnLog: game.libretro.mrboom: Mr.Boom: Plugging device 1 into port 4.

2024-04-12 01:11:37.998 T:7        info <general>: AddOnLog: game.libretro.mrboom: Mr.Boom: Plugging device 1 into port 5.

2024-04-12 01:11:37.998 T:7        info <general>: AddOnLog: game.libretro.mrboom: Mr.Boom: Plugging device 1 into port 6.

2024-04-12 01:11:37.998 T:7        info <general>: AddOnLog: game.libretro.mrboom: Mr.Boom: Plugging device 1 into port 7.

2024-04-12 01:11:37.998 T:7       error <general>: Cheevos: Couldn't load patch file
2024-04-12 01:11:38.110 T:7        info <general>: Loading skin file: VideoFullScreen.xml, load type: KEEP_IN_MEMORY
2024-04-12 01:11:38.129 T:1639     info <general>: RetroPlayer[RENDER]: Configuring format 0RGB32, nominal 320x200, max 320x200
2024-04-12 01:11:38.130 T:1639     info <general>: RetroPlayer[AUDIO]: Creating audio stream, format = AE_FMT_S16NE, sample rate = 48000, channels = 2
2024-04-12 01:11:38.130 T:21       info <general>: CActiveAESink::OpenSink - initialize sink
2024-04-12 01:11:38.135 T:7        info <general>: RetroPlayer[RENDER]: Renderer configured on first frame
2024-04-12 01:11:38.169 T:21       info <general>: PulseAudio: Opened device Default in pcm mode with Buffersize 150 ms Periodsize 50 ms


############### END LOG FILE ################

############ END Kodi CRASH LOG #############
Reply
Hello, you should probably report this to the package maitainers. This thread is for Retroplayer development and not yet merged features, you're using a standard release.

The easiest way to test, if the issue is in the code itself or in the build, is to try LibreELEC 12 beta 1. It contains Kodi 21.0 running on GBM as well.
Reply
(2024-04-12, 08:00)KOPRajs Wrote: It works better now (no performance issues), but there is still one minor issue which happens randomly and that I haven't found the reason for yet. Sometimes it renders black screen after the game has changed the resolution until you open the Video filter selection GUI (that fixes it).

I have found out what the issue was:

#8 - Black screen (or wrong scale) after source resolution has changed

After fixing the #5 by reloading the shader preset when the source resolution is changed, the new issue was revealed. When the preset is reloaded the MVPs of each shader pass are not being initialized (the UpdateMVPs() is not being called). It relies on being called from CShaderPresetGL :: PrepareParameters(), but it is only called if the viewport has changed. When the preset is loading for the first time the viewport is always considered changed. If the viewport hasn't been changed, the MVPs remain uninitialized (or not updated) which causes unpredictable shader scaling issues. Opening of any GUI window with the shader thumbnails fixes it, because the thumbnails trigger the viewport update. This issue mostly affects emulators which change output resolution (e.g. Beetle PSX) with multi pass shaders enabled (using Beetle PSX with the gbc-2x shader during the new game start is a good way to reproduce the issue). This can be solved by initializing of the MVP for every shader pass during the reload (after the texture has been created and SetSizes() has been called, see: https://github.com/KOPRajs/xbmc/blob/6a4...L.cpp#L335).

Both issues #5 and #8 should in theory affect video shaders in DirectX as well (I have only confirmed #5 in the 21.0 RC2 build, as I don't have Windows devel environment for testing).

I have added the fix to 6a48e83 (including the fix for DirectX, but it is not tested). I've also changed the way the shader preset update is triggered (the original version for reference: https://github.com/KOPRajs/xbmc/commit/7...16c0bfa649). Instead of comparing the buffer size in CRPBaseRenderer :: SetBuffer() it is now being done in the CShaderPresetGL :: SetVideoSize() because it seems more consistent with how the rest of the code works and it allows to simplify the CRPBaseRenderer :: Updateshaders(). Let me know if you liked the original version more. I'm also planning to rewrite the fix for #1 and #3 (2057a1c), because after moving the code which actually belongs to rendering from CShaderGL :: SetShaderParameters() to CShaderGL :: Render() in 2a7b0a7, part of the original fix is not needed anymore (we can revert the calls to videoShader->PrepareParameters() back to the loop in CShaderPresetGL :: PrepareParameters() because it will not overwrite anything anymore). The new fix should be more consistent with the DirectX code, but it will require a rebase, so I'll create a new branch for it.
Reply
Let's call it a day for now! Here is the revisited version: https://github.com/KOPRajs/xbmc/commits/...shaders-v4

It contains fixes for all identified bugs, that I'm currently aware of.
I can't reproduce the bug #6 in Omega, so this one is possibly already fixed upstream.
There is still bug #7, but it is not related to video shaders code and if I find a fix for it, I'll submit a PR to upstream.

Summary:
6e4f781 - clean up only, no functional changes
f9e061b - fixes #2
da12f87 - fixes #4
47847c0 - fixes #1 and #3
1022768 - fixes #5 and #8
8c0dd71 - clean up only, no functional changes
Reply
Fun With Flags: Comparing RetroPlayer video shader support vs. RetroArch:

Image

I've decided to compare them running side by side. I started with the CRT Geom and at first I was disappointed, because RetroPlayer clearly had darker colors. After some time spent investigating the issue, I've got the idea to compare the actual shader files, just to be sure. Guess what? The CRT Geom got updated in RetroArch! After syncing the shader files I've got an exact pixel to pixel match! Unfortunately, there are still other shaders, which are not rendered correctly, but we are getting closer.

The conclusion is, if you are going to compare, be sure to compare exactly the same shaders. You also need to set RetroArch to the GL video driver, not the GLCORE, otherwise it will use SLANG shaders instead of GLSL.
Reply
Love the progress so far!

(2024-04-18, 22:00)KOPRajs Wrote: The CRT Geom got updated in RetroArch! After syncing the shader files I've got an exact pixel to pixel match!

This result actually carries significance. Unimplemented file sync was the reason Windows shaders weren't merged. Which I now massively regret. I copied the files in git. Do they need to be updated?

(2024-04-17, 22:24)KOPRajs Wrote: Here is the revisited version: https://github.com/KOPRajs/xbmc/commits/...shaders-v4

I'm just now getting around to v21 final builds. I'm not testing anything in particular right now so the builds are based on your branch plus the RetroPlayer fluff.
RetroPlayer releases: https://github.com/garbear/xbmc/releases

Donations: eigendude.eth
Reply
(2024-04-21, 10:08)garbear Wrote: This result actually carries significance. Unimplemented file sync was the reason Windows shaders weren't merged. Which I now massively regret. I copied the files in git. Do they need to be updated?

I don't see this as a big problem. The shader files are part of the addon, we can release a new version of the addon with updated shader files anytime. It does not depend on the Kodi version. Also having older version of the shaders doesn't mean that they are not working fine. We just need to update them from time to time and be careful when comparing the frontend rendering between RetroArch and Kodi to compare really the same shader.

 
(2024-04-21, 10:08)garbear Wrote: I'm just now getting around to v21 final builds. I'm not testing anything in particular right now so the builds are based on your branch plus the RetroPlayer fluff.

I'm curious to test the new Windows build, because I've made some changes to the DirectX version of the shaders, but I couldn't tested it.
Reply
(2024-04-21, 12:24)KOPRajs Wrote: I don't see this as a big problem. The shader files are part of the addon, we can release a new version of the addon with updated shader files anytime. It does not depend on the Kodi version. Also having older version of the shaders doesn't mean that they are not working fine. We just need to update them from time to time and be careful when comparing the frontend rendering between RetroArch and Kodi to compare really the same shader.

Sorry, I was talking about HLSL shaders: https://github.com/kodi-game/game.shader...ts/pull/10

See the Update shaders to latest master version commit. That is 100% of what has changed in the last seven years.

I was worried about this, files getting out of sync, so at the end of GSoC 2017 I started working on a Python script to keep files up to date. But what happened is that the HLSL shader repo went unmaintained like 9 months after GSoC ended, so the solution was just to copy the files into our repo because they haven't changed since.

GLSL shaders are not unmaintained. So we're back to needing a way to sync or "curate" them. What do you think we should do?
RetroPlayer releases: https://github.com/garbear/xbmc/releases

Donations: eigendude.eth
Reply
(2024-04-21, 12:24)KOPRajs Wrote: I'm curious to test the new Windows build, because I've made some changes to the DirectX version of the shaders, but I couldn't tested it.

V21 final builds are up! https://github.com/garbear/xbmc/releases

The builds include fixes by @KOPRajs.

I'm also including an add-on repo for Acrtic Fuse. I've started using this skin for movie nights and intend to add game support to it someday.
RetroPlayer releases: https://github.com/garbear/xbmc/releases

Donations: eigendude.eth
Reply
New build works great and it looks like on LE12 all the visual glitches are fixed around shaders.

@KOPRajs did you say there's a way to add new shaders at this stage or is this something you were thinking about for the future ?
Reply
(2024-04-21, 22:33)garbear Wrote: GLSL shaders are not unmaintained. So we're back to needing a way to sync or "curate" them. What do you think we should do?

I think that there are not many changes for the GLSL shaders either. IMHO updating the shader folder from time to time with the release of the new version of the add-on should be fine. Even better if we finish the proposed changes for the GUI, then users can even update the shaders themselves or even download and try shaders from 3rd party sources. We might want to add a condition to include only HLSL shaders when building the add-on for Windows and only GLSL shaders when building the add-on for other platforms.

 
(2024-04-21, 22:39)garbear Wrote: V21 final builds are up!

I've tested the Windows build and it seems that my blind changes to the DirectX version don't break anything. The bugs #5 and #8 seem to be fixed on Windows as well.

 
(2024-04-22, 08:57)sunlollyking Wrote: New build works great and it looks like on LE12 all the visual glitches are fixed around shaders.

@KOPRajs did you say there's a way to add new shaders at this stage or is this something you were thinking about for the future ?

Great to hear that the fixes work in LibreELEC using GLES as well. Unfortunately, there is currently no way to add shaders from the GUI, but you can add shaders manually in the /storage/.kodi/addons/game.shader.presets/resources/ShaderPresetsGLSLP.xml file.


@garbear Please note that there are still known issues and many multipass shaders are not rendered correctly when compared to RetroArch. The last patch is WIP (5af3127). I haven't figured out the final solution yet.


P.S. My suggestion for a powerful enough x86 LibreELEC system is to use the CRT Geom for the retro feel and the XBRZ Freescale for high level upscaling. Both are single pass shaders tested to work 100% the same as in RetroArch.
Reply
  • 1
  • 164
  • 165
  • 166(current)
  • 167
  • 168

Logout Mark Read Team Forum Stats Members Help
RetroPlayer Test Builds (updated for Nexus)16