[IBTECH]

Here you go.

Attached File(s)

•  libEGL.dll.zip (12.34K)
  Number of downloads: 1416

[Sponsored Links]

[Chainfire]

Thanks... unfortunately they seem to have the same issue. Guess it's time to nag Sammy.

[IBTECH]

what were the issues you were seeing?
I am not that technical when it comes to coding, but still am interested.

[Chainfire]

To describe the exact issues would be a very long post. Suffice to say it doesn't work properly. Theoretically making a patch that allows standard libGLES to work was a 5 minute job, but there is something weird going on with these drivers. OpenGL ES 1.x does not work at all (2.0 does, see the Cube app, which uses it), also not when used as it's "meant" to be used with these drivers. It either gives errors or a black screen (I have been able to run things like glBenchmark and such, but without sane output). Using M900 drivers I could get garbled output, but that's not much use either

[IBTECH]

Maybe the Samsung SDK can help?
I would really love to see OpenGL application that run on the touch HD run on our O2.

[Chainfire]

If only the Samsung SDK had that stuff GL is not included (nor is the compass... ...).

But yeah, getting existing OGLES apps to work with this was the general idea (goodbye HTC!). Theoretically you should be able to run most of the "old" GL apps on the Omnia II. It certainly has the capabilities for it, however OGLES 1.x (which is used in pretty much every OGLES app out there for WM) seems to be emulated in OGLES 2.0. Unfortunately that doesn't work right now (or I'm just an idiot... ) and 1.x and 2.0 are largely directly incompatible. So you can't just tell a 1.x app to use the 2.0 lib, that won't work (which is actually fairly uncommon for API's like these). Several fixed functions from 1.x need to be emulated using shaders in 2.0. If I was an expert on these things I'd just "do that s***" right there, but I'm not

[hdubli]

May be drivers from acerm900 help as they use they use the same CPU

Attached File(s)

•  LibGLES.rar (370.43K)
  Number of downloads: 1146

[Chainfire]

Already had and tried them - similar but different issues (on the i8000).

[Michael Pang]

so, is there any hope for running TouchFLO3D on i8000?

[Chainfire]

Some... if this 1.x GLES can be gotten to work that'd be a tiny step in the right direction. After that, TF3D would have to be completely repackaged, converting the QTC's to a format the PVR card can understand, and coding a new intermediate GLES layer to patch the texture loading mechanisms. Not to mention that the device checks need to patched, all dependancies (audiomanager, phonecanvas, etc etc) need to be satisfied, probably several of which need their own patches to work properly. Some HTC drivers and services may need to be faked, etc.

It'd be quite an effort, but it is certainly possible. Maybe somebody will be crazy enough to do it - it probably won't be me, though I have created several tools in the past that may assist in the effort (shameless plug)

[GinKage]

Well, it is true that Samsung didn't give us any SDK to use with Omnia II.

But, Chainfire, you may look into these two files:
http://down2.meizu.c...HS_V0.9.2.6.rar
and
http://bbs.meizu.com/attachment.php?aid=26...mp;t=1252061067

These are Meizu M8's SDK (which is, of course, WinCE 6.0, but I think there's no harm in trying) and Cube 2.0 sample (and, I want to point out, this sample is written by Samsung itself). As you maybe know, M8 uses the same processor, so it ships with the same three GLES driver files! Headers, Libs, Sources - everything is there...

[Chainfire]

GinKage, on Sep 4 2009, 12:50, said:

Well, it is true that Samsung didn't give us any SDK to use with Omnia II.

But, Chainfire, you may look into these two files:
http://down2.meizu.c...HS_V0.9.2.6.rar
and
http://bbs.meizu.com/attachment.php?aid=26...mp;t=1252061067

These are Meizu M8's SDK (which is, of course, WinCE 6.0, but I think there's no harm in trying) and Cube 2.0 sample (and, I want to point out, this sample is written by Samsung itself). As you maybe know, M8 uses the same processor, so it ships with the same three GLES driver files! Headers, Libs, Sources - everything is there...

I haven't checked out the SDK in full yet (slow DL), however the cube sample is GLES2. That works fine, it's the GLES1 support that isn't working properly, and that's exactly what we need to have for compatibility with already existing GL apps for WM.

[GinKage]

Quote

the cube sample is GLES2

Not exactly. Look closer: it has sources for both 1.x (cuTe) and 2.0 (cuBe), and two sets of glutLib as well.

[Chainfire]

GinKage, on Sep 4 2009, 14:11, said:

Not exactly. Look closer: it has sources for both 1.x (cuTe) and 2.0 (cuBe), and two sets of glutLib as well.

Interesting, seems I missed that. I'll check it out further.

[Chainfire]

Can't get it to work for GLES2, can't seem to recompile it to properly use GLES1 (only) either. Did you manage to do this?

[GinKage]

In fact, I haven't tried it yet: my Omnia is only going to be delivered to me next week...
Though, I already tried to write a translation dll, just like you did: I tried to load libGLESv1_CM.dll (which only exports "gl*" functions) and libEGL.dll (which exports "egl*" functions), got procedure addresses, and exported all the functions mentioned in Qualcomm's libGLES_CM.dll (both gl* and egl* ones) by translating them to the corresponding Omnia's dll. And - yes, that also failed.
I'll try digging even deeper when my Omnia arrives, and will keep you informed of my findings.

[Chainfire]

GinKage, on Sep 4 2009, 15:35, said:

In fact, I haven't tried it yet: my Omnia is only going to be delivered to me next week...
Though, I already tried to write a translation dll, just like you did: I tried to load libGLESv1_CM.dll (which only exports "gl*" functions) and libEGL.dll (which exports "egl*" functions), got procedure addresses, and exported all the functions mentioned in Qualcomm's libGLES_CM.dll (both gl* and egl* ones) by translating them to the corresponding Omnia's dll. And - yes, that also failed.
I'll try digging even deeper when my Omnia arrives, and will keep you informed of my findings.

Creating a forwarder libgles_cm is not the issue at all. I made one long before I even started this thread.

The problem is the original DLL's themselves. Try compiling a simple v1 sample (like triangle), using the original OmniaII/Pro drivers - so without the forwarder, just libGLESv1_CM.dll and libEGL.dll. It simply does not work. eglMakeCurrent will fail if libGLESv1_CM.dll is loaded (bad alloc).

You can get around by loading libEGL, libGLESv1_CM and libGLESv2 in a certain order, but actual GL calls will still fail with AV's.

You can get around that by setting up the context by using one of the GLES2 exports in the v1 lib. This will get rid of the AV's, and actually start the compiling of the shaders used to fake v1 functions in v2 (libGLESv1_CM is a v1 emulation driver that translates to v2 call).

You can then actually use v1 functions, and an FPS counter will return FPS in the expected range for the video card to be doing actual work. However, the screen will remain blank, and debug output will return strings along the lines of that the state has not been flushed by the hardware.

Some mixing and matching with M900 drivers has once given me garbled output (like the internal buffers' line length differ between the seperate driver builds).

I've traced various of these problems with IDA, both live as well as doing a lot of reading of the code. It seems that some initialization routines in the v1 lib are creating havoc, but I am as of yet unsure. A friend of mine who was also a part of bringing hardware 3D accel to the HTC Kaiser, Polaris and Nike is also looking at it a bit, but I'm not sure how far he's looked and attempted things ATM.

[GinKage]

Well, as I said, I'll try some more investigating once my device arrives.

By the way, I was wrong about Cube after all, it is really a GLES2 sample, and it requires shaders as a must.

I tried to compile this sample, and it seems that it uses its own libGLESv2.dll, with both gl* and egl* functions exported (and without libEGL dependency!). The corresponding .lib is also there. So, if we want to compile something with .dll's that we have in Omnia, we should remove includes and libs found in that sample and replace them with the ones from M8 SDK (in such a configuration, it compiles quite well). Or so I think. Again, othing to test on.

And, about weird dll initialization, I have a suspicion that maybe it could be resolved with correct .lib's... Or, then again, not.

Anyway, sooner or later I think we'll get our SDK.

[mattb777]

just got my omnia ii yesterday if you need anything tested on an actual device..

[Omikr0n]

Oh, not Kaiser 3D again. Couldn't PDA makers just sort graphics problems once and for all?
I was looking forward to OmniaPRO B7610, but if it has the same problems as described here, I won't pay a penny for it!

[Sponsored Links]