Graphics renderer stuck on Software

[swindlesmccoop]

Just installed the latest version of the mod, and every time I start the game, I get a message saying that I'm using software rendering, even though in the settings it is set to OpenGL. Not sure what would cause this because I'm pretty sure I have all of the necessary drivers installed. Is there a list of packages required that I should check to make sure I fulfill the requirements?

System: Linux-5.15.4-artix1-1-x86_64-with-glibc2.2.5 GPU: Nvidia GTX 1660Ti

[multimokia]

Can you send your log.txt file please?

[swindlesmccoop]

Yep. It even says it's using GL renderer. log.txt

[multimokia]

This is literally the exact same issue I had before when I ran Kubuntu. (This was interestingly only an occurrence on my desktop, running a 3080, and not my laptop which has an intel integrated gpu + a discrete gpu, but that wasn't used for MAS if I recall)

Weird issue with how it handled my GPU entirely. I'm not sure why but the only thing that fixed it at least in there was modifying my install of MAS to run renpy7.4, which offers the GL2 renderer instead of GL1.

However MAS is kinda unstable here and there under it. (Chess is basically broken)

That said, I migrated to Manjaro and the issue is just gone. So I'm wondering if there's some low level deps we were both missing for our cards.

Either way this is 100% something that should be investigated

[multimokia]

As for it using software, Ren'Py has poor logs and it actually silently falls back to software after announcing Textures are not rendering properly.

[swindlesmccoop]

Figured out a little bit about the issue. Basically, one of the textures uses an ancient color pallet (whatever a8 is) and it probably just can't render it properly, for some reason killing the entire GL render pipeline. Apparently is an actual Ren'Py issue being triggered by this texture. Most likely related to https://github.com/renpy/renpy/issues/2162.

[Booplicate]

Note: switching from (or to) fullscreen mode and back might (temporary) fix this issue.

[swindlesmccoop]

I stopped playing the game for a bit but it worked just fine when I booted it up today. Only two things changed since I last played: deleting the entire $HOME directory and installing packages. Not sure if it would have anything to do with a configuration inside of ~/.renpy (I doubt it), so instead, I've attached the relevant part of my pacman.log file to help with investigation. Also, I can confirm that the full screen fix did not actually help in this situation, as it was one of the things I read and tried before submitting the issue.

[jvyden]

This just started happening to me after a full system upgrade a couple days ago on Arch Linux x86_64.

I tried the fullscreen workaround and initially it gave me, uhh... this...

After a restart it seemed to work fine after switching to windowed mode.

I get the same Textures are not rendering properly. and the open-twice strategy detailed in renpy/renpy#2162 does work for me even though it is a closed issue, however I do have to delete the lock file, otherwise I get the following exception:

[jvyden@the-overcooler Doki Doki Literature Club]$ ./DDLC.sh 
Traceback (most recent call last):
  File "/home/jvyden/.local/games/Doki Doki Literature Club/DDLC.py", line 198, in <module>
    main()
  File "/home/jvyden/.local/games/Doki Doki Literature Club/DDLC.py", line 195, in main
    renpy.bootstrap.bootstrap(renpy_base)
  File "/home/jvyden/.local/games/Doki Doki Literature Club/renpy/bootstrap.py", line 295, in bootstrap
    renpy.main.main()
  File "/home/jvyden/.local/games/Doki Doki Literature Club/renpy/main.py", line 419, in main
    game.context().run(node)
  File "/home/jvyden/.local/games/Doki Doki Literature Club/renpy/execution.py", line 438, in run
    node.execute()
  File "/home/jvyden/.local/games/Doki Doki Literature Club/renpy/ast.py", line 814, in execute
    renpy.python.py_exec_bytecode(self.code.bytecode, self.hide, store=self.store)
  File "/home/jvyden/.local/games/Doki Doki Literature Club/renpy/python.py", line 1719, in py_exec_bytecode
    exec bytecode in globals, locals
  File "game/0utils.rpy", line 5, in <module>
  File "python-packages/singleton.py", line 66, in __init__
singleton.SingleInstanceException: Another instance is already running, quitting. If the issue persists, restart your computer or manually delete '/tmp/-home-jvyden-.local-games-Doki Doki Literature Club-DDLC-.lock'

Open to trying anything.

[jvyden]

It appears I now have to open 3 copies of the game before it'll work. :upside_down_face:

From what I've noticed, every time I get MAS running on GL using the multiple-games strategy I have to open one more window to get it to run the next time, so I'm sure my RAM is going to just loooove to hear that.

It also appears that updating RenPy will solve the issue with their new gl2 renderer, as the issue mentioned above was closed 5 days ago with the following note from @ renpytom:

I believe the gl2 renderer won't have this problem, so closing this.

I've also tried the angle renderer, but according to renpy/display/core.py it's locked to Windows-only:

# Line 1796
if renpy.windows:
    renderers = [ "gl", "angle", "sw" ]
else:
    renderers = [ "gl", "sw" ]

Of course, sw is the software rendering mode.

[jvyden]

I've accidentally discovered a workaround thats a little more ..lets say bearable in comparison to the previous strategy.

This appears to be a problem with the compositor (I use kwin_x11, but this might also apply to other compositors/window managers.)

Disabling the compositor (Alt+Shift+F12 on KDE) allows the game to start normally. The compositor can be re-enabled again with the same shortcut and no problems occur.

What's interesting is that according to my friend MAS/RenPy is actually meant to disable the compositor anyways, but that doesn't happen for me since I have the ability for applications to disable the compositor disabled, thus causing the problem.

@multimokia Not sure what you think of this, but I'd say this can be closed now.

[Booplicate]

That's a nice catch!

I'd say we keep this open until we upgrade the engine. So other people can comment and receive help if needed.

[multimokia]

Wonder if we can do some in-MAS checks for the state on that potentially and meta topic our way into mentioning it.

[jvyden]

Can you fetch the rendering mode the game is in? If so I bet you could totally do that by seeing if the game is in software rendering and if kwin_x11 is running.

[multimokia]

That's what I'm thinking. The in-game settings would be incorrect through past experience with this issue, but probably some digging in renpy internals may reveal the actual setting

[jvyden]

I could be totally wrong about this as I lack experience with RenPy or Python in general but looking through RenPy's code, it looks like you can just check through renpy.display.draw.info["renderer"].

This example is taken directly from renpy/display/core.py:

# Line 1863
if renpy.display.draw and renpy.display.draw.info["renderer"] == "sw":
    renpy.display.video.movie_stop(clear=False)

The available renderers are the default OpenGL renderer gl, the windows-only angle, and of course software rendering as sw.

P.S I don't use Wayland so I don't know if this bug affects it but in the case that it does I would also check for kwin_wayland in addition to kwin_x11.

[jvyden]

The above draft MR addresses the meta topic.

[swindlesmccoop]

I use KDE Plasma and X11 so those do seem to be what's affecting it. However, I wasn't using any sort of compositor when I was having the issue (to my knowledge, unless there's a built-in one that is enabled by default). So it's either two separate issues, or one of the packages I installed somehow worked around it.

[swindlesmccoop]

I'd say we keep this open until we upgrade the engine.

As far as I'm aware, the engine was upgraded. Has this issue been addressed yet?

[dreamscached]

It was not upgraded yet.