General info:

Samsung S3C6410 processor supports OpenGL ES 1.1 and 2.0, but for some reason Samsung didn't include any proper OpenGL ES 1.0 implementation on our devices.
This is the project of creating a libgles_cm.dll library which compensates this.
So, here is the release of the OpenGL ES 3D v1 (and HTC) compatibility layer for Samsung Omnia II, Pro (Qwerty) and Giorgio Armani 2 (and M900 and...):


Installation:

ZIP download (current version):
(original GinKage material) Download it by clicking on this link.
The zip contains libgles_cm.dll, put this in your \Windows folder for activation across the entire device, or in the same folder as the EXE of the program you want to try this with.

CAB download (version 0.26):
(some additions by Chainfire) Attached!
This CAB will place the libgles_cm.dll file in your \Windows folder (unsigned). This means it will be used by all (capable) programs. I have also included libgles_cl.dll (an adaption from NuShrike's CL), which may add some compatibility for some games, but is untested in combination with GinKage's CM library.

Note:

Don't forget to switch your device to HIGH performance mode or plug a charge adapter otherwise you won't get any decent performance.

Compatibility:

What works:

• Xtrakt
• Experiment 13
• HTC TouchFlo3D v1.3, v2.0, HTC Sense v2.5
• Tower Defense
• Flight Commander
• 10 Games for Betting
• S2P 0.80
• Opera Mobile 9.7
• glBenchmark 1.0/1.1
• TestOpenGL
• HG Engine (Hologram App) and HG Proton [reported by daskalos]

Known issues:

• glBenchmark hangs after 10-13 tests, don't know why. So, if you want to benchmark, do it in 3-4 runs, few tests at a time. Also, 'Flat' shading mode doesn't work, everything renders as 'Smooth'.
• Xtrakt has some minor texturing issues (as you may see on fonts) due to the unsupported 1024x1024 texture resolution. Although it's perfectly playable.
• Some alpha-blensing issues with Spb Mobile Shell 3.5.2 and earlier, NFS: Undercover, 10 Games for Betting and Call of Duty 2.

What does NOT work:

• Spb Mobile Shell 3.5.2 and earlier. Although you may switch acceleration on by registry at [HKLM\Software\Spb Software House 2\Spb Mobile Shell\Gl\], setting GlEnabed to 1, but it is really unusable: you can't tap on a panel or a message to select it, you can only swipe to rotate carousel. I don't really care, because Spb already added GL2 support in the later releases.
• NFS: Undercover. Almost worked for some time, but used to hang or crash randomly, and now it won't start at all. Again, I don't really care, as there is NFS in Samsung's AppStore.
• Tons of GL apps.

Remember, I DON'T actually want to know about apps that DON'T work.
What I DO want to know about, is if anything else apart from
the list above work. That would really be a surprise!


Source code

The project is open-sourced. There are three main reasons for this:

1. I want the project to evolve, even when I don't have enough time for it.
2. I want to see more GL2 applications for Omnia 2 created by third-party developers (waiting for a Samsung's GL2 SDK is some pain).
3. I want Samsung to finally fix their own GL2 driver (and I hope that maybe this lib's sources will help).

So, I don't really think there's any other way to make these wishes possible.

Project source is available at SourceForge here: http://sourceforge.net/projects/omnia2gl/
To build the source code you'll need Visual Studio 2008, Windows Mobile 6 SDK and GL2_SDK.zip from the Files section of the SourceForge project.
At the moment, only me (GinKage) and Chainfire are the project admins, so if you have something to commit you'll need to contact us.

You may also find Screentex source there. Simple app it is, but it may be compiled in both GL1 and GL2 modes (some time earlier, it was also D3DM-compliant, not sure about it now).

I kindly ask you not to criticize the code too much, as I haven't even tried to make it look like industrial-standard.
It was created as a hobby, a brain siesta. If you want to prettify it, do it (and send us a patch, so it would find its way to SVN).

Also, if you use some parts of the code, please do mention us (GinKage, Chainfire, NuShrike) in credits. That's all I ask in return.


Bonus (for Samsung representatives if any):

A short list of some stupid bugs found in Samsung's driver during my work on this project:

• eglGetDisplay(0) fails. It should work with a zero argument, by standard, but it fails.
• Calling glGetString() before eglInitialize(), crashes.
• eglGetConfigs with config_size = 4096 crashes.
• glBindBuffer generates GL_OUT_OF_MEMORY if buffer number is above 100 (it is an actual limit hard-wired into libGLESv2, I had to re-implement the whole buffer management by myself). And, Xtrakt needs 102 buffers...
• glGetIntegerv(GL_MAX_TEXTURE_UNITS) returns 0 instead of 2. This one totally breaks NFS.
• glGetIntegerv(GL_MAX_TEXTURE_SIZE) returns 2048. In reality, every texture larger than 512x512 is going to be ignored at all, with some allocaton errors in debugger output. It may be used with S3TC, but it's DXT1 only, not even DXT5. And, somehow, with a GL_RGBA_S3TC_OES format, an alpha bit is ignored at all.
• And don't forget to create mipmaps, or GL_*_MIPMAP_* won't draw anything at all (it should just use the only level available)!
• glAlphaFuncEXP is not iplemented in libGLESv2 (though the hardware DOES have this available), had to do a hack for this to work.
• glViewport works wrong after all. If the parameters, e.g. X and Width have a larger sum than the width of the window surface, then the resulting width is clamped, which results in scaled down rendering.
• eglCreateWindowSurface is a fail: it doesn't track window size change at all, so if you create a surface and change window size, your output will be of an inadequate size (e.g., in Opera 9.7 going from Widowed mode to Fullscreen, or in anything else when going from Landscape to Portrait mode).
• eglSwapBuffers is slow as hell (probably because of plain BitBlt it uses), it takes about 10 ms, which limits fps to about 100 and reduces the speed of everything else (e.g., you'll get 16 fps where you could have 20, only because of this functon).
• All textures have an offset by half-texel. This is probably done for mapping to the nearest texel (like, round(u + 0.5)), but it breaks everything that is drawn, for example, with glOrtho (like Opera 9.7). Well, not exactly breaks, but akes everything look "smoothed out".

Release history:

Version 0.2, pre-alpha (Sep 24, 2009)

• Initial release (proof-of-concept)

Version 0.25 (Nov 2, 2009)

One of the nicest updates. Faster, smaller, better. That is:

• It does QTC texture decompression more quickly, so Xtrakt loads a tad faster, and lags in TF3D were reduced (though haven't gone completely).
• It has a smaller footprint, so Acer M900 users should be able to run Xtrakt now.
• It allows to run an original unmodified TouchFLO 3D 1.3 (fixes yet another Samsung's bug, this time in glViewport). Maybe it can do even more, but that was not tested. smile.gif
• CFC 0.60 fully supported.

Though, if you want TF3D 1.3, I strongly advise you to use Chainfire's package with recompressed textures, as they have better quality, the package itself is significantly smaller and it runs much faster.

Version 0.256 (Nov 14, 2009)

A minor yet highly recommended update!

• Introduced a minus half-texel offset for every texture coordinate that libgles renders (yet another Samsung's bug).
• The difference, now, is huge. First thing you'll probably notice, is a perfect (pixel-wise) Opera 9.7 rendering.
• Second, some of the irritating lines in Xtrakt are gone as well.
• Third, Tower Defense gets a tiny bit more clear and sharp look.

Version 0.257 (Nov 20, 2009)

Following games are now supported:

• Flight Commander
• Experiment 13

Version 0.258 (Nov 29, 2009)

Yet another minor update:

• adds PVRTC support (not sure if it gives anything useful, but let it be: maybe some game for Dell Axim will finally work, maybe not);
• fixes minor ambient lighting issue (as seen in TestOpenGL's donut test;
• removes matrix palette from extensions list (so that glBenchmark 1.1 wouldn't hang);
• and fixes a crash on MindPol's Coin game from their 10 Games for Betting.

I'd say, the latter game is the only reason why anyone would want to update.
Congratulations to MindPol on getting Bronze medal in App Contest with this one!

Version 0.26 (Feb 23, 2010)

Back to the two-digit version numbers!

• S2P 0.80 crash fixed;
• HTC Sense 2.5 texturing and crashes fixed.

Attached File(s)

 

Attaching my versions to this post. hope this helps!

Attached File(s)

 

Thanks, you also have libEGL.dll for me?

Here you go.

Attached File(s)

 

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

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

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

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

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

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

Attached File(s)

 

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

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

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)

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.com/m8/sdk/M8SDK_CHS_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.

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.

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?

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.