Why?

[kallisti5]

pygame now supports SDL2, why does renpy still depend on this?

[kallisti5]

To give a bit more information i'd like to work on porting renpy to Haiku (which has pygame), but will need to port and package pygame_sdl2 which is a fork pygame I guess?

I tried this "fast and dirty" converstion of the renpy source code to pygame, but didn't get very far...

 find . -name "*.py*" -exec sed -i 's/pygame_sdl2/pygame/g' {} \;

/Data/Code/renpy> python3 ./renpy.py 
pygame 2.0.0 (SDL 2.0.14, python 3.7.12)
Hello from the pygame community. https://www.pygame.org/contribute.html
Could not import _renpy. Please ensure that this program has been built
and unpacked properly.

You may be using a system install of python. Please run renpy.sh,
renpy.exe, or renpy.app instead.

Traceback (most recent call last):
  File "./renpy.py", line 201, in <module>
    main()
  File "./renpy.py", line 197, in main
    renpy.bootstrap.bootstrap(renpy_base)
  File "/Data/Code/renpy/renpy/bootstrap.py", line 292, in bootstrap
    import _renpy; _renpy
ModuleNotFoundError: No module named '_renpy'

[renpytom]

Ren'Py has been ported to pygame_sdl2 since 2015, and it's tested and working well. It's not a fork of pygame, but a reimplmentation of large portions of the API, with some additions to better support mobile platforms. Pygame_sdl2 is a thin wrapper around SDL2, so if SDL2 works on haiku, pygame_sdl2 should as well.

Modern versions of Ren'Py require OpenGL to function.

Note that Ren'Py doesn't currently support Python 3.

[kallisti5]

llvmpipe OpenGL rendering works fine on Haiku (mesa 21.3), as does SDL2. So pygame_sdl2 is going to be around for the long haul? If so I guess I need to migrate our pygame patches to pygame_sdl2 and package it for our ports system

Note that Ren'Py doesn't currently support Python 3.

I was wondering about that... the readme's don't really say anywhere about python version support. This might start to become an issue... a lot of distros are dropping python2 https://fedoraproject.org/wiki/Changes/RetirePython2

The setuplib.py stuff in renpy makes some assumptions on /usr existing, which breaks the library / include detection in Haiku. I patched around it locally, but it really isn't a great solution.

diff --git a/module/setuplib.py b/module/setuplib.py
index 928ea2722..a006ff009 100644
--- a/module/setuplib.py
+++ b/module/setuplib.py
@@ -24,6 +24,7 @@
 
 from __future__ import print_function
 
+import platform
 import os
 import sys
 import re
@@ -36,6 +37,9 @@ android = "RENPY_ANDROID" in os.environ
 # True if we're building on ios.
 ios = "RENPY_IOS" in os.environ
 
+# True if we're building on Haiku
+haiku = platform.system() == "Haiku"
+
 # True of we're building on raspberry pi.
 raspi = "RENPY_RASPBERRY_PI" in os.environ
 
@@ -68,7 +72,7 @@ cython_command = os.environ.get("RENPY_CYTHON", "cython")
 
 # The install variable is a list of directories that have Ren'Py
 # dependencies installed in them.
-if not (android or ios):
+if not (android or ios or haiku):
     install = os.environ.get("RENPY_DEPS_INSTALL", "/usr")
 
     if "::" in install:
@@ -80,7 +84,6 @@ if not (android or ios):
 
     if "VIRTUAL_ENV" in os.environ:
         install.insert(0, os.environ["VIRTUAL_ENV"])

 else:
     install = [ ]
 
@@ -143,7 +146,7 @@ def library(name, optional=False):
         rather than reporting an error.
     """
 
-    if android or ios or emscripten:
+    if android or ios or emscripten or haiku:
         return True
 
     for i in install:

Any thoughts on moving to a standard pkg-config for SDL detection? I'm assuming a python module exists for it.

/Data/Code/renpy/module> pkg-config sdl2 --cflags
-D_REENTRANT -I/packages/libsdl2-2.0.14-6/.self/develop/headers/SDL2
/Data/Code/renpy/module> pkg-config sdl2 --libs
-L/packages/libsdl2-2.0.14-6/.self/develop/lib -lSDL2

guess i'm getting off topic. Thanks for the clairifcation!

[renpytom]

Note that "/usr" is just the default for RENPY_DEPS_INSTALL, an environment variable.

There are no plans to use pkg-config. Ren'Py generally ships as its own thing, without being dependent on OS packages like that.