I want to do projects to make my resume more appealing to game companies. So I am going to start buying books. But I don't know rather to read DirectX 9 or 10 api books to start off with. DirectX10 is great, but it seems the industry is moving slow to 10. so should I use 9 or go with 10 ??
I would suggest learning the basics using directx9 and then rapidly moving on to dx11. DirectX11 is harder to get started in than DirectX9 because it's slightly more complex but also a lot of the utility functions in D3DX are no longer there, or have been moved to source code like the effects framework. This is no bad thing, but it does make it signifiacantly more complex to learn as you have to learn a lot more things at once.
Spend 2 or 3 weeks learning DX9 then move to DX11 for "real" work :P
Learn basic DX9 using the fixed pipeline and d3dx for loading models etc. It's a lot simpler than DX11 and much better documented, and you'll get a triangle and then a model on screen very much faster. Play with that until you completely understand the basic concepts and tranformations.
But then rewrite it all using shaders only. You'll need to use them in DX10/11 anyway but it's a lot easier to learn when you already have a working framework of code, and it's a lot simpler to get that working in DX9.
Once you have that working, learn DX11. You'll have to switch math libraries. You'll have to invent your own model formats and loaders. You'll have to either invent your own effects framework or use the example one, but they are all much easier now you already know the basics of 3d and programming shaders.
TBH further to OneOfOne's comment if you know how to do 3D development in GL, D3D9, D3D10 or D3D11 then you can transfer those skills to any of the others with a little bit of work.
Personally I'd aim for D3D11 as that way you are learning the cutting edge. You'll find you'll be able to do GL, D3D9 or D3D10 with a little work. Do enough work on the theory and you'll discover that its not even that hard to transfer the skills to a fully software engine.
If your intention is really to learn a skill that you would use in the game industry, stick with DirectX 9. Since DirectX 10 and 11 both require Vista or Window 7, game developers are still mostly ignoring them and targeting DirectX 9 in order to have support for Windows XP.
That being said, it doesn't really matter which you start with. The differences are not that large. If you understand the concepts behind 3D APIs and how the GPU pipeline works, you can pick up any of the three or even OpenGL with minimal effort.
Fact is, you need to learn both.
As long as 50% of gamers are still on WinXP, you're going to need to be able to program in Direct3D9.
D3D9 isn't any easier to get started with than D3D10/11. Its the same principles, with vertices to be placed, normals to be calculated, and meshes to be rendered. Whether you're creating a ID3D11BlendState structure or calling IDirect3DDevice9::SetRenderState(), its the same concept, just different ways of doing it.
After working with d3d11 a couple of days, I've come to think of it as better than DX9 in a lot of ways. For one, you're able to use the full caps of the GPU including geometry shaders. 2nd, it forces you to fully understand the graphics pipeline to even draw anything (note how functions are named after the stage of the pipeline they affect: here: (IA* fcns: input-assembler stage, OM* fcns: output-merger stage etc) ). This may result in a slightly larger INITIAL startup curve, but once you get it, its not any harder than D3D9 and is better, since the very naming of the functions helps concepts stick.
So get going on both, and learning them in tandem may help reduce the amount of effort you spend learning deprecated API's/methods of doing things from DX9 (ie you really want to spend more time using shaders, and don't use the fixed function pipeline section of DX9 too much).
You can check Luna's books for DX9 /DX11(I suggest you start with 11). You can check out http://www.rastertek.com/tutdx11.html but he doesn't explain everything so you can go in Luna s book to see what is with those functions or properties
With some little exceptions, DX10 is just a legacy free DX9. For example DX9 had build in options for rendering Flatshaded, Textured or using a Shader. In DX10 these options are gone, you always have to use a real shader. If you want to do flatshading, write a HLSL shader that does flat shading.
So I would suggest you learn DX10 (or DX11). You will be able to adopt fast to DX9 but with a more modern coding style by not using legacy functions. They can be quiet confusing, so DX10 will focus you on relevant things.
If you are a real beginner, and setting up a vertex-buffer to create a single triangle is confusing you (as real 3D-Programmer you are no more interesten in single triangles) I even would suggest to start with OpenGL. You will have faster success, but in reality this can be a little bit distracting as DX9-Legacy if you want to focus on modern 3D-Coding.
Yes do not waste your time with DX10 it was never really adopted as the industry standard for any period of time, there wasn't any big enough changes to warrant people upgrading from DX9 but for DX11 there was.
I suggest directx 11, there's no reason in my opinion to waste time on deprecated functions or techniques.
Learning shaders from the start will make things way more clear
Try doing the samples from the sample folder of both 9 and 10, and if your computer can support it, 11. This is what I am doing.
Related
I saw the presentation at the High-Perf Graphics "High-Performance Software Rasterization on GPUs" and I was very impressed of the work/analysis/comparison..
http://www.highperformancegraphics.org/previous/www_2011/media/Papers/HPG2011_Papers_Laine.pdf
http://research.nvidia.com/sites/default/files/publications/laine2011hpg_paper.pdf
My background was Cuda, then I started learning OpenGL two years ago to develop the 3d interface of EMM-Check, a field-of-view-analyze program to check if a vehicle is going to fulfill a specific standard or not. essentially you load a vehicle (or different parts), then you can move it completely or separately, add mirrors/cameras, analyze the point of view and shadows for the point of view of the driver, etc..
We are dealing with some transparent elements (mainly the field of views, but also vehicle themselves might be), therefore I wrote some rough algorithm to sort on fly the elements to be rendered (at primitive level, a kind of Painter's algorithm) but of course there are cases in which it easily fails, although for most of cases is enough..
For this reason I started googling, I found many techniques, like (dual) depth peeling, A/R/K/F-buffer, ecc ecc
But it looks like all of them suffer at high resolution and/or large number of triangles..
Since we also deal with millions of triangles (up to 10 more or less), I was looking for something else and I ended up to software renderers, compared to the hw ones, they offer free programmability but they are slower..
So I wonder if it might be possible to implement something hybrid, that is using the hardware renderer for the opaque elements and the software one (cuda/opencl) for the transparent elements and then combining the two results..
Or maybe a simple (no complex visual effect required, just position, color, simple light and properly transparency) ray-tracing algorithm in cuda/opencl might be much simpler from this point of view and give us also a lot of freedom/flexibility in the future?
I did not find anything on the net regarding this... maybe is there any particular obstacle?
I would like to know every single think/tips/idea/suggestion that you have regarding this
Ps: I also found "Single Pass Depth Peeling via CUDA Rasterizer" by Liu, but the solution from the first paper seems fair faster
http://webstaff.itn.liu.se/~jonun/web/teaching/2009-TNCG13/Siggraph09/content/talks/062-liu.pdf
I might suggest that you look at OpenRL, which will let you have hardware-accelerated raytracing?
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 at a crossroads between using OpenGL ES 1.1 and 2.0 for iPhone development. I plan on creating 2D applications and simple 3D applications. In the interest of simplicity, should I use 1.1? Or will this be discontinued at some point in iOS? I would like to know if the shaders in 2.0 are significantly more beneficial in making simple programs than the shaders in 1.1. Please tell me the advantages of each. Thanks.
I would say the definitive reason the use 2.0 starting out is complex effects, 2.0 is a wild card in this matter, shaders are little bits of software that run inside the graphics card (ok, not always true) and have the ability to affect individual pixels at run time. In 1.1 there's a lot you can do, but most of the time you're affecting all the pixels in the texture, to affect individual pixels, you have to combine textures, and the after a while there's just stuff you can't do in 1.1.
Now if you don't need complex effects, you can start and use 1.1, but let me show you your journey:
In the beginning 1.1 will be easier, glTranslatef, glRotatef, glScalef, etc do save you time and allow you to start manipulating objects easily.
But has you progress and start to do more complex things, you learn about matrix manipulations, say there's a routine that's a bit slow because you're doing a lot of tranlastes, rotates, etc. So you read up on the subject and learn you can combine all those operations into one matrix, so you start doing your own matrix calc funcs and start to use glMultMatrixf more, after a while it's just easier to always glMultMatrixf, because you can latter add stuff without having to rewrite code.
At this point you have no reason to use 1.1, going from glMultMatrixf to 2.0 is a very small step, and you get that whole new world from the shaders.
So, if you don't need big effects and are itching to go, alright use 1.1.
Anything else just go direct to 2.0.
Disclaimer
Yes this is a simplification, but a journey i've made myself.
2.0 has a programmable pipeline
This seems like not very much information (as when i first started i was like "uh ok?") but it really means a lot.
In allowing you to take control of the transformations of vertices
Now in the smaller things I have done (3d) the transformations could easily be managed by 1.1 automatically, but it is cool to have total control over them in 2.0
If you're learning opengles on the idevices i suggest making programs at first that support both 1.1 and 2.0 so you can get even more experience and understanding into opengles
If you need full control over the vertices then 2.0 is the way to go, otherwise 1.1 should be fine
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.