ptitSeb Gles2glide64 test

[Paul]

This build uses ptitSeb's updated version of gles2glide64.  It has a different frame-skipping strategy and several other optimizations.  I branched off the 2.4 branch, so it can be compared with a recent published version of Mupen64Plus AE for a fair comparison.  I'm interested in seeing how it  compares WRT game compatibility and speed.  I gave it another app name and package id, so both can be installed at the same time to make comparisons easier.

TEST #1: ptitSeb Gles2Glide64 plugin

TEST #2: ptitSeb Gles2Glide64, Neon and Float optimizations only

TEST #3: ptitSeb Gles2Glide64, Neon and Float optimizations only, plus updates by Gilles

I had time to run only a couple of very quick tests to make sure it wasn't crashing, so I am not at all positive that I have the frameskipping config hooked up properly (and possibly other build settings-- need to look at it more closely).  I'll have to take a closer look when I get home from work, and will post another build if changes are necessary.  If the frameskipping config is hooked up properly, then it would seem to have solved the flashing problem in Paper Mario without having to disable frameskip (this is actually the reason I am not convinced it is hooked up, haha ).

[beansta]

Is the flashing problem where the rendered foreground disappears every fraction of a second on occasion? (Ive never noticed that before now since i use Rice to take advantage of HD textures). Didnt happen on this branch in the time i spent playing it (only about 10 minutes).
Also i like the logo.:p

[Paul]

Is the flashing problem where the rendered foreground disappears every fraction of a second on occasion?

The flashing in Paper Mario was enough to cause seizures when frameskipping enabled on gles2n64 or gles2glide64.  Problem wasn't happening in this version of gles2glide64 (but again, I need to make sure frameskipping is actually enabled..)  The much less serious flashing issue in Gauntlet Legends doesn't seem to be any different with this build on my phone.

[Mikhail]

I'm getting missing and black textures in all the games I tried sometimes they return back after resuming.

[Paul]

I suspect that is because you wouldn't have any type of resuming on the Open Pandora (assuming you are talking about Android activity resuming and not load-state, of course).  PtitSeb probably made that assumption (might require either fixing the texbuf changes or #ifdef'ing them)

[Mikhail]

That went over my head sorry, I just meant resuming after pressing one of the navbar buttons to break gameplay and it loading the autosave on resume.

[Paul]

Oh, that would be a different problem than I described.  The autosave's are just save/ load states.  Do you get the same problem if you do a slot save state, then a slot load state?

[gdark100]

I didn't know about these optimizations pitsteb made​​, very good! I only tested CBFD so far (my favorite game, i think everyone already know that  ). With the old version (play store version), i was getting ~6fps ingame, now with this version i can get ~15fps. Very good! But frameskip is worse, with frameskip "no more than 5", i only get 1~3 fps.  And is not a problem on the counter (like not counting skiped frames as rendered frames), since the game feels slower.

[Mikhail]

Loading a slot save where the textures worked after restarting doesn't make any difference the textures still don't showup, to get them to showup i've had to resume 5-10 or more times after exiting.

[littleguy]

Very interesting gdark.

We should make a version with just the NEON updates and see what speedups we can get.  i.e. don't include the alternative frameskip and texture stuff ptitseb made. @paul if you're busy I could probably do it tonight or the next.

[Paul]

I bet the Neon optimizations and changing types to floats helps considerably even without frameskipping.  I'll see if there is anything I can do to figure out why frameskipping might be slower (I am probably not the person to tackle this one though!)  If it can't be made to work, we could always continue to use our own less-sophisticated frameskipping code, and just take other optimizations from ptitSeb's code that are working well.

EDIT: littleguy beat me   I'll post a build with just the Neon pieces tonight (I don't think I'll be busy-- just need to check with Melinda HAHA)

[littleguy]

I'm gaining a better appreciation for the upstream devs with all these new forks...  I wonder which ones will push back upstream.  I plan to get our stuff reorganized and pushed once the version3 UI is in alpha testing.

https://github.com/paulscode/mupen64plus-ae
https://github.com/ptitSeb/mupen64plus-pandora
https://github.com/ricrpi/mupen64plus-rpi
https://github.com/libretro/mupen64plus-libretro

edit: I just created the mupen64plus-es organization on github.  If the others aren't interested in pushing upstream, perhaps we (I) can at least consolidate the Embedded Systems forks.  I know it's a pipe dream but it doesn't hurt to reserve the name.

[Paul]

Speaking of which

[gdark100]

Even super mario 64 is a little slower with frameskip. With "no more than 5", i get 25 fps, without frameskip it runs smooth at 30 fps. The littleguy frameskip implementation is the best for me.

[littleguy]

Speaking of which

Would be curious to see how much it would take to get Squarepusher's glide plugin ported back to compatibility with mupen64plus-core.