Pandora Qemu Based Pandora Usermode-"emulator" Poc

[JayFoxRox]

This is a POC (Proof of concept) only, don't expect anything too cool for now. A download will be made available once I cleaned up the source

Hey, I just wanted to tell you about one of my current side projects, called pandora-emulate.
Basicly, its a wrapper around qemu including:

- A launcher (called "pandora-emulate")
- A host library (called "preload_host.so")
- A guest library (called "preload_guest.so")
- and tons of libraries for any API that is supposed to be forwarded to the host ("host_libX11.so" / "libX11.so", ...)

It works by creating a local pipe in the launcher, then forwarding the pipe descriptors to the guest which then forwards any call to the host system. Additionally realtime dynamic linking was improved (but not fully working yet) by hooking all calls to dlopen and replacing the mode with RTLD_GLOBAL (as its the only one which works in qemu).


I tried to make forwarding as easy as possible and its done using macros. Following is the forwarder for GLES2 for example:

Spoiler

#include <GLES2/gl2.h>
#include "../breakout.h"

BREAKOUT_HOST_SUB(1,glActiveTexture,GLenum)
BREAKOUT_HOST_SUB(2,glAttachShader,GLuint,GLuint)
BREAKOUT_HOST_SUB(3,glBindAttribLocation,GLuint,GLuint,const char*)
BREAKOUT_HOST_SUB(2,glBindBuffer,GLenum,GLuint)
BREAKOUT_HOST_SUB(2,glBindFramebuffer,GLenum,GLuint)
BREAKOUT_HOST_SUB(2,glBindRenderbuffer,GLenum,GLuint)
BREAKOUT_HOST_SUB(2,glBindTexture,GLenum,GLuint)
BREAKOUT_HOST_SUB(4,glBlendColor,GLclampf,GLclampf,GLclampf,GLclampf)
BREAKOUT_HOST_SUB(1,glBlendEquation,GLenum )
BREAKOUT_HOST_SUB(2,glBlendEquationSeparate,GLenum,GLenum)
BREAKOUT_HOST_SUB(2,glBlendFunc,GLenum,GLenum)
BREAKOUT_HOST_SUB(4,glBlendFuncSeparate,GLenum,GLenum,GLenum,GLenum)
BREAKOUT_HOST_SUB(4,glBufferData,GLenum,GLsizei,const void*,GLenum)
BREAKOUT_HOST_SUB(4,glBufferSubData,GLenum,GLint,GLsizei,const void*)
BREAKOUT_HOST_FUNCTION(1,GLenum,glCheckFramebufferStatus,GLenum)
BREAKOUT_HOST_SUB(1,glClear,GLbitfield)
BREAKOUT_HOST_SUB(4,glClearColor,GLclampf,GLclampf,GLclampf,GLclampf)
BREAKOUT_HOST_SUB(1,glClearDepthf,GLclampf)
BREAKOUT_HOST_SUB(1,glClearStencil,GLint)
BREAKOUT_HOST_SUB(4,glColorMask,GLboolean,GLboolean,GLboolean,GLboolean)
BREAKOUT_HOST_SUB(1,glCompileShader,GLuint)
BREAKOUT_HOST_SUB(8,glCompressedTexImage2D,GLenum,GLint,GLenum,GLsizei,GLsizei,GLint,GLsizei,const void*)
BREAKOUT_HOST_SUB(9,glCompressedTexSubImage2D,GLenum,GLint,GLint,GLint,GLsizei,GLsizei,GLenum,GLsizei,const void*)
BREAKOUT_HOST_SUB(8,glCopyTexImage2D,GLenum,GLint,GLenum,GLint,GLint,GLsizei,GLsizei,GLint)
BREAKOUT_HOST_SUB(8,glCopyTexSubImage2D,GLenum,GLint,GLint,GLint,GLint,GLint,GLsizei,GLsizei)
BREAKOUT_HOST_FUNCTION(0,GLuint,glCreateProgram)
BREAKOUT_HOST_FUNCTION(1,GLuint,glCreateShader,GLenum)
BREAKOUT_HOST_SUB(1,glCullFace,GLenum)
BREAKOUT_HOST_SUB(2,glDeleteBuffers,GLsizei,const GLuint*)
BREAKOUT_HOST_SUB(2,glDeleteFramebuffers,GLsizei,const GLuint*)
BREAKOUT_HOST_SUB(2,glDeleteTextures,GLsizei,const GLuint*)
BREAKOUT_HOST_SUB(1,glDeleteProgram,GLuint)
BREAKOUT_HOST_SUB(2,glDeleteRenderbuffers,GLsizei,const GLuint*)
BREAKOUT_HOST_SUB(1,glDeleteShader,GLuint)
BREAKOUT_HOST_SUB(2,glDetachShader,GLuint,GLuint)
BREAKOUT_HOST_SUB(1,glDepthFunc,GLenum)
BREAKOUT_HOST_SUB(1,glDepthMask,GLboolean)
BREAKOUT_HOST_SUB(2,glDepthRangef,GLclampf,GLclampf)
BREAKOUT_HOST_SUB(1,glDisable,GLenum)
BREAKOUT_HOST_SUB(1,glDisableVertexAttribArray,GLuint)
BREAKOUT_HOST_SUB(3,glDrawArrays,GLenum,GLint,GLsizei)
BREAKOUT_HOST_SUB(4,glDrawElements,GLenum,GLsizei,GLenum,const void*)
BREAKOUT_HOST_SUB(1,glEnable,GLenum)
BREAKOUT_HOST_SUB(1,glEnableVertexAttribArray,GLuint)
BREAKOUT_HOST_SUB(0,glFinish)
BREAKOUT_HOST_SUB(0,glFlush)
BREAKOUT_HOST_SUB(4,glFramebufferRenderbuffer,GLenum,GLenum,GLenum,GLuint)
BREAKOUT_HOST_SUB(5,glFramebufferTexture2D,GLenum,GLenum,GLenum,GLuint,GLint)
BREAKOUT_HOST_SUB(1,glFrontFace,GLenum)
BREAKOUT_HOST_SUB(2,glGenBuffers,GLsizei,GLuint*)
BREAKOUT_HOST_SUB(1,glGenerateMipmap,GLenum)
BREAKOUT_HOST_SUB(2,glGenFramebuffers,GLsizei,GLuint*)
BREAKOUT_HOST_SUB(2,glGenRenderbuffers,GLsizei,GLuint*)
BREAKOUT_HOST_SUB(2,glGenTextures,GLsizei,GLuint*)
BREAKOUT_HOST_SUB(7,glGetActiveAttrib,GLuint,GLuint,GLsizei,GLsizei*,GLint*,GLenum*,char*)
BREAKOUT_HOST_SUB(7,glGetActiveUniform,GLuint,GLuint,GLsizei,GLsizei*,GLint*,GLenum*,char*)
BREAKOUT_HOST_SUB(4,glGetAttachedShaders,GLuint,GLsizei,GLsizei*,GLuint*)
BREAKOUT_HOST_FUNCTION(2,int,glGetAttribLocation,GLuint,const char*)
BREAKOUT_HOST_SUB(2,glGetBooleanv,GLenum,GLboolean*)
BREAKOUT_HOST_SUB(3,glGetBufferParameteriv,GLenum,GLenum,GLint*)
BREAKOUT_HOST_FUNCTION(0,GLenum,glGetError)
BREAKOUT_HOST_SUB(2,glGetFloatv,GLenum,GLfloat*)
BREAKOUT_HOST_SUB(4,glGetFramebufferAttachmentParameteriv,GLenum,GLenum,GLenum,GLint*)
BREAKOUT_HOST_SUB(2,glGetIntegerv,GLenum,GLint*)
BREAKOUT_HOST_SUB(3,glGetProgramiv,GLuint,GLenum,GLint*)
BREAKOUT_HOST_SUB(4,glGetProgramInfoLog,GLuint,GLsizei,GLsizei*,char* )
BREAKOUT_HOST_SUB(3,glGetRenderbufferParameteriv,GLenum,GLenum,GLint*)
BREAKOUT_HOST_SUB(3,glGetShaderiv,GLuint,GLenum,GLint*)
BREAKOUT_HOST_SUB(4,glGetShaderInfoLog,GLuint,GLsizei,GLsizei*,char* )
BREAKOUT_HOST_SUB(4,glGetShaderPrecisionFormat,GLenum,GLenum,GLint*,GLint*)
BREAKOUT_HOST_SUB(4,glGetShaderSource,GLuint,GLsizei,GLsizei*,char* )
BREAKOUT_HOST_FUNCTION(1,const GLubyte*,glGetString,GLenum)
BREAKOUT_HOST_SUB(3,glGetTexParameterfv,GLenum,GLenum,GLfloat*)
BREAKOUT_HOST_SUB(3,glGetTexParameteriv,GLenum,GLenum,GLint*)
BREAKOUT_HOST_SUB(3,glGetUniformfv,GLuint,GLint,GLfloat*)
BREAKOUT_HOST_SUB(3,glGetUniformiv,GLuint,GLint,GLint*)
BREAKOUT_HOST_FUNCTION(2,int,glGetUniformLocation,GLuint,const char*)
BREAKOUT_HOST_SUB(3,glGetVertexAttribfv,GLuint,GLenum,GLfloat*)
BREAKOUT_HOST_SUB(3,glGetVertexAttribiv,GLuint,GLenum,GLint*)
BREAKOUT_HOST_SUB(3,glGetVertexAttribPointerv,GLuint,GLenum,void**)
BREAKOUT_HOST_SUB(2,glHint,GLenum,GLenum)
BREAKOUT_HOST_FUNCTION(1,GLboolean,glIsBuffer,GLuint)
BREAKOUT_HOST_FUNCTION(1,GLboolean,glIsEnabled,GLenum)
BREAKOUT_HOST_FUNCTION(1,GLboolean,glIsFramebuffer,GLuint)
BREAKOUT_HOST_FUNCTION(1,GLboolean,glIsProgram,GLuint)
BREAKOUT_HOST_FUNCTION(1,GLboolean,glIsRenderbuffer,GLuint)
BREAKOUT_HOST_FUNCTION(1,GLboolean,glIsShader,GLuint)
BREAKOUT_HOST_FUNCTION(1,GLboolean,glIsTexture,GLuint)
BREAKOUT_HOST_SUB(1,glLineWidth,GLfloat)
BREAKOUT_HOST_SUB(1,glLinkProgram,GLuint)
BREAKOUT_HOST_SUB(2,glPixelStorei,GLenum,GLint)
BREAKOUT_HOST_SUB(2,glPolygonOffset,GLfloat,GLfloat)
BREAKOUT_HOST_SUB(7,glReadPixels,GLint,GLint,GLsizei,GLsizei,GLenum,GLenum,void*)
BREAKOUT_HOST_SUB(0,glReleaseShaderCompiler)
BREAKOUT_HOST_SUB(4,glRenderbufferStorage,GLenum,GLenum,GLsizei,GLsizei)
BREAKOUT_HOST_SUB(2,glSampleCoverage,GLclampf,GLboolean)
BREAKOUT_HOST_SUB(4,glScissor,GLint,GLint,GLsizei,GLsizei)
BREAKOUT_HOST_SUB(5,glShaderBinary,GLint,const GLuint*,GLenum,const void*,GLint)
BREAKOUT_HOST_SUB(4,glShaderSource,GLuint,GLsizei,const char**,const GLint*)
BREAKOUT_HOST_SUB(3,glStencilFunc,GLenum,GLint,GLuint)
BREAKOUT_HOST_SUB(4,glStencilFuncSeparate,GLenum,GLenum,GLint,GLuint)
BREAKOUT_HOST_SUB(1,glStencilMask,GLuint)
BREAKOUT_HOST_SUB(2,glStencilMaskSeparate,GLenum,GLuint)
BREAKOUT_HOST_SUB(3,glStencilOp,GLenum,GLenum,GLenum)
BREAKOUT_HOST_SUB(4,glStencilOpSeparate,GLenum,GLenum,GLenum,GLenum)
BREAKOUT_HOST_SUB(9,glTexImage2D,GLenum,GLint,GLenum,GLsizei,GLsizei,GLint,GLenum,GLenum,const void*)
BREAKOUT_HOST_SUB(3,glTexParameterf,GLenum,GLenum,GLfloat)
BREAKOUT_HOST_SUB(3,glTexParameterfv,GLenum,GLenum,const GLfloat*)
BREAKOUT_HOST_SUB(3,glTexParameteri,GLenum,GLenum,GLint)
BREAKOUT_HOST_SUB(3,glTexParameteriv,GLenum,GLenum,const GLint*)
BREAKOUT_HOST_SUB(9,glTexSubImage2D,GLenum,GLint,GLint,GLint,GLsizei,GLsizei,GLenum,GLenum,const void*)
BREAKOUT_HOST_SUB(2,glUniform1f,GLint,GLfloat)
BREAKOUT_HOST_SUB(3,glUniform1fv,GLint,GLsizei,const GLfloat*)
BREAKOUT_HOST_SUB(2,glUniform1i,GLint,GLint)
BREAKOUT_HOST_SUB(3,glUniform1iv,GLint,GLsizei,const GLint*)
BREAKOUT_HOST_SUB(3,glUniform2f,GLint,GLfloat,GLfloat)
BREAKOUT_HOST_SUB(3,glUniform2fv,GLint,GLsizei,const GLfloat*)
BREAKOUT_HOST_SUB(3,glUniform2i,GLint,GLint,GLint)
BREAKOUT_HOST_SUB(3,glUniform2iv,GLint,GLsizei,const GLint*)
BREAKOUT_HOST_SUB(4,glUniform3f,GLint,GLfloat,GLfloat,GLfloat)
BREAKOUT_HOST_SUB(3,glUniform3fv,GLint,GLsizei,const GLfloat*)
BREAKOUT_HOST_SUB(4,glUniform3i,GLint,GLint,GLint,GLint)
BREAKOUT_HOST_SUB(3,glUniform3iv,GLint,GLsizei,const GLint*)
BREAKOUT_HOST_SUB(5,glUniform4f,GLint,GLfloat,GLfloat,GLfloat,GLfloat)
BREAKOUT_HOST_SUB(3,glUniform4fv,GLint,GLsizei,const GLfloat*)
BREAKOUT_HOST_SUB(5,glUniform4i,GLint,GLint,GLint,GLint,GLint)
BREAKOUT_HOST_SUB(3,glUniform4iv,GLint,GLsizei,const GLint*)
BREAKOUT_HOST_SUB(4,glUniformMatrix2fv,GLint,GLsizei,GLboolean,const GLfloat*)
BREAKOUT_HOST_SUB(4,glUniformMatrix3fv,GLint,GLsizei,GLboolean,const GLfloat*)
BREAKOUT_HOST_SUB(4,glUniformMatrix4fv,GLint,GLsizei,GLboolean,const GLfloat*)
BREAKOUT_HOST_SUB(1,glUseProgram,GLuint)
BREAKOUT_HOST_SUB(1,glValidateProgram,GLuint)
BREAKOUT_HOST_SUB(2,glVertexAttrib1f,GLuint,GLfloat)
BREAKOUT_HOST_SUB(2,glVertexAttrib1fv,GLuint,const GLfloat*)
BREAKOUT_HOST_SUB(3,glVertexAttrib2f,GLuint,GLfloat,GLfloat)
BREAKOUT_HOST_SUB(2,glVertexAttrib2fv,GLuint,const GLfloat*)
BREAKOUT_HOST_SUB(4,glVertexAttrib3f,GLuint,GLfloat,GLfloat,GLfloat)
BREAKOUT_HOST_SUB(2,glVertexAttrib3fv,GLuint,const GLfloat*)
BREAKOUT_HOST_SUB(5,glVertexAttrib4f,GLuint,GLfloat,GLfloat,GLfloat,GLfloat)
BREAKOUT_HOST_SUB(2,glVertexAttrib4fv,GLuint,const GLfloat*)
BREAKOUT_HOST_SUB(6,glVertexAttribPointer,GLuint,GLint,GLenum,GLboolean,GLsizei,const void*)
BREAKOUT_HOST_SUB(4,glViewport,GLint,GLint,GLsizei,GLsizei)

Features include:
- Doesn't touch qemu source-code at all (only library preloading is done)
- GLES2 should be fully supported, some bugs fixed
- Can work with applications depending X
- Can work with applications which are not using X, by creating an extra output when EGL doesn't specify an X window
- Its quite fast for a first version. It runs all GLES samples with at least 30FPS on my machine (ok... its an i7, GTX265 )
- Most smaller things I tried, including my PSP Emulator (the version I send to Pickle in October which ran on a real Pandora before!), work fine
- Input is working by re-creating the original Pandora kernel interface (button mapping is outdated tho, that stuff is changing way too often)


Known problems (Highest priority first):
- Unstable, I still can't get mupen64 gles2n64 to work. Outputs garbage right now
- Probably not working with threads
- Callbacks and variable number of arguments don't work yet (This could be a huge problem for SDL)
- dlmopen is used to fix dlopen (as dlopen is commonly used), which means dlmopen itself doesn't work anymore
- exec() will start on the host system (just like in qemu), making it impossible to use launchers
- Depends heavily on your system and linux installation
- Only 32 bit version was tested and developed because it depends on the PVR GLES wrapper (tho, adding 64 bit support without GLES should be easy)
- Still too slow to be really useful
- No audio libraries yet
- Missing support for lots of other libraries including GTK etc.
- No Win32 support yet (Planned using cygwin, but I haven't used Windows/cygwin in ages)
- Depends on qemu-arm which might have bugs, or not enough compatibility to port it to Win32



And last but not least some screens I took while testing (People on IRC saw them before, don't expect anything new )

Spoiler

(I think its worth to note that the Pandora-PSP output above is wrong and it worked fine on PC when I send Pickle the test version (who reported the problem so I could fix it) - I could have fixed the bug before already if I would have had this emulator)



Using the "emulator" is really simple:

pandora-emulate ./application.elf *parameters*

(I'd like to thank rapidpoobear for making a small script to make it easier to wrap EGL and GLES2 (even tho I only used it for EGL))

 

[PhillipJ]

That is pretty cool. I wonder if it's worth you supporting Window/gygwin though. In my (fairly limited) experience using a linux VM is a lot more user friendly than using cygwin.

 

[ari64]

Known problems (Highest priority first):
- Unstable, I still can't get mupen64 to work. It initializes the plugins fine but then segfaults, needs further work
- Probably not working with threads

Mupen64plus launches the emulator in a separate thread from the GUI. So if threads don't work, then this won't.

You can of course run it on x86. I'm guessing you want to look at the ARM recompiler though.

 

[JayFoxRox]

The bug was in the configs because it was doing something with getenv("HOME"), however, my launcher cleared all env. variables first so it didn't work.

This is what I get now, its a 'start'. I get lots of graphical bugs tho and its only 2 FPS. However, I'm sure there is lots of room for optimizations and improvements.

 

[ari64]

The bug was in the configs because it was doing something with getenv("HOME"), however, my launcher cleared all env. variables first so it didn't work.

Yes, it stores config files and saves in $HOME/.mupen64plus

So I guess threads are working?

 

[kingoddball]

FOX! YOU RO(c)K!

Will this work under any Qemu? (MAC/OSX)
This is some excellent news! I have been waiting for a long time for an Pandora emulator!
Once you can release it, I'll start working on porting Arduino IDE (I have nothing to test it on to see if it will work at all).

 

[torpor]

Very nice work! If I have to use it, though, I'll be pissed: nothing beats running tests on real hardware!

 

[JayFoxRox]

The bug was in the configs because it was doing something with getenv("HOME"), however, my launcher cleared all env. variables first so it didn't work.

Yes, it stores config files and saves in $HOME/.mupen64plusSo I guess threads are working?

No, there doesn't seem to be any thread at work. I'm running the nongui version which starts everything in the mainthread.

The line in question which crashed it was (main.c:1291 in my source [which is VERY old, so don't kill me if this was already changed ]):

strncpy(l_ConfigDir, getenv("HOME"), PATH_MAX);

because getenv("HOME") returned NULL as $HOME was not available on the host system.
Personally I think that there should be a check like this:

char* homedir = getenv("HOME");
if (homedir) {
  strncpy(l_ConfigDir, homedir, PATH_MAX);
} else {
  getcwd(l_ConfigDir,PATH_MAX); //Possibly also just "./" would be working ;) . getcwd can still return NULL
  printf("Your home directory was not set, changed base directory to '%s'\n",l_ConfigDir);
}

Personally I think that this would be a lot cleaner and safer for porting to other systems. While it should be safe to assume that $HOME is providedn (on unix / linux?) its probably also possible that its removed by some sort of wrapper (let it be some anti-virus / safed environment launcher for example)
I think the graphics problems are caused either by bugs in Qemu (unlikely) or in the PVR GLES Wrapper (more likely). I'll try to get gles2n64 to work with the PVR GLES Wrapper now but I checked the source and it looks like it uses integer drawing, I also had problems with Pandora-PSP with that before. If that is the root of the problem I'll fix it by patching the GLES2 wrapper or by rewriting it - something very high on my todo list anyway

FOX! YOU RO(c)KXor!Will this work under any Qemu? (MAC/OSX)This is some excellent news! I have been waiting for a long time for an Pandora emulator!Once you can release it, I'll start working on porting Arduino IDE (I have nothing to test it on to see if it will work at all).

I'm not sure, but I doubt it. But there is a good chance that it can be ported to mac or that there is some unix library like cygwin. However, if that doesn't work you could still stick to a full linux vm with GL support and it should work fine there in theory (Possibly using some sort of savestate to avoid booting the virtual system). I don't have any mac to test but I'll try to get access to one soon if mac support is necessary.

 

[conso]

very much looking forward to this.
Any idea what kind of machine will be necessary to emulate the pandora around fullspeed?

 

[PhonicUK]

very much looking forward to this.
Any idea what kind of machine will be necessary to emulate the pandora around fullspeed?

As a general rule, you need a computer 6-8x the power to emulate a completely alien system at full speed. (Similar systems can get as low as 4x)

Since the Panda is ARM, you would need a massively powerful x86 CPU to emulate it at full speed. And it would likely not benefit from multiple cores.

This is slightly different because a large amount of the work is being done natively as only system calls are being translated. But there is still a high overhead. I reckon 6x will be the figure here.

 

[ari64]

The line in question which crashed it was (main.c:1291 in my source [which is VERY old, so don't kill me if this was already changed ])

My ARM port was based on mupen64plus 1.5 and a lot of the code in main has changed in 2.0. At some point I will want to sync with svn, however they changed the plugin interface somewhat and I have not investigated what might need to be done to make gles2n64 work.

 

[ldesnogu]

That looks extremely interesting! And similar to how I intended on running Wine

JayFoxRox, is there any way to see your code? Some simple example might be enough.

 

[Exophase]

I reckon 6x will be the figure here.

I reckon not, given that Mupen64plus is running at < 15% what it runs on Pandora on a machine that's probably at least 8x more powerful. So unless the bugs in Mupen64 are also causing it to be slower I'd say we're looking at something more like 50x.

 

[Caine]

I like how the Pandora is one of the few (only?) devices where we have an "emulator" before we have the actual platform

Looking forward to this. Thanks for the effort.

 

[JayFoxRox]

very much looking forward to this.Any idea what kind of machine will be necessary to emulate the pandora around fullspeed?

No idea yet. It really depends on how well qemu performs and how much I can abstract and which communication performance I can get between host and guest system.
I'm already looking into tricks to create memory watches which could speed it up a good bit.

very much looking forward to this.Any idea what kind of machine will be necessary to emulate the pandora around fullspeed?

As a general rule, you need a computer 6-8x the power to emulate a completely alien system at full speed. (Similar systems can get as low as 4x)Since the Panda is ARM, you would need a massively powerful x86 CPU to emulate it at full speed. And it would likely not benefit from multiple cores.This is slightly different because a large amount of the work is being done natively as only system calls are being translated. But there is still a high overhead. I reckon 6x will be the figure here.

Where do you people always dig up stuff like this? I'm on an i7, 6GB of RAM etc. Yet mupen, with corrupted graphics only runs at 2FPS while the original hits the 75Hz sync limit.
And what exactly are those 6x? 6x 600MHz? So do you mean its a 6 core 600 MHz system? A 3.6 GHz machine? ARM, PPC? SH-4? x86 (what sort of x86? P1, P2, ...?)?

That looks extremely interesting! And similar to how I intended on running Wine JayFoxRox, is there any way to see your code? Some simple example might be enough.

Just PM me some way to contact you directly (I got MSN, ICQ (Check profile), IRC (freenode #openpandora, need to be registered to post, but /msg me there and I'll respond)) so I can pastebin some parts for you. I just don't like the idea of sharing dirty code with the public (just like delays by PMs etc, so please - IM in some form ).


I also sent a PM to Adventus about the gles2n64 problems because I can't even get it to work when compiling for x86
However, I was already able to fix some problems with PVRFrame and my nvidia drivers I'll probably forward that to IMGTec directly as I found about 10 issues with PVRFrame and I know how to fix them all (done by wrapping my own GLES2 profiler around the GLES functions at the moment)

//Edit: Messed around in the gles2n64 source and had to remove some optimizations. But now it works in qemu and it seems to be stable. Not 100% correct, but stable:

I'm not too sure why the graphics are not correct (looks like the normals are off) and I'm not sure which optimization screws up qemu. As soon as I know I'll report it as bug and try to fix it myself (unless its some sort of rocket science - I'd leave that to others ).

 

[Dead1nside]

Looking good. Very interesting.

 

[stillnumber1]

Just wondered if there had been any updates on this?