Some Litte Questions

[dflemstr]

Well you say it handles all the OpenGL 1.1 specification?

Nope, I don't
Pickle only implemented enough for Quake 2/3, no more.

Do you have a link towards Pickle's explanations?

Announcement post (With old, broken quotes ):
http://www.gp32x.de/board/index.php?/topic/46958-quake2-nanogl/page__hl__pickle opengl wrapper
Couldn't find anything better ATM.

Another question about OpenGL ES: is it simply OpenGL without some functions (such as glBegin/glEnd) or have the other functions changed? What I mean is, if I make an SDL/OpenGL app which uses only vertex arrays and stuff that OpenGLES can cope with, can I directly compile it with OpenGLES or will I have to alter my code?
Second question - sorry -: Is it true OpenGL ES 2.0 doesn't computes itself all the matrix math (translate, rotate...), and that next OpenGL specifications are gonna do so?

OpenGLES is a subset of OpenGL 2.0 so yes, it is possible to write OpenGL code that can be compiled as OpenGLES
OpenGLES 2.0 has no fixed pipeline and requires you to do all your matrix math yourself, yes. The same is true for OpenGL 3.0; shaders are the future of 3D technology.

 

[limestrael]

Do you have a link towards Pickle's explanations?

Announcement post (With old, broken quotes ):
http://www.gp32x.de/board/index.php?/topic/46958-quake2-nanogl/page__hl__pickle opengl wrapper
Couldn't find anything better ATM.

Thanks! So that's NanoGL. I had already seen this word on the forum, but I didn't know what it was up to.

Another question about OpenGL ES: is it simply OpenGL without some functions (such as glBegin/glEnd) or have the other functions changed? What I mean is, if I make an SDL/OpenGL app which uses only vertex arrays and stuff that OpenGLES can cope with, can I directly compile it with OpenGLES or will I have to alter my code?
Second question - sorry -: Is it true OpenGL ES 2.0 doesn't computes itself all the matrix math (translate, rotate...), and that next OpenGL specifications are gonna do so?

OpenGLES is a subset of OpenGL 2.0 so yes, it is possible to write OpenGL code that can be compiled as OpenGLES

Okay, so I can easily develop something on my computer without having to use an OMAP emulator.

OpenGLES 2.0 has no fixed pipeline and requires you to do all your matrix math yourself, yes. The same is true for OpenGL 3.0; shaders are the future of 3D technology.

I don't understand. Does the KhronosGroup do so in order to match the current and future GPU architectures?
Concerning shaders, the little knowledge I have is about fragment shaders, I've never used vertex shaders. So, obviously, I don't see how they could replace matrix computations (if this -as I understood- is their aim).
I'm not gonna bother you with it anymore ^^, but I'm kinda interested by this topic, so do you have some good links?

 

[dflemstr]

OpenGLES 2.0 has no fixed pipeline and requires you to do all your matrix math yourself, yes. The same is true for OpenGL 3.0; shaders are the future of 3D technology.

I don't understand. Does the KhronosGroup do so in order to match the current and future GPU architectures?
Concerning shaders, the little knowledge I have is about fragment shaders, I've never used vertex shaders. So, obviously, I don't see how they could replace matrix computations (if this -as I understood- is their aim).
I'm not gonna bother you with it anymore ^^, but I'm kinda interested by this topic, so do you have some good links?

They want to generalize the GPU so that it can be used for anything, not just graphics rendering. You have heard of heavy maths and physics being done on GPUs, haven't you? Well, the guys basically want to remove everything that is draw-polygon-on-screen-related and widen the usage possibilities of GPUs. The programmer should have control of the whole process, they say.

In OGL2.0 vertex shaders, it is possible to use "built-in" transformation matrices (those that are generated by glLoadIdentity();, glTranslatef(x,y,z); etc), so in a way, OGL still does the matrix stuff for you even if you make your own vertex shaders. In GLES 2.0/OGL3.0, you can't rely on those built-in matrices, but must instead pass along your own to the vertex shader (so you "create your own" translation functions etc and send the result matrices to the shader using an uniform (I think)). It's not too difficult, but it's something you wouldn't want to do just to create a basic game, if you know what I'm saying. There's been talk about creating some kind of common "shader library" that everyone will use to make life easier in situations like those.

I don't really have any "good links" since all material I can think of can be found with Google. Hope you find something interesting, though!

 

[wardred]

There's the OpenglES 2.0 programming guide. I haven't done this myself yet, but if you look for "shader language" there ought to be something out there that covers these topics outside of books. Luck!

 

[Kramy]

But today we have 32 GB cards, and all the games you'll ever install for the Pandora combined will max take up 2048 MiB of space, so it's not like it's an imminent problem.

No.

 

[femngi]

But today we have 32 GB cards, and all the games you'll ever install for the Pandora combined will max take up 2048 MiB of space, so it's not like it's an imminent problem.

No.

What the hell? You are aware people are going to want to cram all their ISOs onto one card?

 

[WizardStan]

dflemstr is suggesting that all programs could be installed to a single SD card. All data such as ROMS and ISO and MP3s and movies could be stored to a second card.
This, of course, fails because some programs are quite large in and of themselves, by virtue of the fact that they are complete games that contain a lot of data, data that needs to be stored alongside the program. Ur-Quan Masters, for example, takes up 437 MB by itself if you've got all the add on packs (and why wouldn't you?)
It also assumes that you have a single, huge SD card. Eight 2 gig cards are cheaper than a single 16 gig card, so some users might choose that route, not to mention the cards that users already have lying around.

 

[limestrael]

OpenGLES 2.0 has no fixed pipeline and requires you to do all your matrix math yourself, yes. The same is true for OpenGL 3.0; shaders are the future of 3D technology.

I don't understand. Does the KhronosGroup do so in order to match the current and future GPU architectures?
Concerning shaders, the little knowledge I have is about fragment shaders, I've never used vertex shaders. So, obviously, I don't see how they could replace matrix computations (if this -as I understood- is their aim).
I'm not gonna bother you with it anymore ^^, but I'm kinda interested by this topic, so do you have some good links?

They want to generalize the GPU so that it can be used for anything, not just graphics rendering. You have heard of heavy maths and physics being done on GPUs, haven't you? Well, the guys basically want to remove everything that is draw-polygon-on-screen-related and widen the usage possibilities of GPUs. The programmer should have control of the whole process, they say.

In OGL2.0 vertex shaders, it is possible to use "built-in" transformation matrices (those that are generated by glLoadIdentity();, glTranslatef(x,y,z); etc), so in a way, OGL still does the matrix stuff for you even if you make your own vertex shaders. In GLES 2.0/OGL3.0, you can't rely on those built-in matrices, but must instead pass along your own to the vertex shader (so you "create your own" translation functions etc and send the result matrices to the shader using an uniform (I think)). It's not too difficult, but it's something you wouldn't want to do just to create a basic game, if you know what I'm saying. There's been talk about creating some kind of common "shader library" that everyone will use to make life easier in situations like those.

They should! Even if matrix math isn't anymore computed by the OpenGL implementation they should at least provide an external utility lib that does those computations, as they did concerning windowing with GLUT or tesselations with GLU. OpenGL MUST remain simple to learn!

 

[Adventus]

I'll just clear some thing up. Pickle did not write NanoGL. It was written by the guy who did the Nokia N95 Quake ports. NanoGL implements a small subset of OpenGL 1.1, mainly the glBegin / glEnd stuff.

Okay, so I can easily develop something on my computer without having to use an OMAP emulator.

There's an OpenGL ES emulator available from Imgtech.

They should! Even if matrix math isn't anymore computed by the OpenGL implementation they should at least provide an external utility lib that does those computations, as they did concerning windowing with GLUT or tesselations with GLU. OpenGL MUST remain simple to learn!

As dflemstr was hinting at inorder to support matrix transformations they would have to implement the whole Fixed Function pipeline. This would add overhead to the driver and goes against the whole philosophy of OpenGL ES 2.0, if you want fixed function use OpenGL ES 1.1.

 

[limestrael]

I'll just clear some thing up. Pickle did not write NanoGL. It was written by the guy who did the Nokia N95 Quake ports. NanoGL implements a small subset of OpenGL 1.1, mainly the glBegin / glEnd stuff.

Okay, so I can easily develop something on my computer without having to use an OMAP emulator.

There's an OpenGL ES emulator available from Imgtech.

According to what dflemstr said, I don't need it. Unless you speak about an OpenGL ES 2.0 emulator?

They should! Even if matrix math isn't anymore computed by the OpenGL implementation they should at least provide an external utility lib that does those computations, as they did concerning windowing with GLUT or tesselations with GLU. OpenGL MUST remain simple to learn!

As dflemstr was hinting at inorder to support matrix transformations they would have to implement the whole Fixed Function pipeline. This would add overhead to the driver and goes against the whole philosophy of OpenGL ES 2.0, if you want fixed function use OpenGL ES 1.1.

Yes, but how could you possibly make a 3D app without matrix computations? Can you do the same through only shaders?

 

[lulzfish]

In OpenGL ES 2, the application manages its own matrices in the CPU and sends them to the vertex shader, which does transformation.

 

[Adventus]

According to what dflemstr said, I don't need it. Unless you speak about an OpenGL ES 2.0 emulator?

ImgTech supplies both an OGLES 1.1 and OGLES 2.0 emulator (though they're more wrappers than emulators). Unless you know the exact functions/parameters that aren't supported in OGLES, you may aswell use an emulator (its just a case of linking to the library). It saves you having to convert anything down the track. The ImgTech SDK also gives you a matrix library and many other helper libraries.

Yes, but how could you possibly make a 3D app without matrix computations? Can you do the same through only shaders?

There are many reasons for allowing the application to handle matrix computations. Here's some of them:

• Having to call an external function in the driver over and over to perform a basic matrix function can produce a CPU bottleneck.
• The developer always knows more about the matrices than the driver. Under some conditions the OGL implementation has no choice but to use full 4D matrix arithmetic, usually you only require 2D+Offset or 3D+Offset matrices.
• It can easily be abstracted from the hardware (and therefore driver). There are better maintained, higher performance matrix libraries out there.
• It unneccessarily increases the memory footprint and complexity of the driver.
• Tuning matrix libraries can take a long time. This is compounded by the fact that ES is targeting many different CPU architectures, not just x86.

For these reasons most high performance 3d engines do not rely on the OGL tranformation pipeline.