RetroArch core issues #9936
Comments
|
OK, that looks like a good start. I'll look into making the iOS hack a bit more generic so you can use it. |
|
Awesome! Thanks a lot. BTW, I am trying to see if I can get any output with the software renderer - I see these errors right now when trying to use the software renderer - https://hastebin.com/puzexaneda.pas Am I missing any compile-time defines for making the dynarec PIC-compliant? I am trying to base the libretro port so far on the Headless target, so there is no NativeApp/UI being used. |
|
It does seem from another reported issue that we're failing PIC-compliance somewhere. If you can breakpoint there and get a good callstack, I can fix it very quickly. For bringup, you can enable the interpreter. |
… the new RetroArch port attempt (#9936)
|
Added a quick FBO override. |
|
Thanks, I will try to get that hooked up on the libretro side. As for the potential PIC issues, I get those errors with the software renderer when setting the CPU core to either Interpreter or JIT. Anyway, I will try hooking up the FBO override first. |
|
Oh, then it's probably the vertex decoder JIT. That can be turned off as well. |
|
Hi there, is there also an equivalent for this function that I could use? ' fbo_create_from_native_fbo We used that here after initializing PPSSPP - and before we enter the main loop - https://github.com/libretro/libretro-ppsspp/blob/master/libretro/libretro.cpp#L1130 Or is this no longer necessary? I should simply use the GLuint from the libretro framebuffer ? |
|
OK, I now get a crash here - (gdb) bt |
|
You shouldn't need fbo_create_from_native_fbo, right? Is draw = null there for some reason? |
|
Yeah, I hope I won't need that function. I am only setting coreParam.thin3d here - is that not enough? https://github.com/twinaphex/ppsspp/blob/master/libretro/libretro.cpp#L1189 |
|
Yeah, I have GetDrawContext just return NULL. I honestly don't know what is supposed to be done there or why we need all these abstractions now when they weren't there back in 2015. I also see no real good reference implementations from a headless perspective that I could base this new port on - https://github.com/twinaphex/ppsspp/blob/master/libretro/libretro.cpp#L97 |
|
Can't I just point DrawContext stuff to NULL? Libretro shouldn't really need this kind of drawcontext, all buffer swaps happen at the frontend level, no need to set swap interval either, its all frontend-bound. |
|
Back then PPSSPP didn't support so many backends. The GraphicsContext with swapbuffers you can just stub. thin3d is an abstraction used for drawing the UI using the same code for all the backends (GL, D3D9/11, Vulkan). You don't need it for that because you'll presumably skip the PPSSPP UI. But, we also use it for framebuffer management in the emulator to be able to share the rather complex framebuffer management code without creating YET another absraction layer. This is not really architecturally super-clean, but that's the way it is currently. So you still need to spawn the appropriate thin3d context for that reason. That should not be an issue though, it should easily work. |
|
You can skip the CreatePresets stuff though, it's only used for drawing UI IIRC. |
|
if I stub out the CreatePresets function call invocation, it crashes here instead - Program terminated with signal SIGSEGV, Segmentation fault. |
|
So I can get it to work with -O0, -O2 still produces the crash you can see. Anyway, as discussed on IRC, here are some details on how to get RetroArch compiling for Linux - This should be our official instructions for compiling RetroArch itself - http://buildbot.libretro.com/docs/compilation/ubuntu/ Now, as for compiling the core itself - do a git clone --recursive of my fork - https://github.com/twinaphex/ppsspp.git Once done, go to the directory 'libretro'. Run 'make'. When it's done, you should have a ppsspp_libretro.so file. This is the dynamic library core. You need to put that in RetroArch's cores directory. BTW, I am always online on IRC at freenode, so definitely hit me up if you have any further questions. |
|
I checked out and built retroarch in ~/retroarch, then built and copied ppsspp_libretro.so to ~/retroarch/cores/ , but when I run ./retroarch in ~/retroarch and choose Load Cores, it's not in the list. Any ideas? |
hrydgard
changed the title
|
Fixed one PIC bug, not sure if it'll do the trick: 8d04983 |
|
Hi there, not sure if the Cores issue is still a problem, but in case it is - You can go to Settings -> Directory. Look at what 'Core Dir' is set to. Your cores need to be placed there. You canalso change the path from that screen. |
|
If you're still getting that crash, it may be worth adding something like: bool OpenGLContext::BlitFramebuffer(Framebuffer *fbsrc, int srcX1, int srcY1, int srcX2, int srcY2, Framebuffer *fbdst, int dstX1, int dstY1, int dstX2, int dstY2, int channels, FBBlitFilter linearFilter) {
OpenGLFramebuffer *src = (OpenGLFramebuffer *)fbsrc;
OpenGLFramebuffer *dst = (OpenGLFramebuffer *)fbdst;
GLuint bits = 0;
if (dst == nullptr || src == nullptr) {
printf("Goodbye, cruel world.\n");
*(int *)0 = 1337;
}Just to make sure the backtrace isn't confused. SetNumExtraFBOs() shouldn't be calling BlitFramebuffer(),. I would think... I also recommend https://stackoverflow.com/a/2220565. -[Unknown] |
|
@twinaphex I think I know why Tekken 6 isn't working. First time you run it it shows you a system message dialog, and those aren't working currently because it can't access ppge_atlas.zim from PPSSPP's /assets. That file and compat.ini must be included somehow. Does RetroArch have a system for "system data files"? I guess it must, for BIOSes and so on? |
|
@hrydgard Yes, it has a system directory. The core can get a path to this through an environment variable call. |
|
I made a change to the libretro fork to hook up save states, however I had to move SaveState::SaveStart public to do so. Is there a better way to handle this? A wrapper function that could be used directly without extra modifications? The change I made is below: |
|
You shouldn't call that directly. It looks like you want -[Unknown] |
|
How's progress on this? Can we close this issue? |
|
@hrydgard Maybe that its merged now this can be closed? I'd suggest new issues be made for anything more specific. :) |
Hi there,
We are making a new libretro core for PPSSPP, this time with the intent of making it upstreamable.
We are currently hitting a blocking issue with the GL driver. We need to be able to override the backbuffer ID so that it points to an FBO, so that the final blit is being done to a FBO instead of the backbuffer. With libretro GL, a 'backbuffer' FBO gets made available to the core and the core should use it from that point on instead of the code just rendering to the backbuffer.
You can see here what ToadKing added to the code years ago -
https://github.com/libretro/libretro-ppsspp/commit/f30e7df7ef262a47e65767285d56e0016e797484
Apparently, Unknown tells me this is an issue on iOS too, and that there currently exists a hackish solution for it.
If this could be implemented in upstream, I could continue with the core. So far, I have it logging the main loop and __AudioMix seems to be returning a value (indicating it's processing some audio samples). Right now, rendering is not implemented yet, so I hope that when this gets added to upstream, we wil lfinally be able to output a picture.
Just for the sake of reference, I'm currently working on the new core port here -
https://github.com/twinaphex/ppsspp
The text was updated successfully, but these errors were encountered: