I've been trying to create a Cocoa project that uses OpenGL. NSOpenGLView is too restrictive for my needs, so I've created my own custom NSView subclass. I need to have multiple copies of this class on screen at once. And I need to use shaders.
What's the best way to organize this sort of project? I've tried a ton of different setups, but I always seem to wind up having invalid drawables, GL errors, trouble managing contexts, etc. Is there a simple way that I'm overlooking? Maybe setting up a single context at app launch and having all views share it?
Stay away from messing with OpenGL yourself...it sucks. Just say no.
I HIGHLY recommend using Cocos2D. Its a FANTASTIC graphics library that is highly supported and documented and handles all the OpenGL nonsense and makes the pain go away. Don't touch OpenGL unless you want to spend more time dinking with technical details than actually making your project happen.
Related
I'm using the Marmalade SDK, my question is, can I use only cocos2d-x and Box2d, and not use Iw2d, IwGx, IwGL altogether (or vice versa)?
And what factors will my choice depend on regarding if I want to use cocos2d-x and Box2d, and not all the others (or vice versa)?
P.S I'm developing a 2d game that will need minimal physics
you can use Cocos2d-x without using Iw2D, IwGX, etc. Cocos2d should abstract these things for you. Cocos2D-x is a complete game engine, where Iw2d is only a rendering system that renders 2d sprites für you.
What systems you want to use depend on how much low-level work you want to do yourself.
If you use Cocos2D-X it will have support for a lot of features out of the box. Like scenes, sprite-rendering, skeleton-animation, effects, particles etc..
Iw2D just abstracts the low level OpenGL-API so that you can render sprites with just one function call. But it does not support animations and other features. So you would have to include other projects or write the functionality yourself.
IwGx is a wrapper for OpenGL which introduces states so that the OpenGL-API is easier to handle.
IwGl is just plain OpenGL and you would have to implement even the rendering yourself.
Which one to use depends on the project. When you just want to make a 2d game cocos-2d or Iw2D should give you enough control to succeed doing so and also you will save time because you can use already tested systems.
Box2d is only used to drive the physics simulation of your game world. You can use it with all of these systems.
Depending on your C++ and game programming experience i suggest to first use a game engine (like cocos2d-x) or Iw2D to learn the basics. For your second game you can still switch to a more low level api if you want to.
Sounds like you can focus on the Quick flavor of Marmalade, which has cocos2d and box2d bundled up with Lua. That will make for easy start and development.
I'm familiar with the basics of objective-c and cocoa touch and I want to start now my first large iOS project.
I want to build an iPad app with a histogram like you know it from several photo apps where you can see e.g. the distribution of brightness in a picture. But it needs to be smart, i.e. scrolling horizontal, setting borders and pinching for zoom-in and zoom-out.
Is it possible to handle this requirements with iOS7 standard API or do I need a 3rd party framework like Core-Plot to achieve a histogram I described, and if so, which one would you prefer and why.
Thanks for your help!
Is it possible to handle this requirements with iOS7 standard API or do I need a 3rd party framework
It's certainly possible to do it all yourself with no help from anybody except the frameworks that Apple provides. Whether that's the best solution for you, only you can decide. I think these are the relevant considerations:
You seem to have some fairly specific requirements and it sounds like you may need fairly fine control over exactly how this histogram looks and works. These are good reasons to create the histogram yourself.
You're still fairly new to Objective-C, Cocoa Touch, etc. That's a good reason to look for something that's already written. You'll save a lot of time and frustration, but you may have to be a little more flexible in terms of what you're willing to accept; it's unlikely that anybody has already written exactly the thing you want.
I'd suggest taking a shot a building what you want, and if it turns out to be a bigger thing than you're ready to tackle, you'll at least have a better understanding of what's involved.
To get started, read up on UIBezierPath. All you really need to do is to create a view that accepts an array of numbers and draws the corresponding graph. Don't worry about zooming and scrolling yet, just make a view that draws the graph. Once you have that, you can read up on UIScrollView, which will give you the scrolling and zooming with almost no work.
In IB one can instantiate controllers, build up references to UI elements, and define action targets. It is also possible to do that programmatically. I wonder what (most) seasoned Cocoa developers prefer?
In many other environments, I would not bother too long with interface builders (lower case), but the Apple tools are clearly a class of their own. Still, do they carry further, or are they beginners' tools? And why?
I think it is clear that they are the right choice for assembling and laying out the UI. But what about associating the UI elements and controller objects?
Experienced Cocoa developers use Interface Builder extensively. It's the inexperienced ones who tend to distrust it, because the UI builders for other environments usually suck, so they assume Interface Builder is like that. It's not. Cocoa and Interface Builder are intimately connected. It's hard to develop an app without using Interface Builder — to the point where if you look through the Cocoa-Dev mailing list archives, you'll see a lot of frustrated developers new to Cocoa asking how they can avoid using IB. The answer both from Apple employees and from veteran Cocoa devs is the same: Just use it.
Think I'm full of crap? Open any professionally done Cocoa app. Seriously — any Apple app, any third-party Cocoa app. Now go to the Resources folder. Poke around and you will see nibs everywhere.
As for how much IB is too much — there is a point where connections will be set up by code. In general, hooking up UI elements and controllers is usually done in IB, and even controller-to-controller connections often are as well, though that's more iffy. It essentially comes down to which is less work to set up and maintain. The big exception to IB's dominance, ironically, is custom views. When you have a custom view that is only used once, it just isn't worth the time to create an IBPlugin for it. In that case, usually the controller is hooked up to the view in IB and then the controller hooks up the view to anything else it needs.
It mostly depends on their background as a developer and what you could consider "experienced".
I've seen people refuse to even open IB.
My opinion is that to make an app that doesn't look like every tutorial app from the iPhone 3G era, you have to use IB, and to eschew it and try to build a good looking sophisticated app completely in code is a waste of time and can make your code hard to read unless its done perfectly.
Like apple's documentation says, the less code you write the less you have to maintain, and I think that it is a very good point.
You associate controllers with UI elements at all times, this is what is called the MVC schema.
Any experienced Mac or iPhone developer will use IB for almost all of their interface wiring, and as an "inversion of control" object creation manager. By putting your wiring in NIB instead of code, it's not loaded until requested, and is easier to manage.
I am a beginner in Obj C development, though quite experienced (over 10 years) with other ECMAscript based languages and OOP development.
I want to build a simple flipbook style animation, controlled through swiping motion. I'm sure extremely simple for any advanced ObjC coders.
Can anyone with extensive ObjC-CocoaTouch experience give me some higher level recommendations?
ie,
1 -general application design, should I start with a simple view based application, or navigation based or?
2 -should I use 3rd party animation frameworks such as Cocos2D, or stick with built in classes and methods?
3 -if using built in methods, classes, what is the recommended way of achieving a animation, that will be controlled via swipe and touch gestures?
4 -I want to eventually have multiple 'flipbooks' that I can 'instantly' swap with one another, ie to give the net effect of an object changing color, etc, but not sure how to approach this from a memory management point of view, related to #1 above
Except for point 3 above, I'm not expecting any actual code examples. Just general guidelines to follow and perhaps, what are some next steps I should take in my goal as an ObjC code samurai.
While I am no expert I can think of a few things you could pursue to get the effect you want. Sounds like you want have a somewhat immersive experience for users. Cocos2D would definitely fit that bill. Me and my team at Get Set Games have been using it for the past year and have not been dissapointed with it. We haven't done the flipbook effect you speak of but quite possibly someone in the Cocos2D forums has implemented are at least attempted this. Forums are accessible here.
Having said that I think starting with the iPhone SDK UIKit framework and basic examples that come with it are great. There is a great array of samples on scrolling, swiping, etc. If you want to hook in Cocos2D or other frameworks later that's definitely an option.
I'm programming this game in OpenGL, mostly working inside an single EAGLView (I'm not that familiar with Views and other Cocoa concepts, my work to this point only involved using OpenGL to draw my game and calculating the logic myself).
I'm being told for adding a ton of features:
Send mails to Your friends when You achieve certain objectives in the game.
Interact with facebook ( I'm being told that I will provided with all the libraries I need).
Interaction with store kit !, buy weapons, Items, etc..
I would like to know, how effort and time will take to add those features... It's complicated to use GameKit ..StoreKit..MediaPlayer and other frameworks ?, considering that I only have worked with OpenGL to this point ?
Short answer: no, it's not hard to add those features.
Longer answer: depending on your background, if object-oriented concepts are new to you, it may take you longer to learn how to use the objects and frameworks. The only thing you can really do is read over the documentation and look at tutorials and decide how complicated it looks. Really, though, it's all well designed and thought out and if you have a programming background, a couple of the examples should give you plenty to start with and you'll get it all soon. And then come on back with your specific questions and smarter devs than I will answer them.
The hard part is all the details: weapons, items, etc.