I spent the weekend trying to see what the state of the art is for iPhone development, and ended up getting pretty far along in making a native iPhone game. (See http://robterrell.com/iphone_snapshot_0.jpg – the little figures are renders of the same models I originally used in Unity.)
What was really interesting was to learn that lots of useful CoreGraphics things, like OpenGL and CGGLContext, exist on the phone. There’s an OpenGLES library. No GLU or GLUT or glaux that I could find, though.
I don’t know any OpenGL at all, but if someone has some OpenGL code that can draw something interesting without GLUT or glaux, I’ll drop it into an iPhone app and we can see what it looks like.
Now to make this post relevant… even if it was software rendered 3D, it would be fantastic to develop for the iPhone in Unity. iPhone development is just Cocoa – I bet making an iPhone runtime for Unity wouldn’t be impossible, if you scale down your expectations.
The game in the screenshot is 2D (just bitmaps moving around). I just now tried to compile a true OpenGLES app for the iPhone but it can’t find the gl symbols (i.e. glBegin) at link time, even with the OpenGLES framework specified.
If you are 15, how long ago could you have possibly done that?
Also, do you have any tips to become smarter? I feel I got a slow start because all my parents did was watch TV and I didn’t know any better than to copy them.
Well, a long time ago relative to how long I’ve been programming. Considering I can now render Quake 3 maps, with a FPS camera view, and collision (but terrible collision response :(… Still need to work on physics), I’d say a year in tennager years, or 3 months in regular time
Umm…lol.
Get some type of motivation, read, read, read, experiment, ask googles questions, give it a lot of dedication. Oh, and did I mention read?
Seriously, I pretty much just sat down, read tutorials, articles, parts of books, documentations, then looked at how other people implemented something (not always if I had a good idea what I was doing), then tried to do it better (and different). Basically, give it all you’ve got, and always thrive to make what you have better.
@bliprob, if you can’t run true OpenGL apps, then how did you run the game you showed a screenshot of?
I gave this matter some thought, and here’s my take:
Find something you don’t know how to do, then do it (say, make a game, make a small movie, make a kickass 3D engine). Follow it through all the way. Whenever you hit a stumbling block just keep chipping at it until it’s overcome.
This gives you (after a few years)
Some concrete knowledge (that will probably get outdated)
Problem solving skills (that carries into different fields just fine)
Confidence that you can solve anything given enough time.
Doesn’t solve the “getting off to a slow start” problem, though - but you’ll probably live for some 70 years, so you’ve got plenty of time to catch up
@bronxbomber92: in the screenshot, the game uses 2D bitmaps taken from 3D renders of characters (in Cheetah 3d). All of the art is stored as PNG files, which are rendered using [UIImage compositeToPoint] in the draw loop. The bridge and water artwork was made by hand in Freehand and Photoshop. Yes, Freehand, the artist is old school.
I’d like to get some 3D working on the phone, but I don’t know how to get around the linker error.
Yeah, like Jon said, OpenGL ES is not the same as OpenGL. Think OpenGL with 80% of the historical cruft removed. The first six letters in the name are the same though
Wow, glBegin() is cruft? They must have cleaned the heck out of that API. Thanks for the tip. And sorry to spam the Unity forum with unrelated nonsense. I was just excited.
The hardware most likely only operates on some array representation (i.e. vertex buffer objects). So glBegin and friends are somehow emulated before going to the hardware. This is both inefficient and needs code in OpenGL runtime to implement the functionality. On embedded platforms those concerns are more important than on regular machines.
