iPhone?
Oh, I am well aware that I wont be able to port Doom 3 style graphics to the iPhone. If only **begins to dream**....
Anywho, what I really want to be able to do is some simple 3D graphics, and maybe some more elaborate 2D graphics. I have used irrlicht in the past and was simply blown away by its ease of use and common sense syntax and small footprint (relative to most other engines). So when I saw the iPhone SDK was based on OpenGLES I thought, why reinvent the wheel if I can just find away to put some OpenGLES tread on the one irrlicht already invented.
So, does anyone have any idea how much work would actually be involved in porting the OS X version of irrlicht over to the Cocoa touch frame work with openglES driver?
Anywho, what I really want to be able to do is some simple 3D graphics, and maybe some more elaborate 2D graphics. I have used irrlicht in the past and was simply blown away by its ease of use and common sense syntax and small footprint (relative to most other engines). So when I saw the iPhone SDK was based on OpenGLES I thought, why reinvent the wheel if I can just find away to put some OpenGLES tread on the one irrlicht already invented.
So, does anyone have any idea how much work would actually be involved in porting the OS X version of irrlicht over to the Cocoa touch frame work with openglES driver?
Does it feature an FPU?
EDIT:
"Features vector floating point coprocessor ("for embedded 3D-graphics")"
Oooh, very nice...
(And SIMD integer instructions.)
I'm starting to think that a custom solution built from the ground up would be best for this sort of device, but maybe porting Irrlicht to OpenGLES would work too.
EDIT:
"Features vector floating point coprocessor ("for embedded 3D-graphics")"
Oooh, very nice...
(And SIMD integer instructions.)
I'm starting to think that a custom solution built from the ground up would be best for this sort of device, but maybe porting Irrlicht to OpenGLES would work too.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
-
- Posts: 914
- Joined: Fri Aug 03, 2007 12:43 pm
- Location: South Africa
- Contact:
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Yeah! So it sounds like it's at least not impossible. some performance approximations would be interesting, but I think that with some optimized drivers you should get enough FPS. varmint, did you already try the simulator, or is it not part of the SDK?
I guess such a port would open a whole new field for indie devs. And a chance to make some money with casual games and small apps, the dev licenses are not that expensive (compared to other console like platforms). Especially since you get an online sales channel for free then. There are some rumors, though, that Apple might be quite restrictive which kind of apps will be put into the download for iPhone. Anyway, games won't be too restricted hopefully.
I guess such a port would open a whole new field for indie devs. And a chance to make some money with casual games and small apps, the dev licenses are not that expensive (compared to other console like platforms). Especially since you get an online sales channel for free then. There are some rumors, though, that Apple might be quite restrictive which kind of apps will be put into the download for iPhone. Anyway, games won't be too restricted hopefully.
You wont be able to test the code with the iPhone emulator packaged with the SDK. It dosnt emulate the OpenGLES part. Which I found out the hardway yesterday. In order to test the code here are the things you need.
1. An actual physical iPhone
2. An intel based mac running 10.5 (10.4 might work, not sure)
3. An iPhone developers license which is 100 bucks. This allows you to send code to the phone itself. You can code for the emulator without the license, but the emulator dosnt support OpenGL es, so in our case the 100 bucks is required.
4. The iPhone SDK (Free )
5. Ported version of irrlicht for OpenGL ES driver.
I have everything on that list except the most important part #5. If someone has already started working on porting this to the iPhone OpenGL ES base, then I would be happy to test if for them if there were missing any of 1-4.
I think this could work wonderfully if we could minimize the memory usage, and be honest with ourselves about the graphics capabilities. However they have a port of "Super monkey ball" running on the device that just looks amazing. So, maybe we are underestimating its capabilities to beging with?
1. An actual physical iPhone
2. An intel based mac running 10.5 (10.4 might work, not sure)
3. An iPhone developers license which is 100 bucks. This allows you to send code to the phone itself. You can code for the emulator without the license, but the emulator dosnt support OpenGL es, so in our case the 100 bucks is required.
4. The iPhone SDK (Free )
5. Ported version of irrlicht for OpenGL ES driver.
I have everything on that list except the most important part #5. If someone has already started working on porting this to the iPhone OpenGL ES base, then I would be happy to test if for them if there were missing any of 1-4.
I think this could work wonderfully if we could minimize the memory usage, and be honest with ourselves about the graphics capabilities. However they have a port of "Super monkey ball" running on the device that just looks amazing. So, maybe we are underestimating its capabilities to beging with?
OpenGL ES is not significantly different from OpenGL, but it is moderately different. (If it wasn't, then you wouldn't hear PS3 developers complaining.)
Here is a short list of what the OpenGL ES has stripped from OpenGL: quad and polygon primitive rendering, texgen, line and polygon stipple, polygon mode, antialiased polygon rendering (with alpha border fragments, not multisample), ARB_Image class pixel operation functionality, bitmaps, 3D texture, drawing to the frontbuffer, accumulation buffer, copy pixels, evaluators, selection, feedback, display lists, push and pop state attributes, two-sided lighting, and user defined clip planes.
I am curious as to why Sony chose to use OpenGL ES instead of just supporting OpenGL, but my guess is it had something to do with time limits. No worries though, as it seems that Sony devs are getting together to make their own API.
Here is a short list of what the OpenGL ES has stripped from OpenGL: quad and polygon primitive rendering, texgen, line and polygon stipple, polygon mode, antialiased polygon rendering (with alpha border fragments, not multisample), ARB_Image class pixel operation functionality, bitmaps, 3D texture, drawing to the frontbuffer, accumulation buffer, copy pixels, evaluators, selection, feedback, display lists, push and pop state attributes, two-sided lighting, and user defined clip planes.
I am curious as to why Sony chose to use OpenGL ES instead of just supporting OpenGL, but my guess is it had something to do with time limits. No worries though, as it seems that Sony devs are getting together to make their own API.
TheQuestion = 2B || !2B
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
varmint said that he has a stripped down OpenGL Irrlicht driver which is running with OpenGL ES. I suggested to make a separate driver from it and add it to the library. If the missing extensions are all easily testable and get a working version just with ifdef's and version checks we might also go for this. I'd need to get some ogl-es emulator probably.
Might take some time until all this happens, but maybe varmint can give an early beta of the driver to some people.
Might take some time until all this happens, but maybe varmint can give an early beta of the driver to some people.
Wow that's pretty cool. If you do support OpenGL ES, then people could run Irrlicht on the PS3 natively. (If they have the license, of course.)hybrid wrote:varmint said that he has a stripped down OpenGL Irrlicht driver which is running with OpenGL ES. I suggested to make a separate driver from it and add it to the library. If the missing extensions are all easily testable and get a working version just with ifdef's and version checks we might also go for this. I'd need to get some ogl-es emulator probably.
Might take some time until all this happens, but maybe varmint can give an early beta of the driver to some people.
TheQuestion = 2B || !2B
-
- Posts: 19
- Joined: Sun Feb 25, 2007 1:31 pm