Author Topic: Glide GL ES 2.0 Port (WIP) (Read 50887 times)

xperia64 · « **Reply #45 on:** April 04, 2013, 05:28:57 PM »

Whoops, looks like its actually framebuffer->RDRAM copy thats needed, not framebuffer->vram. Curious as to if Glide64 even has that, I know napalm does..

Kris · « **Reply #46 on:** April 04, 2013, 06:09:43 PM »

Quote from: xperia64 on April 04, 2013, 05:28:57 PM

Whoops, looks like its actually framebuffer->RDRAM copy thats needed, not framebuffer->vram. Curious as to if Glide64 even has that, I know napalm does..

I've found most of the framebuffer stuff to work as it does with glide64mk2 on the PC. The large screen in Mario Kart is blank for me on android and pc unless I enable fb_read_always. You can change this in glide64mk2.ini [DEFAULT] not [SETTINGS] section. I don't think exposing every gfx option in the app is a good idea.

xperia64 · « **Reply #47 on:** April 04, 2013, 06:26:28 PM »

Wow!! The puzzle piece intro in banjo-kazooie actually works, albeit a lot slower

mudlord · « **Reply #48 on:** April 06, 2013, 08:12:19 PM »

of course its slower, you need to read every single frame for a CPU based fb effect to work.

littleguy · « **Reply #49 on:** April 16, 2013, 02:05:44 PM »

Can this be mirrored over to the github repo now? I'd like to start test merges with the new ae-bridge library and SDL 2.0.

littleguy · « **Reply #50 on:** April 16, 2013, 07:57:06 PM »

Just got around to checking this out again. I was getting force closes on launch due to a segfault, regardless of whether I merged to master first or not. I traced it down to some SDL initialization stuff in main.cpp, which was easily solved by reverting some lines of code back to the upstream version:

Spoiler: "patch" • show

This might fix the issue Paul was having with the depth buffer, possibly.

Anyhow, some recent bugfixes and cleanups on master have removed the need to even touch the java code for glide plugin compatibility. E.g. CoreVideo_SetCaption is now safe and the config file is now populated with the correct screen dimension.

littleguy · « **Reply #51 on:** April 16, 2013, 08:35:43 PM »

Ok once again I spoke too soon.

Nevermind what I just said, turns out the glide library wasn't even loading so the core was quietly reverting to Rice instead of crashing.

Kris · « **Reply #52 on:** April 16, 2013, 09:28:27 PM »

Quote from: littleguy on April 16, 2013, 07:57:06 PM

This might fix the issue Paul was having with the depth buffer, possibly.

I haven't heard back about whether it worked when when I first disabled CoreVideo_SetCaption. As things are setup with the java egl code neither SDL_GL_SetAttribute or CoreVideo_GL_SetAttribute probably do anything useful anyway. I will try remote testing a PowerVR device again soon although yesterday when I tried it just timed out.

Quote from: littleguy on April 16, 2013, 07:57:06 PM

Anyhow, some recent bugfixes and cleanups on master have removed the need to even touch the java code for glide plugin compatibility. E.g. CoreVideo_SetCaption is now safe and the config file is now populated with the correct screen dimension.

The fewer changes needed the better. I think there is room to simplify some things further maybe just being source files to pick and choose instead of being a library. I mentioned that the polygon offset stuff should be possible without passing the hardware type from java but as they are used differently in rice vs glide I don't think it can be shared.

Has it been considered to pass all the frameskip, screenstrech, bit-depth etc by config or as one big struct instead of separately?

Quote from: littleguy on April 16, 2013, 08:35:43 PM

Ok once again I spoke too soon. Nevermind what I just said, turns out the glide library wasn't even loading so the core was quietly reverting to Rice instead of crashing.

I ran into that too, when CoreVideo_SetCaption worked it changed the title so you could tell. It might be the removal of SDL_InitSubsystem you mention in that patch.

littleguy · « **Reply #53 on:** April 16, 2013, 09:51:02 PM »

Quote from: Kris on April 16, 2013, 09:28:27 PM

As things are setup with the java egl code neither SDL_GL_SetAttribute or CoreVideo_GL_SetAttribute probably do anything useful anyway.

You're right, they don't do anything in SDL 1.3, but they actually do get used in SDL 2.0. Which is now integrated in a test branch on github.

Quote from: Kris on April 16, 2013, 09:28:27 PM

The fewer changes needed the better. I think there is room to simplify some things further maybe just being source files to pick and choose instead of being a library. I mentioned that the polygon offset stuff should be possible without passing the hardware type from java but as they are used differently in rice vs glide I don't think it can be shared.

I agree, would be best not to involve java at all for polygon offset. I just noticed your code that grabs the gl renderer. Pretty slick, definitely worth developing on, as it would be much more transparent to the user and java, and easier to maintain in the long run.

Quote from: Kris on April 16, 2013, 09:28:27 PM

Has it been considered to pass all the frameskip, screenstrech, bit-depth etc by config or as one big struct instead of separately?

That's actually next on my agenda after we get the last kinks out of the SDL 2.0 integration. Most of the custom JNI functions in the ae-bridge are just this kind of static stuff, which really belongs in the config file.

Quote from: littleguy on April 16, 2013, 08:35:43 PM

I ran into that too, when CoreVideo_SetCaption worked it changed the title so you could tell. It might be the removal of SDL_InitSubsystem you mention in that patch.

Yeah, could be. Either way, using the mupen CoreVideo abstraction rather than the SDL api directly is more in the "mupen spirit" and would sit better with me if it works.

littleguy · « **Reply #54 on:** April 16, 2013, 10:02:43 PM »

By the way, I just tested glide with SDL 2.0 and it worked without a hiccup

(on my xperia play that is). First impression, didn't notice any performance improvement (or regression) in a quick run around the outside of the mario 64 castle (~18-25 FPS).

Still getting a segfault with glide on my Nexus 7, no matter where I merge. Any suggestions on how to track it down? Looks like something in the Tegra gles2 drivers. Here's the logcat (with backtrace) in case it helps:

Spoiler: logcat • show

littleguy · « **Reply #55 on:** April 17, 2013, 09:27:28 AM »

Segfault is occurring in init_combiner(.) in combiner.cpp, on line 292. This is the first line where glCompileShader is called. If I put a return statement right before this line, I can successfully launch the emulator (though I get a black screen of course). If I put a return statement right after this line, I get the segfault. Hope this helps...

Edit: When I comment out this line, the emulator successfully launches and the video appears to be fine. Getting full 30 FPS in mario on my nexus 7.

Paul · « **Reply #56 on:** April 17, 2013, 10:15:07 AM »

Quote from: Kris on April 16, 2013, 09:28:27 PM

Quote from: littleguy on April 16, 2013, 07:57:06 PM
This might fix the issue Paul was having with the depth buffer, possibly.
I haven't heard back about whether it worked when when I first disabled CoreVideo_SetCaption.

Sorry, I didn't realize that commit was related to the depth buffer problem (thought it was just to address the black screen behavior). I just built the latest commit on Metricity/glide branch, and it still has the problem. I haven't had much free time to run diagnostics to see whether it is just not picking a config with a depth buffer or what (been busy with a couple of contracts when I'm not at work).

Kris · « **Reply #57 on:** April 17, 2013, 10:29:53 AM »

Quote from: littleguy on April 17, 2013, 09:27:28 AM

Segfault is occurring in init_combiner(.) in combiner.cpp, on line 292. This is the first line where glCompileShader is called. If I put a return statement right before this line, I can successfully launch the emulator (though I get a black screen of course). If I put a return statement right after this line, I get the segfault. Hope this helps...

Edit: When I comment out this line, the emulator successfully launches and the video appears to be fine. Getting full 30 FPS in mario on my nexus 7.

I thought I remembered an un-merged commit from the pc version with this removed but couldn't find it when I had a quick look. That shader writing to fragdepth needs an extension in ES although it should just fail to compile it shouldn't crash.

littleguy · « **Reply #58 on:** April 17, 2013, 10:43:32 AM »

Quote from: Kris on April 17, 2013, 10:29:53 AM

That shader writing to fragdepth needs an extension in ES although it should just fail to compile it shouldn't crash.

I know practically nothing about shader programs, but a quick scan of the internet suggests the same... the driver should fail gracefully -- a total crash indicates a poorly written driver.

I looked through the original mupen history of this plugin, and then to gonitz's history even farther upstream. This chunk of code hasn't changed since the start gonitz's repository in march 2009. More evidence to suggest a driver bug.

Kris · « **Reply #59 on:** April 17, 2013, 11:29:56 AM »

I couldn't find any device that supports the extension anyway. I guess it will need to be disabled for ES although I haven't found out which games use it yet either.

I must have misremembered that there was a change removing set_depth_shader...

Yep it does sound like a driver bug.

Author Topic: Glide GL ES 2.0 Port (WIP) (Read 50887 times)

xperia64

Re: Glide GL ES 2.0 Port (WIP)

Kris

Re: Glide GL ES 2.0 Port (WIP)

xperia64

Re: Glide GL ES 2.0 Port (WIP)

mudlord

Re: Glide GL ES 2.0 Port (WIP)

littleguy

Re: Glide GL ES 2.0 Port (WIP)

littleguy

Re: Glide GL ES 2.0 Port (WIP)

littleguy

Re: Glide GL ES 2.0 Port (WIP)

Kris

Re: Glide GL ES 2.0 Port (WIP)

littleguy

Re: Glide GL ES 2.0 Port (WIP)

littleguy

Re: Glide GL ES 2.0 Port (WIP)

littleguy

Re: Glide GL ES 2.0 Port (WIP)

Paul

Re: Glide GL ES 2.0 Port (WIP)

Kris

Re: Glide GL ES 2.0 Port (WIP)

littleguy

Re: Glide GL ES 2.0 Port (WIP)

Kris

Re: Glide GL ES 2.0 Port (WIP)