Today, I continued working on my port of Rainbow from Javascript/WebGL to C++/OpenGL. I got steering in, and tested out collision detection -- [nearly] working first time.
As you can see in the screenshot above, I haven't yet turned on depth testing (to make the stripes render in the proper stacking order). Also, if you are an astute counter of pixels, you will notice that this shot is exactly the size of an iPhone4 display.
Yep, instead of graphical effects, I decided to find out how similar the OpenGL 3.2 and OpenGL ES 2.0 APIs were, and got an iPhone compile working. Turns out: really really similar; though the GLSL flavors are unfortunately somewhat different. Also, using GL_STREAM_DRAW vertex buffer objects instead of just pointing to data in memory seems to be a bad idea on iOS (versus the only game in town in GL3).
So it looks like my mobile version is going to probably have some unfortunate #ifdef magic in place in the graphics code. On the other hand, steering (multiple) rainbow fronts around with multiple fingers is already working (and fun!), and there's a fair amount of room on an iPhone screen to do it in.
I don't know much about iOS development; don't you need to do that in ObjectiveC?
ReplyDeleteFor one, C(++) is a subset of ObjectiveC(++), so C++ is ObjectiveC++ already.
DeleteBut, yeah, you do need to use [message passingSyntax:nil] to do some of the GUI setup. Once you've got an OpenGL context and an event handing layer in place, you can pretty much forget everything you ever knew about square braces, __strong and __weak references, blocks, and other ObjectC tomfoolery.
In the case of Rainbow, libSDL is providing this abstraction layer already, so I avoid ObjectiveC entirely. (Of course, given the subset of SDL I'm actually using, I'm somewhat tempted to just write the shim code myself.)