I am finding this library to be unstable for anything larger than a tech demo. I recently made postings about 0xbaadf00d errors and invalid GL_INVALID_VALUE errors. These are coming up a lot once I started to do more advanced things inside of a game engine.
I am using the library for porting a non-trivial D3D9-based game to iOS/Android by initially porting it to use the OpenGL ES 2.0 library on Windows XP. At first, the library was pretty awesome, getting the code to be API-compliant, but with all these errors, my next step is to just try to get my current code working with vanilla OpenGL before moving to iOS/Android.
Is this library known to be unstable with more real-world application usage? Some of the bugs that I’ve come across have been reported by people back on these forums in 2009/2010 with responses that they’ve been fixed in an upcoming release. The odd part is that I have the latest release, which is dated newer than those postings, and I still see those bugs.
I’m not trying to be negative, since I really love the fact that we can develop ES-compliant code under Windows and hopefully have that code “just work” on the actual ES devices, but I would like to get a handle on how usable this library is, especially given that I’ve dug myself pretty far down this path in porting this game.
Anyone from Imagination Technologies know what’s going on with these “fixed” bugs as well as the ones I (and others) recently posted about?
Thanks in advance for any advice/comments/sympathy 
The emulation environment has been verified to work successfully with several non-trivial projects (benchmarks, games etc.) over the past few years. We do find that specific cases do seem to throw up a lot of issues that haven’t been encountered before or that are difficult to reproduce. Sometimes this is because of conditions that only seem to be produced by these projects, sometimes it’s the hardware/drivers on the developer’s machine that are at fault - sometimes it is bugs in the library.
Specific issues we handle through our bugtracking system and if these don’t seem to be getting cleared up, please enquire about them - sometimes stuff does fall through the cracks, sometimes issues get fixed, but there may not have been a followup on this forum (both things we’d like not to happen).
Descriptions of what you’re doing when you hit difficulty might help us to advise on how to proceed or on known issues with the emulation (or devices for that matter). As I’ve said in one of the other threads, examples that we can use to reproduce problems might enable us to zap bugs quickly and we are open to shipping “engineering releases” with fixes in if this helps your projects and our emulation get better. If you’d like to do this under an NDA then that’s fine as well - please contact us through devtech@imgtec.com and we can sort this out.
Sometimes the underlying GL environment causes problems for our emulation so making a desktop GL version might actually be a good approach (esp if you can get some value out of it on a real platform). Obviously, it would be better if you didn’t have to do that though - I think there may be more options to explore before that is necessary.
Gordon2011-08-17 18:36:58
That’s a great response. Thanks for taking the time to write it.
I can’t narrow down smaller cases due to time (I’m in crunch mode) and the fact that the errors didn’t pop up in smaller examples (or when I had only more trivial areas of the engine wired up to the OGLES2 calls). Once I got most of the engine ported, errors started popping up all the time.
I would be happy to grab any releases you have that could help in tracking down these problems and/or have fixes that aren’t released yet. If that’s possible, sure, send an NDA my way. (I don’t want to post my email address publicly [sigh… spam bots], and I don’t see a way to PM you, so if you don’t have access to my account details with my email address, go to my company’s webpage below in the .sig and “Contact”.)
I’ve sent you an email.
