Pandora Emulator Vs Real Pandora

[Zotty]

I've been playing around with EGL a bit and was wondering if there are any significant differences between Imagination's PVRVFrame GLES emulator and a real Pandora. Due to the lack of real hardware (it'll come ) I was hoping PVRVFrame would be a good alternative. The idea is that if it runs fine with the emulator, it will run fine on the hardware. Any experiences?

One of the things I ran into was that there's only 1 32-bit EGL config which happens to be a pbuffer surface. Didn't expect this since my desktop is set to 32-bit so a 32-bit window surface would be nice. How's this taken of on the Pandora?

 

[JayFoxRox]

//Edit: Anything about GLES2

[...]
conflist[i++] = EGL_SURFACE_TYPE;
conflist[i++] = EGL_WINDOW_BIT; 
[...]

Didn't doublecheck this if it really doesn't use a pbuffer, but the config works fine for me.
//Edit: Only checked 16 bit - but is 32 bit really that important on a mobile device? The last drivers I had on my beagleboard only accepted 16 bit anyway.
Some problems I ran into with PVRFrame (On latest nvidia drivers):


- Integer drawing rarely works for, sometimes it does, sometimes not. I noticed this when emulating lots of PSP homebrew which does that, it worked fine on beagleboard tho.

- Its anything but strict, where the original driver might fail, the emulator won't tell you about problems, this is especially true for:
-- Shaders get compiled but don't work like expected
-- Linking shaders, always do it after changing an attribute, this also works the other way around in GL (not sure about the spec, but drivers handle it well on ATI and nvidia for me), however, with PVRFrame it doesn't (leads to unpredictable results)

- It's not as pixel perfect as the real driver. Sometimes when mapping a 512x512 texture to a 512x512 region on the display (only some parts visibile) I get blurry lines on my Desktop which worked fine on the BeagleBoard, integer drawing helped here, but this only works for a few seconds for me as said already.

- Make sure you use the right constants, glEnable(GL_TEXTURE_2D) is not necessary anymore, PVRFrame should also report that, however sometimes I have constants like GL_BGRA defined elsewhere, PVRFrame usually accepts them (as it justs forwards to your GL driver), renders fine, but it doesn't work on real hardware.

- Some other applications might be hooking your GL, since the GLES symbols are most often the same they will get the wrong functions and sometimes crash your applications or lead to strange error reports in PVRFrame.

 

[Zotty]

Thank you for the info, will keep it in mind. Not too bad since integers shouldn't be a problem (use floats) and shaders is something I'm saving for later. Which also means I can ignore the glEnable(GL_TEXTURE_2D) thing for the time being. This whole GLES thing has a steep enough learning curve as it is already

Btw, the only reason I'm using 32-bit is that the game I'm porting used 32-bit gfx. Was hoping to save some time and get things up and running first before I start rewriting gfx conversion routines. Even 8-bit should be enough, but it's something I have to tackle sooner or later, independent of emulation.

 

[JayFoxRox]

Rendering to 16 bit doesn't mean that your textures can't be 32 bit. If you stick to GLES and don't blit anything using your own routines you can safely ignore the 16 / 32 bit difference. The only drawback with 16 bit would be that everything looks a bit.. less fluent or sometimes like its sprayed.
However, I doubt the display will show the difference that clearly (at least not under normal conditions).

//Edit: How exactly are you ~"saving shaders for later"? GLES1 doesn't support shaders and differs a good bit from GLES2 which requires you to use shaders as it doesn't have a fixed function pipeline.
I added the note to my other post that its about GLES2. I assumed you would use that.

 

[Zotty]

GLES2 is something I plan on using eventually, but for now I'm sticking to GLES1. It allows me to focus on getting everything up and running without diving into programmable shaders. Since I haven't got any opengl experience yet this means lots of research and prototyping, so rewriting existing code to do GLES2 didn't seem like a good place to start. Would it be a new project it might though.

Btw, the wiki could really use an update concerning GLES development <_<