I am attempting to create a 2D game using DirectX 10. I've been having lots of problems with figuring out how to actually get started to create such a thing. I've discovered mixed ideas, such as just use shaders and stick with Direct3D and I've seen some people using libraries such as SFML. I am rather new to DirectX, and am wondering what I should be using to create a 2D game (shaders or a library). Are shaders something that I should look into, or should I just use a library?
Well if you are interested in learning DirectX itself, you should try to write your own 2D engine, which with a little experience isn't as hard as it may seem. But if you want to get straight to game developement, you can take a look at some engines that take care of that part. Shaders can really enhance scenes (3D as well as 2D) and if I were you, I would definitely use them, instead of just using simple unprocessed textures. Most engines won't take the shader programming from you, so you will probably need to look into hlsl anyway.
Also what I experienced with several engines and librarys: at some point they will come to an end, and if you are enthousiastic about your project, you don't want to live with those limitations. That's why I would recommend writing your own engine which you can easily expand as needed.
A good starting point for pure DirectX:
http://www.rastertek.com/tutdx10.html (Mainly for 3D but also covers 2D, which you will notice isn't that different)
Related
I am reading through the OpenGL Superbible Fifth Edition and they discuss using stacks via their own class. That's all great but they mention that matrix stacks were deprecated. Why were they deprecated and what do people use instead of them?
The reason(s) are political, not technical, and date back to the early 2000s.
OpenGL 3 was the first ever version willing to break backwards compatibility. The designers wanted to create an API for the expert users, the game programmers and high end visualization coders who knew all about shaders and wrote their own matrix code. The intent was that the OpenGL 3 API should match the actual hardware quite closely. (Even in OpenGL 1/2, the matrix stack was usually implemented on the CPU side, not the GPU.)
From a game engine programmer point of view, this was better. And hey, if you have to develop a new game engine every couple of years anyway, what's the big deal about throwing away the old code?
The result of this design process is the OpenGL 3/4 core profile.
Once the "new generation" OpenGL was announced, all the not-so-expert coders in universities and companies realized they would be screwed. These are the people (like me) who teach 3D graphics or write utility programs for research or design. We don't need any more advanced lighting than plain ambient-diffuse-specular. We often have to mix code from different sources together, and that is only easy if everyone is using exactly the same matrix, lighting, and texturing conventions - like those supplied by OpenGL 2.
Also, I've heard but cannot verify, the big CAD/CAM companies realized that they'd be screwed as well. Throwing away two million lines of code from ten years of development is not an option when you've got paying (and well-paying: compare prices for Quadro vs GeForce, or FireGL vs Radeon) customers.
So both NVIDIA and ATI announced they'd support the old API for as long as they could.
The result of this pressure is the compatibility profiles. And the OpenGL ARB now seems to have realized that while they'd like everyone to switch to core profile it just isn't going to happen: read the extension spec for tessellation shaders in OpenGL 4 and it mentions that GL_PATCHES will work with glBegin.
Matrix Stack (and the rest of matrix functions) were deprecated only in the core profile. In the Compatibility profile you should still be able to use them.
From my point of view it was removed because most of engines/frameworks have custom Math code and shader uniform style for sending matrices to shaders.
Although for simple programs/tutorials it is very inconvenient to use and search for something else.
I suggest using:
glm (http://glm.g-truc.net/)
very simple math lib (vsml)
Why were they deprecated
Because nobody actually used it in real world OpenGL programs. Take a physics simulation for example: You'd have all the object placement being stored in the physics system as a 4×4 matrix anyway. So you'd just use that. Same goes for visible object determination and animation systems. All those need to implement the matrix math anyway, so having this in OpenGL is rather redundant, as most of the time the already existing matrices were simply put into glLoadMatrix.
and what do people use instead of them?
What they used before: Their animation systems, physics simulators, scene graphs, etc.
Well the first and main reason, for me, is that with the rise of programmable shaders (being mandatory after the 3rd version of opengl), all the variables such as GL_PROJECTION and GL_MODELVIEW that were automatically transferred to the shaders are being deleted from the shaders, so the user has to define its own matrix to use it in the shader. Since you have to send the matrix manually using the Uniform functions, you don't really need fixed variables anymore.
I'm new to graphics programming and I'm wondering why I would ever prefer GDI over the hardware accelerated graphics of DirectX/OpenGL?
Are there still good reasons to use GDI?
It ultimately comes down to what you need. If you just need non-real time 2D graphics, GDI will do exactly what you need.
On the other hand, DirectX and OpenGL take much more work to use and manage (and typically use more system resources), although they allow faster drawing, and 3D.
Remember, keep it simple, you don't need a full 3D system to draw a couple of circles!
I'm learning OpenGL and really like to know how the interaction with the Graphics card will be.
I feel understanding how it was implemented in the Graphics driver, will let me know complete internals of the opengl(With this I can know what stages/factors influence my decisions regarding performance in opengl).
Are there any ways for this path to proceed.Does exploring the 'Mesa lib' will help me in this aspect? Am I in the right path?
There's an excellent 10 part series explaining exactly this that you can find at the ryg blog. http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/ It's explained in terms of DirectX, but both API's are handled quite similar by the actual driver.
Still one of the best articles that describes the performance characteristics of actual hardware is the GPU Gems 2 article http://developer.nvidia.com/node/52. The article itself is a couple of years old, but it will definitely increase your awareness of the problem space. Also, studying the NVIDIA bindless graphics extensions ( http://developer.nvidia.com/content/bindless-graphics ) will give you some extra insight, if you understand why it speeds things up. Also, the "Batch batch batch" presentation is a classic on CPU/GPU interaction optimization ( http://www.nvidia.de/docs/IO/8230/BatchBatchBatch.pdf ).
But, I feel obliged to get back to the original question. Ask yourself which comes first : knowing how to program C++, or knowing the internals of GCC. There's good reason almostopen everyone treats the 3d api as a black box. Drivers are different (API/NVIDIA) depending on the hardware, and performance characteristics doubly so. I really recommend you to just start hammering out some OpenGL code, and learn by optimizing your code. You can either do a small technique (like parallax occlusion), or, probably better, write a whole scene with with different kinds of dynamic lights, shadows, deferred rendering and post processing. And then set a couple of weeks aside for optimizing just that and see how far you can get.
Optimizing 3d rendering really is a bit of a black art, and there are very little "true in every case" answers. The best way to learn is by hard won experience.
These guidelines are probably as close as anyone can get:
use LOD extensively ( meshes, textures and shaders)
try to keep your draw count as low as possible
try and keep your intermediate buffers as small as possible (count and size) for deferred rendering
try and do some rendering in half resolution (eg particles and postprocessing)
always prefer arithmetic before texture access in shaders
always keep in mind that "looks good" trumps "is correct"
prefer algorithmic optimization before low-level optimizations
You will have a hard time trying to understand the internals of an OpenGL driver (state tracker in Mesa/Gallium terminology) without being intimate with the OpenGL API.
OpenGL itself is defined in terms of an abstract graphics machine and actually its much easier to understand OpenGL from this vantage point, than trying to do it through the driver.
Looking at a driver's source code will surely help you to understand any bottlenecks associated with this particular driver. And of course it helps seeing the patterns in other drivers. But it helps a lot more to read the technical documents about the GPUs' architectures.
I came across a very interesting book. I have done some 2d games but 3D is a whole new ballpark for me. I just need to know if there any benefits of learning 3d software rasterization & theory before jumping into OpenGL/Direct3D? Any reason why to either approach? Thanks in advance!
It is handy stuff to know, but largely unnecessary for learning OpenGL or Direct3D. It might be (marginally) more useful when getting into pixel shaders.
if there any benefits of learning 3d software rasterization
You'll get deeper understanding of internal working of 3D apis.
I think that if you're serious about working with 3D, you should be able to write CSG raytracer, software rasterizer with texture mapping support, know a few related algorithms. Or AT LEAST you should have knowledge that would allow you to write those if you wanted.
Francis Hill's book "Computer Graphics using OpenGL" had a few chapters about writing raytracer and combining software rasterization with OpenGL-rendered scene, which is definitely something you have to read.
Without that knowledge you'll screw up when you'll have to write a tool that HAVE to calculate something in software mode. Classic example of such tool is radiosity/lightmap calculation, raytracing, and so on. Some of those tasks can be accelerated by GPU, but GPU won't magically handle everything for you, and you'll have to deal with code VERY similar to standard software rasterization.
I would skip the rasterization theory. Most of the tricky parts are fixed in current GPU, so when you move on to hardware accelerated graphics, you won't be able to apply your knowledge.
If you first learn about rasterization theory, you will probably have a better understanding of why it is useful to specify things such as pixel center coordinates and why there's a difference between the way D3D9, D3D10 and OpenGL handle it, but at the end of the day it doesn't really matter for most developers. Try the other way: Learn the APIs first and whenever you step over some weird specification, try to find a rationale in rasterization theory.
Unnecessary. Good tutorials will tell you everything you need to know to use the relevant technology. The fact is that if everyone needed a doctorate in rasterization theory before they could use OGL/D3D, there'd be way, way less OGL/D3D games than there are.
I learned it (wrote software rasterizer) and am extremally happy with that - this is much more helpfull I would say for doing open gl tahan for example knowing assembly tocode in c - it is extremally helpful to get understanding of things and feeling that everything is possible is possible
Does anyone have some useful beginner tutorials and code snippets for playing with basic geometric shapes and geometric proofs in code?
In particular something with the ability to easily create functions and recursively draw them on the screen. Additional requirements, but not absolute, support for Objective-C and basic window drawing routines for OS X and Cocoa.
A specific question how would one write a test to validate that a shape is in fact a square, triangle, etc. The idea being that you could draw a bunch of shapes, fit them together and test and analyze the emergent shape that arises from the set of sub shapes.
This is not a homework question. I am not in school. Just wanted to experiment with drawing code and geometry. And looking for an accessible way to play and experiment with shapes and geometry programming.
I am open to Java and Processing, or Actionscript/Haxe and Flash but would also like to use Objective C and Xcode to build projects as well.
What I am looking for are some clear tutorials to get me started down the path.
Some specific applications include clear examples of how to display for example parts of a Cantor Set, Mandelbrot Set, Julia set, etc...
One aside, I was reading on Wikipedia about the "Russell's Paradox". And the wiki article stated:
Let us call a set "abnormal" if it is
a member of itself, and "normal"
otherwise. For example, take the set
of all squares. That set is not itself
a square, and therefore is not a
member of the set of all squares. So
it is "normal". On the other hand, if
we take the complementary set that
contains all non-squares, that set is
itself not a square and so should be
one of its own members. It is
"abnormal".
The point about squares seems intuitively wrong to me. All the squares added together seem to imply a larger square. Obviously I get the larger paradox about sets. But what I am curious about is playing around with shapes in code and analyzing them empirically in code. So for example a potential routine might be draw four squares, put them together with no space between them, and analyze the dimensions and properties of the new shape that they make.
Perhaps even allowing free hand drawing with a mouse. But for now just drawing in code is fine.
If you're willing to use C++ I would recommend two libraries:
boost::GGL generic geometry library handles lots of geometric primitives such as polygons, lines, points, and so forth. It's still pretty new, but I have a feeling that it's going to be huge when it's officially added into boost.
CGAL, the Computational Geometry Algorithms Library: this thing is huge, and will do almost anything you'll ever need for geometry programming. It has very nice bindings for Qt as well if you're interested in doing some graphical stuff.
I guess OpenGL might not be the best starting point for this. It's quite low-level, and you will have to fight with unexpected behavior and actual driver issues. If you emphasize the "playing" part, go for Processing. It's a programming environment specifically designed to play with computer graphics.
However, if you really want to take the shape testing path, an in-depth study of computer vision algorithms in inevitable. On the other hand, if you just want to compare your shapes to a reference image, without rotation, scaling, or other distortions, the Visual Difference Predictor library might help you.
I highly recommend NeHe for any beginner OpenGL programmer, once you complete the first few tutorials you should be able to have fun with geometry any way you want.
Hope that helps