Libgdx on Libretro

Anything libgdx related goes here!

Libgdx on Libretro

Postby msx » Tue Jan 21, 2020 4:12 pm

Hi there, lately i've been experimenting in developing something like a "libretro" backend.

Libretro/Retroarch is a generic "game system" that can execute "cores". Each core is an emulator, or a virtual machine (like there's a "Mame" core, a "dosbox" core, etc Doesn't need to be an emulator too, some games are relased as "cores" ). The infrastructure provides for all window and input management, the core has to specify its desired resolution and has a callback method to render the scene (simplifying a lot). Audio, input, etc are unified for all cores. Cores are actually just dll/so with specific callback functions (obviously they can rely on external files). Most important callbacks are "init" (that inizialize the core) and "run" (which is called every frame and should render the scene).

Also, cores come in two variant: the classic variant draw graphics on a generic "ram buffer" that's then sent to the screen (like old 8 bit system), while the opengl variant is opengl-aware and receive an opengl framebuffer onto which to render. (this is becouse opengl is so ubuquitous that they consider skipping a layer of abstraction for performances).
The main gotcha of the opengl core is that you have to render not on the screen but on a framebuffer that is provided to you by libretro infrastructure (so that it can render its own gui on top etc). This shouldn't be a huge deal since, once bound, rendering on the framebuffer should be pretty transparent.

So i think it should be teoretically possible to have a "libgdx core" (based on opengl core). It would work something like this: the main C program (dll/so), on initialization should instantiate an embedded java virtual machine, load some java middleware (the libretro backend basically) and an ApplicationListener. On the "run" callback, the backend should call ApplicationListener.render(), like in a main loop (control here is obviously on the libretro side).
The system should also wire the libretro input system to the Gdx.input and same goes for audio etc., but this shouldn't be problematic.

I gave it a try and i was able to have a core that instantiate a jvm, load a jar and can execute java methods in response to any libretro callback, so the very basic infrastructure is there.

The problem is: if i put any kind of opengl call on the java callback, it crashes (without logs).

I've tested a simple:
org.lwjgl.opengl.GL11.glClearColor(1f, 0, 0, 1.0f);
org.lwjgl.opengl.GL11.glClear(org.lwjgl.opengl.GL11.GL_COLOR_BUFFER_BIT);

I think the problem is that it's not loading the native libraries correctly. I followed the trail and it should do that on the static initializer of org.lwjgl.opengl.GL.
But beside the native library problem, i was wondering if there's some other problem with sharing opengl context this way (like making calls from different dlls etc) that i should be aware of. Maybe it's necessary to have a jni layer that points back to libretro own stuff or something? Anybody have any experience in this kind of problems ?
msx
 
Posts: 5
Joined: Mon May 09, 2016 2:09 pm

Re: Libgdx on Libretro

Postby shatterblast » Tue Jan 21, 2020 10:53 pm

To my understanding, OpenGL requires firmware of some sort, or it will crash guaranteed. I believe it's possible to use "stub" drivers or similar from OpenGL itself. The .so files and similar usually search for actual graphics cards.

I think that the Android emulator has limited support for these type of fake graphics drivers, but by default, support for them is shut off once the build process for an emulator is finished. In other words, you would need an Android emulator build designed specifically to support these fake drivers in the first place. I know it's possible with the proper JVM commands if you try to build the open source version of Android yourself. However, these versions are not publicly released. They are meant for compatibility tests I believe, before something goes Beta or similar.

I know the root OpenGL library in C code already has its own versions of fake drivers. However, those are meant specifically for building OpenGL itself. Either way, I don't think that would be a valid solution in my own opinion. It would be comparing two different languages.

LWJGL encompasses the standard OpenGL calls and then some. It's a very neat project. It already innately has support for fake drivers, but I don't think you will find any in their project either. It's more of a really awesome code wrapper plus a lot more.

My first suggestion in this case would involve seeking advice from the maintainers at LWJGL. Someone from there could probably whip you together some kind of fake driver if you ask nicely.

I hope your efforts succeed.

1) http://forum.lwjgl.org/
2) https://github.com/LWJGL/lwjgl3
shatterblast
 
Posts: 653
Joined: Sun Jul 06, 2014 1:14 pm

Re: Libgdx on Libretro

Postby msx » Wed Jan 22, 2020 11:21 am

To my understanding, OpenGL requires firmware of some sort, or it will crash guaranteed. I believe it's possible to use "stub" drivers or similar from OpenGL itself. The .so files and similar usually search for actual graphics cards.


Yeah you're probably right. The fact is in this context OpenGL is already up and running (literally the window is already open). I think the problem is that lwjgl opengl binding don't "reconnect" with the already existing system (Sorry if i use wrong terminology, i'm no expert and just proceeding blindly).

Anyway i have a minor move forward. In my Java code i have the following:

Code: Select all
      System.out.println("****************CHIAMATO DOCALL***************");
      Configuration.DEBUG.set(true);
      System.out.println("Context: "+WGL.wglGetCurrentContext());
      System.out.println("Device: "+WGL.wglGetCurrentDC());
      System.out.println("lolTest: "+org.lwjgl.opengl.GL11.class); // ensure class has initializers done
      System.out.println("OK");
      
      String s = org.lwjgl.opengl.GL11.glGetString(org.lwjgl.opengl.GL11.GL_VERSION);
      System.out.println("Version is "+s);


Basically it sets up LWJGL with DEBUG messages and then attempt some queries

When running from within libretro, i get the following logs:

calling doCall
****************CHIAMATO DOCALL***************
[LWJGL] Version: 3.2.3 SNAPSHOT
[LWJGL] OS: Windows 10 v10.0
[LWJGL] JRE: 13.0.1 amd64
[LWJGL] JVM: OpenJDK 64-Bit Client VM v13.0.1+9 by AdoptOpenJDK
[LWJGL] Loading JNI library: lwjgl
[LWJGL] Module: org.lwjgl
[LWJGL] Loaded from org.lwjgl.librarypath: C:\Users\niclugat\AppData\Local\Temp\lwjglniclugat\3.2.3-SNAPSHOT\lwjgl.dll
[LWJGL] Loading JNI library: lwjgl_opengl
[LWJGL] Module: org.lwjgl.opengl
[LWJGL] Loaded from org.lwjgl.librarypath: C:\Users\niclugat\AppData\Local\Temp\lwjglniclugat\3.2.3-SNAPSHOT\lwjgl_opengl.dll
[LWJGL] Loading library: opengl32
[LWJGL] Module: org.lwjgl.opengl
[LWJGL] opengl32.dll not found in org.lwjgl.librarypath=C:\Users\niclugat\AppData\Local\Temp\lwjglniclugat\3.2.3-SNAPSHOT
[LWJGL] Loaded from system paths: C:\WINDOWS\SYSTEM32\OPENGL32.dll
[LWJGL] Loading library: jemalloc
[LWJGL] Module: org.lwjgl.jemalloc
[LWJGL] Loaded from org.lwjgl.librarypath: C:\Users\niclugat\AppData\Local\Temp\lwjglniclugat\3.2.3-SNAPSHOT\jemalloc.dll
[LWJGL] MemoryUtil allocator: JEmallocAllocator
Context: 131072
Device: 251730347
lolTest: class org.lwjgl.opengl.GL11
OK



All [LWJGL] lines are LWJGL telling me that it's finding the libraries and can proceed.
The Context and Device like are very important and are telling that we ARE within an opengl context and theres a device attached, so we should be good here (as far as i know).

Problem is the following call (to glGetString, but any other i tried) crashes.
msx
 
Posts: 5
Joined: Mon May 09, 2016 2:09 pm

Re: Libgdx on Libretro

Postby shatterblast » Wed Jan 22, 2020 12:07 pm

With LibGDX 1.9.10, you should use either Java 11 or 12 because of the supported Gradle version, not Java 13.

The next release might be different, but it's not Stable yet.
shatterblast
 
Posts: 653
Joined: Sun Jul 06, 2014 1:14 pm

Re: Libgdx on Libretro

Postby msx » Fri Jan 24, 2020 9:59 am

Thanks to the nice people on LWJGL i was able to have something running.

Ladies an gentlemen, here's the libgdx demo running on (a super crude) proof-of-concept libretro backend.

Image
msx
 
Posts: 5
Joined: Mon May 09, 2016 2:09 pm

Re: Libgdx on Libretro

Postby shatterblast » Fri Jan 24, 2020 3:16 pm

Congratulations on the success of your work!
shatterblast
 
Posts: 653
Joined: Sun Jul 06, 2014 1:14 pm


Return to Libgdx

Who is online

Users browsing this forum: Google [Bot], Majestic-12 [Bot] and 1 guest