I need to render video from multiple IP cameras into several controls within the client application.
On top of the video, I should be able to add some OSD such as timestamp and camera name.
What I'm trying to do has nothing to do with 3D since we're talking about digital video with some text on it.
Which API is more suitable for this purpose? Direct3D or Direct2D?
Performance should also be a consideration here.
It used to be that Direct2D was a poor choice for Windows Phone (if you care about that system) because it wasn't supported, but Win Phone 8.1 has it now, so less of an issue.
My experience with D2D was that it offered fast, high quality 2D rendering, and I would say it is a good choice.
You might want to take a look at this article on Code Project. That looks appropriate for your purposes.
If you are certain you only need MS system support, then you're all set.
Another way to go would be a cross platform system like nanovg, which offers nice 2D rendering and would work on a Mac. Of course, you'd need to figure out how to do the video part on non windows systems.
Regarding D3D, you could certainly do it that way, but my guess would be it would make some things trickier to do. Don't forget you can combine the two as well...
Let's say I wanted to develop interface like in Smule (iPhone flute app).
Youtube linke to Smule
What sort of Frameworks I should consider using. Should I stick to native frameworks in iOS such as CoreAnimation, OpenGL ES or, are there any third party framework which makes job easier ?
thanks.
Waruna.
This depends on so many parameters... there are so many options...
Just some questions to get you started:
What are your skills? (Comfortable with OpenGL? What about Objective-C?)
What is your budget? (Money for proprietary frameworks? Time to do low level stuff?)
Is performance an issue? (For smule apparently it is not.)
With a scripting framework like Pythonista this could probably be achieved in half a day and under a hundred lines of code with decent performance... if it would support input from the mic...
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.
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 am working on BlackBerry user interface. But the BlackBerry UIs are less attractive compared to Android UI. I want to make my BlackBerry UI more attractive like in Android.
#Dave Markle is right, this is a fairly general question. Assuming that by 'attractive' you mean 'UI Controls that look better than the default' then you'll have to do a lot of custom control work. More an more in the BlackBerry industry it seems that leading applications are doing almost entirely custom UIs.
I won't touch on specifics of graphic design, that seems outside the scope of SO, but a good place to start is to get a graphics designer to put together some conceptual screens, and then as a developer your job will be to build controls to match that.
There are some tutorials on the net about how to get started with that. I've written a few - "BlackBerry UI - A simple custom field" is a good basic introduction on how to make a custom control.
And a correction to #Dave's comment - you can antialias text on the BlackBerry - though it's not well documented. For example, a 9 pt subpixel antialiased bold font, derived from the default system font:
Font.getDefault().derive(Font.BOLD, 9 Ui.UNITS_pt, Font.ANTIALIAS_SUBPIXEL, 0);
Well, after a couple of beers a lot of things look more attractive... ;-)
But seriously, I think you're going to run into some fundamental limitations with the platform you have. The iPhone, Pre, and (I guess?) the Android all have dedicated graphics hardware which can antialias text and perform complex animations with relative ease. Most blackberries don't.
I generally suggest to people that when they do a design, that they try to stay within the boundaries of the device they're designing for. For example, if you're writing an app for Windows XP, don't try to make it look like it might on a Mac. Stay with the style of the best-of-breed applications on the particular platform you're designing for. Maybe this answer isn't helpful, I don't know... But it was a pretty general question.