pouët.net

I'm about to start coding for OGL ES, and my first hurdle of running existing code is the lack of the matrix stack.

Did anyone else do this? (C/C?++)

I'm about to write my own matrix stack class (hey it's easy), which also implies that my before dynamically linked program now'll be statically linked which is fine since I'm targeting mobiles.

Anyone did this before?

to be honest, I never understood the need of a stack. Just upload matrices to your shader uniforms as you need. There is no more to it...

well, my modular VPL is based around that...
a module connected closer to the screen "wraps" around all else rendering to it.

jaw: You mean OpenGL ES 2.0, right? The matrix stack is there in OpenGL ES 1.x, but was removed from OpenGL ES 2.0 because it's a part of the fixed function state.

Why does writing a matrix stack class force you to link statically? That makes no sense to me.

kusma: yes, 2.0.

about linking statically, I don't feel like extending my API - so far I've managed to keep all OpenGL out of the engine core and the API.

This is of course a matter related to my project only. I.e. I want to reimplement the plain C functions (like glTranslatef) for use inside the object-oriented code.

That still doesn't explain the static vs dynamic linkage, though.

First, the module DLL's are never linked with the executable as you should be able to plug them in and out of the system. "Plugins". So I'm using dlopen/LoadLibrary etc to load these when the program inits.

The modules know nothing or can't access the engine, they're totally isolated.
The engine knows nothing about the modules either, spare what's defined in an abstract class.
Right now each DLL has an abstract factory for inherited classes and that's it.

So in order for the module classes to get the pointer to the master matrix class (owned and linked statically in the executable) the engine would have to supply that in an init function or similar and that's not very nice, that would impact a lot of code and would mean special hacks for this case.

I hope I make some kind of sense ;)

re: matrix stack,I've found that using an external math lib (like cml) is often faster and always more convenient than using opengl's matrix stack, and you can easily make a stack of matrices yourself using STL containers..

yep. actually I'm thinking now that I'll ditch the whole concept, the only reason for it was to be compatible with projects made for a desktop machine with regular OpenGL, but those are so different anyway in terms of performance.

So either way, the phone version of the environment will be vastly different. So I'll do as iq suggested and go with ES 2.0 all the way, and provide good math functions instead for feeding matrices into the shaders.

Why do you want that?

doing some ES 2 ... yeah !
You will have to define a 4x4 matrix in attributes, something like this.
If I remember well, from some es2 sdk example, you can manage (or ont) both modelview and projection on the same matrix. ... you really should get some example somewhere.

my unoptimized but working stack matrix class (for some DC project), with gl like funcs:
MatrixModel.h
MatrixModel.cpp
... the resulting table is in gl order, and can be glloadmatrix'ed. ... no glloadmatrix on ES 2 ? hehe !

glLoadMatrix is fixed function. What you want is glLoadUniformMatrix4f or something.

if you got a nvidia card, download the Tegra Khronos Application SDK for Windows CE 6 with Windows XP/Vista/7 OpenGL ES 2.0 emulator,
it has a ES 2 emulator, and most of all a shitload of good examples.
http://developer.download.nvidia.com/tegra/files/tegra_khr_apps_sdk_100.msi

I mean, there's a device emulator, no need for a real tegra hardware?

More likely he's doing iOS stuff, in which case the iphone emulator works for the basics (but realistically, you NEED hardware for this kind of thing, unless the emulator is smart enough to accurately emulate real device speed, which the iphone one at least definitely doesn't).

Also, there's the powervr sdk with lots of useful stuff: http://www.imgtec.com/powervr/insider/powervr-sdk.asp

off topic:
no, I'm thinking android actually.

on topic:
krabob: cool. I'll look at all that in detail.

I'm planning (if possible) to run my stuff on the phone and send commands to it over wlan during development, so the emulator is only needed for testing the GL ES commands in an initial development phase. I'm on Ubuntu btw, found an emulator by ARM, seems to run on nvidia gtx 480 at least.

http://www.malideveloper.com/developer-resources/tools/opengl-es-20-emulator.php

psionice: great resource, most examples should be compatible and useful for sure.

working with the android sdk emulator is shitty and slow (there are tons of limitations with it, your app can't weight more than some mega,etc... ). Hopefully, debugging with eclipse and android sdk on a real android hardware via usb cable is fast as hell and kicks ass ( a few seconds only are needed to compile, install , and run debugger, contrary to any other embedded sdk I ever saw).
Never tried GL ES 2 on android, good luck. ( note: the management of gl contexts on views is strange, you have to cheat and deal with cases when the device goes to sleep mode, ... )

So what's the android emulator like? Does it try to emulate the actual hardware quite closely (if so, which hardware?!)

The iOS emulator is kind of good.. pretty fast, emulates iphone/iphone 4 (higher res screen)/ipad, with rotation, simulated calls, a few other things you want. It does gles too.

Then again.. apps compiled for the simulator run natively as intel binaries, with access to as much ram as they want. In the old days they'd happily talk to OSX instead of iOS too, I got really screwed once by using an OSX api that didn't exist on iOS ;( That seems to have been fixed at least. There's no camera support though, which is painful at the moment as my current project uses it. It won't even build if you include the camera related headers. I have to do all test + debug on the device, when you're building very often it takes time to copy across and install then load, it's slow :(

the android sdk emulator emulates a ARM chip and some android hardware parts, but not much, and it does it bad. (you can perfectly download the whole sdk over your eclipse for free to test it) . When I said shitty, it is for sure. It takes 5 minutes to start. (hint for beginners: do not close it) Its GL ES 1 implementation looks like a software shit and render very bad. I would be surprised if it manages ES 2. on android, the GL rendering seems driver-based and is always way better on devices.
note: The "intel" directories for the jni libs applies for "android for desktop", not for the emulator.

the iPhone emulators are intel-compiled and seems to use osx directly for GL. (Easier for apple, the sdk only exists on OSX , android emulator has to work on win,linux and osx)

Did some more research. Next issue - on android NDK: no STL support for C++.
But I'm only using vector, list and map from stl.

I have a vector class already, and the lists are replacable with vectors. left is the map. gotta code that on my own or replace it with something else.

Or use something like uSTL (http://ustl.sourceforge.net/) which is also cheating with std::maps, it's using a vector. I don't think it'll be an issue for what I'm using it for. anyway..


I figured that the android emulator was crap as well..

I'm hoping to use gdb in console mode to the phone I hope that's possible since I'm coding in kdevelop and building with cmake. There was some cmake libs for android, gotta test those.

"your app can't weight more than some mega". This is a limitation of compressed assets, per file. You can disable the compression completely or by extension. Also, media files such as mp3 and ogg etc are not compressed.

jaw: In my experience, a simple sorted list handles 90% of the cases where I tend to use std::map. It's easy and fast to binary search, and insertions aren't that bad.

... :)
Use the "crystax" patched version of the NDK for full sTL support
http://www.crystax.net/android/ndk-r4.php
... this is a slightly different version of the official NDK, with only a few difference to allow the stl allocs. Basically, as everything is opensource with android, a guy just did this, and google doesn't care. For rev.4, crystax version was released a few hours later.

First step done:

http://vimeo.com/20404897

"Concept is: Development in real-time of OpenGL ES 2.0 visual effects done over TCP/IP on any device that can run VSXu. VSXu is being adapted in the process to run on OpenGL ES, this is a work in progress in the early stages. If it works on n900 it'll work on more phones - android mainly. iOS won't accept shared libraries so that's a no-go.

What you see:
- running vsxu engine+server (same binary, network communication runs in a thread) on the n900 (OpenGL ES 2.0)
- cable is just for charging the device
- connecting over the w-lan to the phone from the desktop using the network layer in VSXu"

when building for androind im using stlport, works just great