This is something I've pondered/struggled with and would love to hear some opinions on. I have a good deal of familiarity with the iOS sdk but not so much with the opengl related aspects and not really any with the various SDKs, especially game SDKs build to work on iOS.
If I want to create 2D games for iPhone/iPad, is it easy/better/practical to use some simple collection of iOS SDK objects such as the UIImageViews etc to build a plethora of sprites interacting on the screen, or much better to go with an SDK for that? I'm assuming that going with gl is overboard for 2d requirements, but please voice any dissent if I'm wrong there.
I'm mainly interested in what the quickest route to getting things done is, combined with the smallest requirements to ramp up on technologies. Obviously if it is well worth it to use an SDK simply because it is cross platform for other OSs, that is reasonable to mention.
The advantage of using a framework on top of OpenGL can greatly increase productivity, maintainability and reduce programming errors.
Personally I work with cocos2d-for-iphone. It's written in Objective-C and is based on top of OpenGL. It was created with the aims to create 2D games and thus unlike UIKit or QuartzCore, it's designed for that. It provides a lot of convenience API to manage scenes or sprites, to create animations, etc. Or even libraries for the sounds for example.
There is a very good article which describes some open-source game engines available on iphone here. It could help you in your search.
Related
This is a pretty basic question and doesn't really need much depth for an answer. I was just currently interested in developing an app for iPhones and after learning the swift2 language from the Mac site, i was just wondering which API I should use.
I did some moderate research, and so far spriteKit seems like the way to go (bit of a hassle if I want to port it over to android, but not impossible). But I was just wanting to make sure it's the right way to go.
The app idea revolves around keeping track of some form of progress and being able to use this data to generate graphs for the user? I'd also like to add some image functionality to the application as well. (similar to the health app and how it measures distance walked?)
I know this sounds vague, but would spriteKit be able to do these things? Or is there another API worth having a look into? (I've checked out metal and sceneKit as well, but leaning towards the more 2D type apps)
From my point of view using spritekit for this is overkill.
There are some greats frameworks to do graphs like charts :
https://github.com/danielgindi/ios-charts
Spritekit is more gaming oriented, if you want a "simple" app you don't need it.
I don't think SpriteKit is the right API to accomplish your problems.
SpriteKit is all about moving and manipulating images on the screen. I am quite familiar with the SpriteKit API.
I do not see any help for generating graphs or something like that.
Also it is not the right API to display a proper interface for "serious" apps.
I'm creating a simple Breakout style game and would like a simple way to display the score.
I've been doing some research and found several ways to do text in OpenGL ES, but most methods look fairly complicated.
This looks like it would do the trick, but I couldn't get it to work.
I've looked into FTGL and FreeType, but they look complicated.
I've also read one can display a UILabel over the EAGLContext, but not sure how that would be in the performance department.
I could probably get any of these options to work, I'm just wondering what the best solution is for this situation.
For simple use cases like you're describing, on even vaguely modern hardware (i.e. iPhone 3GS and later, I think), the compositing penalty for layering UIKit/CoreAnimation content on top of OpenGL ES content is negligible. (You can see this if you run your app in Instruments with the "Color OpenGL ES fast path blue" option turned on.)
They say premature optimization is the root of all evil — it's pretty easy to try UILabel, see if it makes a significant difference to your app's performance, and look into third-party libraries and more complicated solutions only if it does.
(Also, it sounds like you might be trying to manage your own CAEAGLLayer. For common use cases, it's a lot easier to use GLKView, plus GLKViewController for animation.)
I'd recommend checking out the Print3D functionality of the PowerVR SDK's PVRTools framework. Print3D is free to use, cross-platform (iOS, Android, Linux, Windows, OS X etc.) and it efficiently renders text within OpenGL ES 1.x, 2.0 & 3.0 applications. The SDK includes an example application with source that demonstrates how to use the Print3D framework (IntroducingPrint3D).
The PowerVR Graphics SDK can be downloaded for free from Imagination's website: http://www.imgtec.com/powervr/insider/sdkdownloads/index.asp
An overview of the source included in the SDK can be found here: http://www.imgtec.com/powervr/insider/sdkdownloads/learn_more.asp
I have an android game thats basically completed and I want to start porting it to iOS.
I'm completely foreign to objective c and I have no idea where to start. In android I have a surface view, canvas, and a game loop which draws and posts the canvas. What's the iOS equivalent?
First, be very careful of trying to transliterate between languages. You can't just pick up Java idioms and "do the same thing" on iOS in many cases. Many things are done with a completely different approach (threading is a major example; drawing is often done differently as well). You should spend some time learning the platform first or you'll get something that "almost" works and chase bugs and performance problems forever.
That said, the tool you probably want to study is Cocos2D which is a very good 3rdparty toolkit for building 2D games on iPhone. This is generally a much better approach than trying to build it up from scratch and should have a lower learning curve for game dev.
It's difficult to know how you should port without knowing the nature of your game but most iOS games are written in OpenGL which is very extendable. It has some optimization tricks that can play a big role in how you architect your rendering pipeline though.
If you decide to go with OpenGL you should check out this Stanford talk presented by NGMoco on how to do this...
http://www.youtube.com/watch?v=VNr5I3ZRecE
I am really interested in using Unity3d to develop an app.
I like the fact that I can develop once and port the app to multiple platforms (Mac/Windows/iPhone/Android), and the performance on my Mac seems to be quite good.
This will be the first time I write an app for iPhone, and I am curious about performance issues down the road. I think I will definitely use Unity3d on iPhone for a prototype, but am wondering if building an iPhone Unity3d app will use the iPhone resources as efficiently as a native app written in Objective-C.
The Unity3d site seems to suggest that Unity3d algorithms are optimized, and I thought that if I asked that question in the Unity3d forums, that would be the kind of response I would get. Ideally, I'd be interested in hearing from someone who has built an app in Unity3d and Objective-C and can compare the two.
The discussion that got me thinking about this was Andrew and Peter Mortensen's response to a question about iOS development cost, which begins "There is a much easier way to develop iPhone apps than learning Cocoa."
There are specific resources in Unity that will help with mobile development including resources, shaders, etc. that are specifically designed with mobile in mind.
You certainly won't want to take 'unoptimized' PC-quality assets and drop them into a Unity project and export that for the iOS platform as you will ensure poor/unreliable performance. What you want to do is start building out a scene using assets of similar quality to those you want for your game and then seeing what the performance is on a real device. This will give you a feel for what level of performance you can expect from your game in production.
Remember that the performance of a iPhone, iPad, iPad2, etc will vary wildly depending on what you're doing and which features you're touching. While Unity3D has been heavily optimized to deal with a variety of the scenarios, you can certainly do things like fogging which push the fill rate (a known limitation of the platform) and end up with horrendous performance.
Could you possibly get more performance out of building your application purely in Objective-C? If you have the right skillset in engine development to design a specific implementation of technology for your specific requirements - Certainly.
You just need to decide if you want to spend your time writing technology or building product. Most people who choose Unity do so because you get an exceptionally good engine which most people cannot beat the performance of (try building your own landscape engine), while at the same time getting exceptional time to market... and really its time to market that really matters in most cases.
This is an old post, but I figured I'd answer it because no one here has really got it quite right.
It's important to keep in mind that the internal core workings of Unity is entirely native. The physics engine and resultantly everything dealing with collision. The occlusion system (umbra). The entire rendering engine core. All of that is written in C/C++ and runs at full native speed on any platform. What AmitApollo says is not correct at all, the unreal engine 3 is not more direct 'native' at all when compared to unity. Both Unity and Unreal engine 3, as well as any other 3D engine like Ogre or cocos3d, their core rendering system is all written in c/c++. Some of these engines may have certain internal rendering algorithms implemented better than others, and may thus produce better performance, but this has nothing to do with whether or not they are 'native', because the internal core rendering system is native for all of them.
The internal workings of the physics engine is written in c/c++ as well, and thus the physics engine in UE3 and Unity both run at 'full native speed'.
The epicCitadel demo also does not show greater technical prowess or performance than Unity on iOS. Much of the 'visual impact' of the citadel demo comes simply from the fact that it is really good artwork. The citadel demo is not pushing any higher vertex count than what Unity could handle on iOS, the citadel demo is not demonstrating any more advanced shader or lighting techniques than what Unity can do on iOS. In fact there are more examples of Unity showing off more advanced mobile rendering techniques than what Unreal Engine 3 has demonstrated. Look at games like Shadowgun or BladeSlinger made in Unity, both these games demonstrate more advanced mobile rendering techniques than what Unreal Engine 3 has shown. Light Probes, Mobile BRDF shaders with translucency and normal mapping and well implemented dynamic mobile shadows to name a few. The vast majority of the most successful 3D games in the App store are Unity games, and Unity has thus put alot of R&D into Unity's mobile rendering performance and capabilities.
Now Unity is scripted in C# and Mono. Which does run slower than native code, about 50% slower on iOS by most estimates. But you must keep in mind that you are only doing game logic in this code. You are not writing any code in C# and Mono in Unity that deals with the working of it's internal rendering system, nor the internal workings of the physics system. You only write game logic in C#, that then interfaces with the rendering and physics core, which then executes at full native speed. Mono C# does execute slower than native C++, but if you program intelligently, I think you will find this is hardly a hindrance at all because you only do game logic in Mono C# and game logic is not necessarily CPU heavy. In my experience, it is really quite difficult to make an iPad 2 drop below 60 fps on purely game logic written in Mono C#. I have never actually been hindered by this at all.
If we are to compare to Unreal Engine 3, keep in mind that UE3 also is set up to have it's game logic programmed in a non-native language, UnrealScript. Unrealscript is a language much like Mono C# or Java, where UnrealScript is compiled down to byte code then interpreted at runtime. Meaning, just like Unity, game logic is not 'native' in UE3.
Now if you look here:
http://lua-users.org/wiki/LuaVersusUnrealScript
That is a benchmark comparing UnrealScript to C++ on a simple arithmetic operation using ints. It shows that unreal script is 1/4 to 1/20th the speed of C++.
Then have a look here:
http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
If you scroll down to the C# vs C++ Simple arithmetic benchmark. It shows Mono C# is 3/4 the speed of C++ doing simple int arithmetic. Mono C# is about 1/2 the speed when doing simple arithmetic with floats. The int64 and double benchmarks don't really mean much to us because typically you'll never use those in performance critical code in iOS game logic.
Now other benchmarks on there do show Mono C# at times having as bad as 1/20th the performance of C++. But these are through very specific tests, really the best apples to apples benchmark I could find are those simple arithmetic tests.
So really, since Unity's scripting runs on Mono C# and UE3 runs on UnrealScript. Unity is actually the engine that will offer you radically better performance in game logic code.
The notion that UE3 is any more advanced, or offers any more performance, or any greater graphical capability than Unity on iOS is simply not true. Quite the contrary is true.
Now it is true that if you used something like cocos3d you could potentially get better performance because your game logic could be written natively in C++ as well. But the benefits of working with a scripting language like c# to do game logic I think far outweighs the performance loss that is generally never an issue. Namely the benefits of using a scripting language for game logic is that it offers you faster iterations of design, which when doing games is really critical due to how quirky things can be and how frequently you have to recompile and test code.
However, in Unity, it is really easy to write native code plugins with the Pro version. So if you ever do have a piece of performance critical code that needs to run at native speed, you can write it in C++, compile it to a native library, then call that from Mono C#.
Also keep in mind if you are targeting all iOS devices the difference for heavy GPU graphics means drastic performance discrepancies between iPhone 3GS to 4, then from 4,4S to iPad2,& 3 Even certain games on the new iPhone5 or iPad4 could run at a higher FPS than it's predecessors. Keep in mind to keep poly's low, and of course in your terrain keep resolutions low, and even something as subtle as pixel error could drastically effect. Fog will always produce a strain. Textures > 512x512 may cause a problem, same with multiple light sources. It's much faster to have no light rendering, and bake the shadows and highlights. I also found that running in Native Resolution as opposed to best performance may hinder performance (Unity 4). Billboarding, Occlusion Culling are also topics you want to lookup. There is a fine line between looking good, and running slowly.
If performance is an issue to you, you may want a different engine altogether. A more Direct "native" engine like Unreal Engine 3 is amazing with it's capabilities. And it can do it without much overhead. Case and point, Epic Citadel Demo App running on an iPhone 4 or 3GS. Something comparable in Unity would be slow, and wouldn't quite look as sexy.
Perhaps its a good idea to take a look at other games made with Unity and see where yours fits in and what kind of performance you can expect.
http://www.youtube.com/watch?v=7aVttB25oPo
http://unity3d.com/gallery/game-list/
One asset that is helpful to increase performance on IOS is KGFSkyBox.
We found out, that unity3d skyboxes are using up to 6 drawcalls! This is guite a problem on devices having limits of max 30DCs!
We solved this by implementing KGFSkyBox which reduces the drawcalls to 1 if you have terrain (Hides bottom sky hemisphere). If you do not use terrain KGFSkyBox will render using 2 drawcalls which is still better than 6!
Check it out here:
http://u3d.as/4Wg
If you have any questions or suggestions just contact us here: support#kolmich.at
I have used PyGame for a while now, and quite enjoyed doing so, but only 2D experience is not going to cut it when I apply for video game jobs, and besides, I have a number of ideas I want to try out in 3D. What 3D library should I go into first? I was considering Irrlicht, which will also force me to work on my C++ again, but I was also looking towards XNA, as it would be cool to write 360 games. Any suggestions?
You can try Unity3D http://unity3d.com/. In the fall they released their engine for free that is cross platform (Mac, Win and possible Linux) and it can also be targeted for iPhone and web browser and is starting to build an open community and looks promising.
I've done some XNA stuff and the Unity tools look pretty good in comparison making it easier to get content into your games.
In my opinion, going with Irrlicht or OGRE is a good idea. It will help you get back in touch with C++ and experiment with 3D without making it too easy. It is a good idea to learn XNA as well and build a few 3D game prototypes there.
Summary: Do both, eventually. Learn OpenGL/DirectX later.
All the best.
XNA Game Studio is a fantastic framework and let's users jump into creating games quite quickly if you are comfortable with the .NET Framework.
However, if you decide that you want to move to the 3D world, you have 1 more dimension to take into consideration and it makes things exponentially harder. Simple collision detection, isn't so simple anymore. However, with the vast amount of information available for XNA Game Studio, you should find yourself getting to grips with the 3rd dimension quite quickly.
If you haven't done the whole Nehe type tutorials, it's probably best to play with the API, so that you get comfortable with it.
Create a Triangle
Spin the Triangle
Color the Triangle
Load some assets (models and textures) and render them
Try your hand at Alpha Blending
Take into consideration that XNA Game Studio does not have a fixed function pipeline and you will have to use Shaders (HLSL).
I have personally used Irrlicht, Ogre3d, Unity & Xna. Because you want to do this to help for when you apply for jobs in the game industry in my opinion I would suggest Irrlicht as you will want to work on your c++ skills. I also suggest Irrlicht as it is a 3D engine not a specific game engine which will allow you to work on your physics and maths skills as well which are highly sought after in the games industry.
I would suggest avoiding Unity if you are looking for experience to take to industry as it is a package that handles a lot for you and as such could limit your learning.
Ogre3D is a viable option as it is similar to Irlicht, maybe look into the tools available to help you make a choice between those two.
Xna is another interesting choice, it will give you a lot of chances to learn as Irrlicht could and there are a huge amount of resources to help you learn but at the same time you lose the c++ experience that comes with irrlicht.