Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLideN64 not starting on android x86 #604

Closed
fzurita opened this issue Jul 5, 2015 · 13 comments

Comments

@fzurita
Copy link
Contributor

commented Jul 5, 2015

GLideN64 does not seem to be starting up in android x86. I have tried debugging the issue and it's baffling me. Here is the log output when the plugin fails to start, it does not seem to be crashing:

07-05 00:11:04.029: I/GameSurface(11018): Creating GL context
07-05 00:11:04.029: V/GameSurface(11018): Found EGL display connection
07-05 00:11:04.029: V/GameSurface(11018): Initialized EGL display connection
07-05 00:11:04.030: V/GameSurface(11018): Found compatible EGL frame buffer configuration
07-05 00:11:04.036: V/GameSurface(11018): Created EGL rendering context
07-05 00:11:04.038: V/GameSurface(11018): Created EGL window surface
07-05 00:11:04.047: V/GameSurface(11018): Bound EGL rendering context to EGL window surface
07-05 00:11:04.047: I/GameSurface(11018): Created GL context OpenGL ES 3.1 build 1.4@3300288
07-05 00:11:04.047: D/GLideN64(11018): [gles2GlideN64]: Create setting videomode 1440x1080
07-05 00:11:04.047: D/GLideN64(11018): OpenGL version string: OpenGL ES 3.1 build 1.4@3300288
07-05 00:11:04.047: D/GLideN64(11018): OpenGL vendor: Imagination Technologies
07-05 00:11:04.047: D/GLideN64(11018): OpenGL renderer: PowerVR Rogue G6430
07-05 00:11:04.047: D/GLideN64(11018): OpenGL major version: 3
07-05 00:11:04.047: D/GLideN64(11018): OpenGL minor version: 1
07-05 00:11:04.047: D/GLideN64(11018): ImageTexture support: yes
07-05 00:11:04.047: D/GLideN64(11018): Max Anisotropy: 0.000000
07-05 00:11:05.078: I/GameSurface(11018): Destroying GL context
07-05 00:11:05.078: V/GameSurface(11018): Unbound EGL rendering context from EGL window surface
07-05 00:11:05.083: V/GameSurface(11018): Destroyed EGL window surface
07-05 00:11:05.086: V/GameSurface(11018): Destroyed EGL rendering context
07-05 00:11:05.086: V/GameSurface(11018): Terminated EGL display connection
07-05 00:11:05.091: D/Core(11018): Rom closed.

I have been trying to debug this issue and some strange things are happening.

Adding any log entry to void OGLRender::_initData() in OpenGL.cpp after the for loop seems to fix the issue. For example, I have this:

for (u32 i = 0; i < VERTBUFF_SIZE; ++i)
    triangles.vertices[i].w = 1.0f;
LOG(LOG_VERBOSE, "TEST\n");

And it seems to run normally after adding that.

Thinking that it was some sort of timing issue, I tried replacing the LOG entry with a usleep ranging from 1us to 1 sec and it did not allow the GLideN64 to work correctly. I have no idea why adding this log entry works. By the way, I have also set the log level to verbose by modifying Log.h to have this line:

define LOG_LEVEL LOG_VERBOSE

@fzurita

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2015

Also, another thing. I can place that LOG line almost anywhere in the initialization process and they all seem to work as well. It doesn't have to be in that specific location.

@gonetz

This comment has been minimized.

Copy link
Owner

commented Jul 5, 2015

Interesting. Probably __android_log_print call forces some system initialization, which is necessary for plugin's work. If it really helps, I may add some log message to OGLRender::_initData().

@gonetz

This comment has been minimized.

Copy link
Owner

commented Jul 5, 2015

Please check, does this code fix the problem:

 triangles.num = 0;
#ifdef ANDROID
    __android_log_write(ANDROID_LOG_DEBUG, "GLideN64", "Finish render initialization.\n");
#endif 
@fzurita

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2015

I'll try that some time today. Another thing, there is already some logging before where I added my own logging related to the android version. Not sure why more logging after that fixes it.

@fzurita

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2015

I set the logging level back to error and made the change you suggested after triangles.num = 0; and it's working ok right now in x86. This feels like a workaround, I'm sure it's going to come back to bite us some day.

@gonetz

This comment has been minimized.

Copy link
Owner

commented Jul 6, 2015

Yes, it is a crutch. What is bad, we even don't know why and how it works.

@fzurita

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2015

This maybe nothing, but it seems like the "RomOpen" implementation in the plugin should be returning a non zero integer for the call to be successful, but it seems like your implementation is returning void?

In the core I can see that for everything to startup correctly, it expects a non-zero value for the RomOpen method. But I'm not seeing a RomOpen method with a return type of integer, only one with a void return.

@fzurita

This comment has been minimized.

Copy link
Contributor Author

commented Jul 15, 2015

Ok, that did the trick. I got rid of the logging and modified the following and it works in android x86.

In ZilmarGFX_1_3.h changed:

EXPORT void CALL RomOpen (void);

to

EXPORT int CALL RomOpen (void);

In CommonPluginAPI.cpp changed:

EXPORT void CALL RomOpen (void)
{
    api().RomOpen();
}

to

EXPORT int CALL RomOpen (void)
{
    api().RomOpen();

    return 1;
}

This worked.

@gonetz

This comment has been minimized.

Copy link
Owner

commented Jul 23, 2015

You're right: RomOpen for Mupen64Plus returns int, while RomOpen for Zilmar specs returns void. I did not notice that and use Zilmar version for both specifications.

gonetz added a commit that referenced this issue Jul 23, 2015
RomOpen for Mupen64Plus API returns int, while Zilmar specs RomOpen returns void.

Thanks fzurita for pointing on this mistake.

Fixed issue #604
@gonetz

This comment has been minimized.

Copy link
Owner

commented Jul 23, 2015

@SuperL2

This comment has been minimized.

Copy link

commented Sep 11, 2015

I need help. I'm having the same problem as fzurita. I don't know how to alter the code like he did.

@fzurita

This comment has been minimized.

Copy link
Contributor Author

commented Sep 11, 2015

The latest Mupen64plus AE should have the fix included. Here is the link:

http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/

@SuperL2

This comment has been minimized.

Copy link

commented Sep 12, 2015

Thanks.

IT's running now. It's just incredibly slow and laggy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.