GLideN64 Android port

[retroben]

As in slowdown,do you mean that you can hear slowed down music and the resulting crackling and stutter?
Are you sure you are using the right version of the code? (8007913F 0000)
Please try that one above.

I am able to keep it mostly around 25-30fps/60fps with Rice and Dynarec on my x86 tablet on CountPerOp=1 and without crashing.
It should only so much as softlock during cutscenes with the code on.
The whole point was that I wanted to see if it could run at maxed out speeds on Shield TV's Tegra X1 chipset.
How is the performance so underpowered though?
Does this perhaps mean Android/Mupen64Plus AE has reached its global limit?
Maybe it is the same case that various PJ64 versions have,where 1.6 and 1.7(.0.50b23) are slower compared to 2.x which can run Tooie quite a bit faster.
This would mean Mupen64Plus needs certain improvements to combat the sluggishness.

Such a crying shame it is crashing in one of the most desired Android devices.
Hopefully Gillou or anyone else can check this out.

Also,if you are using it,DON'T use auto resume!
It causes the split-up pads to trigger a crash,so you'll have to always hit restart instead.

P. S. you can grab my "funpleted" save file from PJ64 forums and rename it to match the game filename to apply the save,I did this myself so I could use my save dependant "Groggy Cloner" code again.

The post with it...

http://forum.pj64-emu.com/showpost.php?p=53597&postcount=261

[fivefeet8]

@retroben

When the game slows down, the sound stutters and crackles.  I was using the code "8007913F 0001" before.  Just tried the code you posted, "8007913F 0000" and still the same.  The game slows down with the unlocked FPS, but full speed without sound issues when the code is disabled.  The game seems to normally run at 20 FPS in a lot of places.  If there was a code to keep the FPS at 30 FPS, it should be fine as that is what the frames hover around with the FPS unlocked to 60 FPS.

I'm always restarting the games when I run them.    I'll check out your save file and report back.  Maybe if I have some time, I'll post a video of the game. 

[retroben]

The game actually runs at 30FPS in almost every area,just drops some when CountPerOp rises.
It actually hits 60FPS max naturally in the giant cheese wedge,but if you take damage,it drops to a horrendous 15FPS.
Slow even on Dynarec,or is that causing crashing?
Thanks for testing as I am unable to since the lack of having one of those "beasts".

I still can't wrap my head around the fact it goes slow on that beast. (how is that even possible?)
Any chance you have too much stuff going on in the background like dozens of syncing options or a chance of bloatware?
Maybe there is an unfair clocking limit on Mupen64Plus AE causing any and every device to go slow in that situation.
If true,then it may need more Ghz access on CPU and more Mhz on GPU and maybe also a high priority feature.

I think I just figured it out,maybe it needs an optimized version for Aarch64 architecture in the off-chance that is causing performance issues.

Edit: Try every GFX plugin (Rice is the fastest for Banjo-Tooie) and make sure audio buffer is set to 2048 to maximize performance as a trade-off,it might be a large cause of slowdown if you have it set to a low number.

[Gillou68310]

I just updated master with latest gliden64 fixes.

[retroben]

Welcome back,thank you.

I know this should be asked in upstream,but what do you think about the Glover and Glover 2 dynarec crashing/broken interpreter issues?
The 2.4.4 interpreter runs both perfectly fine while alpha's interpreter has Glover 2 beta's characters frozen in place and uninteractable.
Despite the interpreter issues,GLideN64 actually has the best framerate for Glover 2 in interpreter mode,not just the smoothness but the speed as well.
Dynarec works briefly if you resume,but crashes once you change areas,maybe revealing an easy fix.
Just hoping you wanted to try something for these two games.

Edit: The polygon offset situation is still see through on GLES2 and wondering if the hack will ever be enabled.
(I am guessing by geometry,you meant that Rat Attack game?)

Also,DK64 has the white texture segments issue on the pile of coins in Gloomy Galleon.

http://www.2shared.com/photo/O3CCsm5d/DK64_Coinpile.html

[Gillou68310]

Sorry retroben I doesn't have much time these days I spend some hours this week working with gonetz in order to improve the gles2 variant of gliden64. Concerning glover games please test it on PC and open an issue upstream if it fails. It will be much easier for me to track core regression 

I'll create a branch for the polygon offset so you can make some experiments.

Also I'll check dk64 on PC to see if it's a gles specific issue. Could you send me a savestate?

I'm out for the weekend so I won't be able to work on the emu until monday.

[retroben]

I'm stuck as well until Sunday or Monday kinda.
Would a Mupen64Plus AE savestate work on PC?
I ask because the PC Mupen64Plus is a major pain to deal with from lack of a GUI,and any other alternate ones with a GUI have no support for DK64.

[fzurita]

I was finally able to get the x86 version of Mupen64plus to work with GLideN64, but the way I did it makes no sense to me.

To get it to work, I had to add the line:

Code: [Select]

LOG(LOG_VERBOSE, "TEST\n");
   

right before

Code: [Select]

triangles.num = 0;

in OpenGL.cpp at void OGLRender::_initData() and then recompile. I tried adding the logging in other places during initialization of the plugin and they seem to work as well. I have tried replacing the LOG line with a various sleep durations and that doesn't seem to work, so it seems to be related to the logging itself.

So, after getting it to work, performance seems to be not that great in the Nexus Player (Power VR 6 GPU). One thing I have noticed so far is that whenever text appears on the screen when talking to NPC in super mario 64, the frame rate drops to less than 10 FPS (estimate). Text appears above an alpha blended box, maybe that operation is slow for some reason in the PowerVR GPU?

[fzurita]

Another thing. On my nvidia shield portable. HW lighting does not seem to be working correctly, see this screenshot:

https://drive.google.com/file/d/0B57Ioy26LWegQ1lrOTNkS250OVE/edit?usp=docslist_api

Also FBE also seems to have issues, see these screenshots:

https://drive.google.com/file/d/0B57Ioy26LWegckdRVEgxX2pGVEk/edit?usp=docslist_api
https://drive.google.com/file/d/0B57Ioy26LWega0w1N1JhTm5fMmc/edit?usp=docslist_api

[Gillou68310]

Which gles version are you using on your shield?

Zelda subscreen FB issue will be fixed as soon as this pull request will be merged:
https://github.com/mupen64plus/mupen64plus-core/pull/125

I think the second issue is caused by copyfromrdram option, try disabling it.

Also thanks for opening an issue for the x86 problem

[Metalmusic3000]

I have a missing texture issue on goldeneye gles 2 the soldures guns are missing textures everything else works fine

[fzurita]

Which gles version are you using on your shield?

Zelda subscreen FB issue will be fixed as soon as this pull request will be merged:
https://github.com/mupen64plus/mupen64plus-core/pull/125

I think the second issue is caused by copyfromrdram option, try disabling it.

Also thanks for opening an issue for the x86 problem

The shield uses GL ES 2.0. By second issue, do you mean third screenshot? Also, no problem in opening up the issue on the x86 problems.

[Gillou68310]

By second issue, do you mean third screenshot?

Yes I do.

[Gillou68310]

Metalmusic enable frambuffer emulation. This fixed the issue for me.

[Metalmusic3000]

Enabled framebuffer emulation on shield portable no effect on soldures guns what settings besides fbe are you using gillou