View Full Version : NanoGL for Fremantle?
It would be wonderful if someone could port the NanoGL wrapper to Maemo 5.
The code comes originally from the S60 ports of the Quake engines (http://koti.mbnet.fi/hinkka/Download.html), and then it was modified by "Pickle" (1 (http://www.phoronix.com/forums/showthread.php?t=15964)) (2 (http://www.gp32x.com/board/index.php?showtopic=47407&st=0)) to run Quake 3 on the Pandora.
I can't find Pickle's source code, but it seems to me someone needs to get that library ported for Fremantle, so people can compile OpenGL games / applications for Fremantle.
This might be of some interest: http://forum.openhandhelds.org/viewtopic.php?f=14&t=884
Very interesting. One other problem is that apparently clutter is only supported way to get acceleration. When using Opengl ES directly hildon-desktop has to be shutdown first. I remember Kate Alhola mentioning it somewhere.
attila77
2009-05-21, 09:35
Yikes. I hope higher level GL access (like via Qt or sorts) gets wrapped automatically or made coexist with the desktop, switching back and forth manually would be a pain.
Very interesting. One other problem is that apparently clutter is only supported way to get acceleration. When using Opengl ES directly hildon-desktop has to be shutdown first. I remember Kate Alhola mentioning it somewhere.
I really, really hope that's not true anymore. :(
One other problem is that apparently clutter is only supported way to get acceleration. When using Opengl ES directly hildon-desktop has to be shutdown first. I remember Kate Alhola mentioning it somewhere.
mikkov: can you track that down for me? If you can find it, I think I should raise a bug right now, because this will really get application porters upset in the future.
I don't think the Maemo SW developers quite understand how upset developers will be if they are told that they must rewrite their OpenGL applications for Clutter to use hardware graphics acceleration.
I certainly don't want to have to write a hack that shuts down the desktop (and all the functionality that comes with it) just to play a game.
sjgadsby
2009-05-21, 19:05
mikkov: can you track that down for me?
I believe this discussion on Maemo developers (http://lists.maemo.org/pipermail/maemo-developers/2009-March/054392.html) may be relevant.
This post (http://lists.maemo.org/pipermail/maemo-developers/2009-March/054374.html) from March is especially relevant:
I have tried and got both native OpenGL-ES2.0 applications and Qt4.5 OpenGL-ES2.0 applications working together with Hildon desktop composite window manager.
I tried same thing with clutter but there is some issue with it. I have not yet had time to investigate more, i just returned from my Bossa conference trip.
We are here considering to set up wiki pages avbout how to use 3d acceleration in Fremantle and collect there instructions needed to get it running.
Kate
This post (http://lists.maemo.org/pipermail/maemo-developers/2009-March/018639.html) is puzzling and a bit unsettling, however:
As Kate has already proven, multi-context works.
But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...)
It sounds like OpenGL will work, but hildon-desktop "stands in the middle" and does the actual rendering for your app. So OpenGL apps may need to kill the desktop to get decent rendering speeds.
EDIT: Kimmo gives the gritty details about the performance impact of this in this post (http://lists.maemo.org/pipermail/maemo-developers/2009-March/018645.html). Most of it is over my head, but delays of 10-25ms don't sound stellar.
Here's the critical quote:
killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...)
I assume that this is similar issue as using desktop effects and 3d apps at same time in linux pc. My experience is that it just doesn't work very well or at all. DRI2 should helping here
In extras-devel there is this nice game call hex-a-hop, which afaik is pure OpenGL ES. It installs and plays nicely. At full screen, but just like any other Fremantle app, no difference there. Without the usual navigation bar though, but just like the SDL games, and there is a way to get off the app at any moment.
Intrigued by this thread I did some tests and I found no problematic situation e.g.
- Media Player keeps your music in the background.
- IM and email notifications come and go as usual.
So it looks like the behavior is more or less the same than with Diablo SDL games. Please port/write more OpenGL ES apps! :)
qwerty12
2009-05-21, 20:19
Hex-a-hop is plain SDL; no GL.. It's even available for N8x0. :)
Good to know. :)
If anybody can point out to an OpenGL ES app in extras-devel I'll give it a try.
I must say that I don't know any OpenGL ES 2.0 application anywhere :)
Someone compile Quake 2 :)
pipeline
2009-05-21, 22:49
grab the source from here (0.16.1) :
http://icculus.org/quake2/#download
Then grab the data files from the quake 2 demo version... you can use my archive :
http://wardenclyffetower.com/MaemoFiles/quake2/quake2demodata.tar.gz
Someone compile Quake 2 :)
...aaaaand we're back to my first post. We need a wrapper for plain OpenGL apps to be able to use the GL ES 2 instruction set.
SO, we need someone to port NanoGL (or equivalent) to Maemo so devs can port Quake 2/3 (or other OpenGL apps) to Fremantle.
EDIT:
grab the source from here (0.16.1) :
http://icculus.org/quake2/#download
Then grab the data files from the quake 2 demo version... you can use my archive :
http://wardenclyffetower.com/MaemoFiles/quake2/quake2demodata.tar.gz
pipeline, we want to test OpenGL performance. Does this port have OpenGL or just software rendering?
pipeline
2009-05-21, 23:02
it has everything...
correction : it has opengl not sure if it will work with opengles
they also extract video drivers into their own library files so you could build for software and find source from an opengles quake 2 driver and combine the two.
it has OpenGL but it cannot have ES 2.0 if it's from 2005
Please port/write more OpenGL ES apps! :)
afaik it's not even possible to test Opengl ES 2.0 applications with SDK alone. You would need some real hardware to see if anything works
Just a note, lardman's first post leads to this project, gl-wes-v2 (http://code.google.com/p/gl-wes-v2/), which is specifically targeted to the OMAP 3 (in this case, the Pandora, but close enough ;) ). It has some stuff in its SVN (http://code.google.com/p/gl-wes-v2/source/browse/#svn/trunk) updated on May 4th. Perhaps this is a good start to get something compiled for testing?
afaik it's not even possible to test Opengl ES 2.0 applications with SDK alone. You would need some real hardware to see if anything works
Duncan Cragg has a way (http://lists.maemo.org/pipermail/maemo-developers/2009-March/054381.html).
My approach is that I just run the PowerVR SDK in the X86 mode. I notice that the lib/.h files have now arrived for cross-compiling to ARM.
By the way, it's amazing how many levels and layers you can go through.
In case anyone else is put off trying it: I run in X86 SDK mode to the PVR ES 2.0 emulation lib, which presumably uses the X86 SDK's GL libraries and then goes to the Xephyr X11 app. This then runs into my Ubuntu's X11, which is created by VMWare inside Windows XP inside a laptop with Intel Graphics chips. (So I'm not expecting great performance! But it works fine for testing. =0) I get "direct rendering: Yes" from glxinfo inside my VMWare guest, so there's a slight chance that there is some acceleration going on somewhere in the pipes...
I don't want to wait until the hardware is released for people to start porting 3D apps!
So can we use any of the information here for Maemo 5?
OpenGL ES for SDL 1.3 (Pandora) (http://www.gp32x.com/board/index.php?showtopic=48023)
Ok, well just got a response from Kimmo Hämäläinen in the developers mailing list. Looks like there won't be any GL games in Maemo for a while.
I guess the good news is that he's working on it.
Yes, [there is currently] about 30% penalty [for GL ES applications] with the [Hildon desktop] compositor, but I'm working on "non-composited" or "game mode" for hildon-desktop that allows shutting down the compositor and rendering directly to the screen (without killing hildon-desktop). I still need to get it working with dialogs and menus popping on top of the non-composited application, but I guess it'll work in the end somehow.
The other good news that he mentions in one of his posts is that hildon-desktop will be open-source, so we should be able to fix it to allow game playing or whatever else (by whatever method we choose).
Isn't hildon-desktop open source already?
Probably yes, but no hw accel atm so is a moot point ;)
I didn't think that it was good news when he said, "it will be open source; fix it yourself," I think that was a frustrated response to my comment, "That's disappointing," but I did think his response that he's working on it is good news.
I think that I should quote my answer to this question also this Forum:
I have been having several presentations to maemo community how to use OpenGL-ES in maemo
You can find them from my blog http://blogs.forum.nokia.com/blog/kate-alholas-forum-nokia-blog
It is ot so much question of transition libraries but understanding what is OpenGL-ES and
how it relates to desktop OpenGL
I checked pandora wiki http://pandorawiki.org/Development_tutorials . It looks a like
they are having very similar approach, no silver bullet OpenGL to OpenGL-ES translation library
but just OpenGL-ES1.1 tutorial and example how to use OpenGL-ES with SDL.
I have had my tutorials about how to use OpenGL-ES2.0 and how to use it with Qt .
If you read http://pandorawiki.org/OpenGL_ES_1.1_Tutorial . It tells a lot what is
the qestion. There is just no single "OpenGL" but desktop OpenGL has many, many
legacy layers of API's . Mobile OpenGL implements only the most efficient subset of them.
Because there is hundreds of ways to use OpenGL, there is no simple way to convert.
The pandora OpenGL-ES1.1 wiki tries to explain ( as i had in my presentations/blog and maemo wiki page )
that as example OpenGL has legacy API glBegin/glVertex/gEnd that are obsoleted in OpenGL-ES
and OpenGL-ES only supports way to pass vertexes as array. Of course passing them as array is much
more efficient, just one API call with big number of vertexes as opposed one call for one coordinate point.
That just an example what is the difference.
For game developer it is much more sense port the application to use vertex arrays because it is
more efficient also in desktop.
When we go to OpenGL-ES2.0 or Desktop OpenGL-2.0, we have thing called programmable shaders.
OpenGL1.x or OpenGL-ES1.x has fixed function non programmable pipeline doing transformations and lighting.
In OpenGL-(ES)2.0 it is all programmable and it offers much more features to make much better
looking games. I strongly recommend to take it in use.
If you still would like use fixed function pipeline to port old not so advanced games, you can
still use OpenGL-ES1.x emulation libraries in maemo. I hope that we can get them in to next
SDK release.
Kate
Looks like there won't be any GL games in Maemo for a while.
Port games to OpenGL ES 2.0 and they will work. Last week I saw a proof of concept and I was impressed.
That is excellent news. It is good to hear that this is being addressed inside Maemo, and clearly it is intended to be ready by the time hardware is released.
Opengl es != opengl. A lot of code must to be rewritted to port an opengl game to opengl-es. Opengl-es 2.0 is more like opengl 3.0. I have a cool 3D game that i developed for iphone some months ago. I am awating for the release of the new maemo device to port it to freemantle.
Sorry for my english, i know it is bad :D
actually today Kate was saying that OpenGL ES 1.? (too late & lazy to recall now) works as well and there is a version available internally that seems to work. I don't know more details but surely she and knikkane do know more.
and speaking of iPhone developers, it's interesting to see that iPhone is moving to OpenGL ES 2.0. I wonder how easy/complex will be to port such apps between both platforms.
and speaking of iPhone developers, it's interesting to see that iPhone is moving to OpenGL ES 2.0. I wonder how easy/complex will be to port such apps between both platforms.
Games shouldn't need any specific changes to the game core, because OpenGL handles almost everything (events, key presses,...), although some specific iPhone code might need to be ported (just guessing here, don't know the iPhone platform).
I guess that should be easy to do such ports :).
I'm also guessing, but I suspect that the core of most games on the iPhone may well be using underlying OpenGL ES technology; but they'll be written in ObjectiveC.
Notwithstanding whether or not ObjectiveC compilers are available for other platforms, the monetisation of the App Store discourages people from publishing their source code.
I'm also guessing, but I suspect that the core of most games on the iPhone may well be using underlying OpenGL ES technology; but they'll be written in ObjectiveC.
Yah probably, I forgot that this language* exists :), but you can also write C or C++ OpenGL code that will run in the iPhone (xcode will do the required translation).
* "When you see Objective-C code for the first time in your life, your stomach will turn and your eyes won't know where to look and you will feel dizzy."
My iphone game is pure c++, not objective c. Iphone devkit comes with gcc, then any language supported by gcc could be compiled by the iphone sdk and runs on iphone with no problems. There are some changes with opengl and opengl-es, glbegin/glend/glvertex/glnormal... it is not suported on opengl-es, it only supports vertex arrays and vbo. That is faster than use glvertex or glnormal etc... but a lot of software that runs with opengl must to be rewrited for opengl-es.
http://en.wikipedia.org/wiki/OpenGL_ES
Hmm, I wonder if this has already been patented....
http://www.freepatentsonline.com/EP1847966.html
konttori
2009-07-28, 10:18
I would assume that actually getting some decent games to the maemo platform will require paid content delivery model. Game development tends to require so much effort and time that getting paid is really needed. Now, trinket games is another thing. Fortunetely, for that niche (?) maemo has flash runtime. I would really not write trinket games on anything else but flash.
I would assume that actually getting some decent games to the maemo platform will require paid content delivery model. Game development tends to require so much effort and time that getting paid is really needed. Now, trinket games is another thing. Fortunetely, for that niche (?) maemo has flash runtime. I would really not write trinket games on anything else but flash.
You can also have some cool linux games and emulators running in maemo5 that don't run smoothly in the current devices. I've tested some inside SB, some of them has a lot of issues and a lot of external dependencies, others run with some glitches (colours, fullscreen issues), if someone with a device and some linux/terminal knowledge offer to test them, I can create a package and send those to extras, if they work well :)
konttori
2009-07-28, 21:47
Indeed, with emulators, you can get access to content that has already been developed as paid content. Now, as to cool linux games. There are a few, so, if you can port some, that would be splendid! How about tuxracer and neverball! neverball would love to use the accelerometer as well. Come to think of it, that would be natural for the tuxracer as well.
nikolajhendel
2009-07-28, 22:00
I would kill for uae emulated at 100% speed. Playing all the old amiga games on this form factor would be perfect.
vBulletin® v3.8.8, Copyright ©2000-2024, vBulletin Solutions, Inc.