Racoonacoon

Hey Migi0027,

 

The semantic does exist. It exists for the pixel shader.

You could write the pixel shader like this if you wanted:

float4 PShader(float4 color : COLOR) : SV_TARGET
{
    return color;
} 

 

The SV_POSITION semantic exists for the non-programmable rasterization stage.

Hiya Ckosmoe!

I started getting into game development when I was 14 too! I remember I didn't have internet at the time, so I would go to the library and browse various game dev websites and forums on their blazing fast 56Kbps modem Anyway, as others have said, there is a good bit to game development, but if you take your time and enjoy the process everything will fall into place. The best place to start, imo, is by using some sort of game engine. For me it was RPGToolkit2.0. A game engine will help you understand the whole picture more clearly and allow you to actually gain the experience of developing games without being burdened by a whole bunch of technicalities. At least, that's how things worked out for me. I think I was in seventh grade when I finished my first game with RPGToolkit. It involved my English Teacher trying to take over the world, and you had to defeat her via a turn-based RPG battle system. It was full of in-jokes, badly photoshopped images, and very simple graphics, and it was an absolute blast to make.

That was ten years ago, so I'm not really sure if RPGToolkit has kept up with the times. You may want to check out GameMakerif RPGToolkit doesn't work out for you. Just remember: Take your time, read/watch many tutorials, and enjoy yourself.

As far as a career path, you have a fairly wide range of choices when it comes to actually making money and supporting your future self. A few people here seemed to assume work at a traditional game studio, but it is also possible to develop games as an independent (indie.) Given that you want to design, compose, and draw your own game, the indie route may be more of what you are after. As an indie you come up with the ideas and you develop the game from start to finish. It's much more flavorful, if you will, because you get to do everything. You design for a while, and the program for a while, and then draw for a bit, and then do some sound design, etc. It is very difficult for life to become dull when you are a true indie. You can also take on work as a Freelancer and work from home...that's what I ended up doing. There are many clients on oDeskand Elancethat need a game engineer who knows their stuff. You often don't need a college degree when you work as Freelancer either. As long as you have a portfolio that displays your awesome skillz you have a very good chance of landing a well-paying job.

Best of luck!

Hiya shadowbreaker,

 

I'm not all that familiar with the fixed-function pipeline of DirectX 9, so I can't offer much assistance on the issue you are having. What I would like to ask though, is why you are beginning your foray into DirectX with DirectX9, and futhermore, why you chose to use the fixed-function pipeline. The fixed-function pipeline is going the way of the dinosaur (one may argue that it is there already) so it likely not the best investment of your time to learn it. Furthermore  there are a great number of differences between DirectX9 and 10/11, so you will have to do a good deal of relearning if you want to move to the newest stuff.

 

Perhaps your goal is to learn the fixed-function pipeline for experience sake and then move on, and if so, then have fun! But you also said you are just beginning, which makes me wonder if you are accidentally starting down a potentially wrong path that will sap you of the time you could be spending learning the better way of doing things.

Hey LastUser,

 

What I typically do is draw the game onto a render target that has a set size (such as 1920 x 1080) and then apply a scaling matrix with letterboxing to get it to fit on the user's resolution. The advantage of this is that it is pretty easy to do and it looks good, but the downside is that you are always rendering to a potentially large render target when the user may have a much lower resolution.

 

Another option is to draw more or less of your game depending on the resolution the game is running at. The disadvantage of this method is that it may change the gameplay mechanics somewhat. For example, if the user played your game with a huge resolution they would be able to see much more of the world, which may enable them to spot enemies and such, while someone running your game on a low resolution would get a much narrower view.

After 2 hours of despair I decided that I'd try going to C++ and Direct X (I used them at school so I have some idea of what I'm doing).  From what I've ready I can't do that with the new version of VSE; I have to pay to upgrade which I refuse to do unless I started actually making money from my hobby.

 

You don't need the Pro edition to do DirectX development. You only need the pro if you want all the new fancy game dev specific features that VS 2012 offers, but you can use the express without these additions just fine. I'm currently using Visual Studio Express for Windows 8 to develop a DirectX game and everything works great.

 

As others have already mentioned, you should definitely check out MonoGame.

Hiya Scoots,

 

Out of curiosity, do you have any platform in mind? By platform I mean devices, like a Windows Desktop or a Android Tablet, or the iPad, etc. Each device has their own little ways of doing things. For example, the Java programming language is considered the standard for Android based devices, where as the Apple devices primarily use a language called Objective-C. The Metro side of Windows 8 makes use of JavaScript, C#, or C++ depending on what type of application you plan on targeting, where as the 'good ol desktop' is pretty much open to whatever programming language you feel like using. I'm asking this because if you have a particular goal in mind then it may shape what you want to start learning.

 

Anyway, 'how do I start making games' is a surprisingly heavy question. There is bunch of stuff that a person must learn before they can really start making a game, and it is sometimes difficult to maintain the patience to learn all of the things correctly. After you have the platform in mind the next step is to start learning a programming language. You mentioned C++, but it might be a good idea to start with something a little less involved and gradually work your way up, or, who knows, perhaps you will find that you don't even need to move to C++ to meet your goals. C++ is complicated, but it isn't just the language that is complicated. Setting up the compiler/linker/IDE is much more involved than say, Python or C#, in which these extra steps pretty much don't exist.

 

A handy thing about programming languages is that the concepts learned in one have a very high level of transferability. If you play around with Python for a couple of months, it will be much easier for you to get the hang of any other language out there. The way the program looks aesthetically (called syntax) may vary from language to language, but the underlying concepts invariably are the same. This means once you get the hang of Python you could jump to a language that more closely resembles C, such as Java or C#. Then once you have the syntax down you could jump to C++.

 

A thing worth noting is that, depending on the platform, C++ is not required to make games. For an absolute beginner, it may be best to go with Python and Pygame. Pygame has a few tutorials on their website you could take a look at, but, as Bacterius mentioned, the first thing you will want to do is get a solid feel for the language you are using. Python, unlike C++, requires almost zero setup (you download and run an installer) and thus it is much more beginner friendly. Pygame is nice because it offers a gentle introduction into game development. Most of the annoying cruft is cut out, so you can focus on learning and experimenting instead of focusing on memory leaks and bizarre pointer issues.

 

Microsofts XNA or the open source MonoGame may also be a good starting point, but they are slightly more involved. It may actually be good to start with PyGame, and, once comfortable, move to XNA. XNA would introduce you to shaders and reveal a bit more of the 'metal' without getting too 'metaly.' I got my start with XNA and C#. It was pretty tough, but it was also so much easier than trying to tackle C++ and raw DirectX. I can't even imagine trying to do that without some bit of previous knowledge. C# & XNA was a great stepping stone.

 

Anyway, if you decide to start with C# or C++ you will want to download a thing called an Integrated Development Environment (IDE.) An IDE is pretty much a glorified text editor married to a complier that makes programming significantly faster and more pleasurable. For Windows I recommend Visual Studio. And it's free too ( at least the Express edition ) so there should be no barrier to playing around with it.

 

 

You also asked if you had to use an engine. The answer is no, you dont, but, depending on what you enjoy doing and how your mind works, you may enjoy working with an existing game engine over building your own. My mind enjoys the engineering, so I naturally shy away from Game Engines and build my own for the fun and experience. But perhaps you are the type who wants to make games more than write code. If you are that type than Game Engines are nice, but, as with programming, there is an unfortunately steep learning curve. Some Game Engines don't require you to know any sort of programming language, such as GameMaker (it uses a drag and drop event system, though it can be a bit challenging at times to achieve the behaviour you want.) It is also worth noting that many, but not all, game engines require you to purchase a software license to use them to their full potential, so that is something to keep in mind if you are strapped for cash.

In addition to IndieCity, you may also want to look at Indievaniaand Desura.

I do not know much about the subject, but from what I can tell that bear fighting game I linked appears to be straight 2D without anything 3D-accelerated.

 

Given that Fist of Awesome runs on OUYA, iOS, and Android, it's safe to assume that everything is rendered using OpenGL ES. You can't (visually) tell the difference between drawing the individual pixels using something like GDI+ vs drawing textured quads using OGL or DX. They look exactly the same. Either one can be 'purely 2D.' It's just a matter of setting up the states/shaders to get things to look they way you want it. Take the below screenshot from a game a friend and I worked on for example:

 

Everything is drawn using DirectX 9 (to be more accurate, it uses a wrapper around it called XNA.) Basically you create a bunch of textured squares ( called quads ) send those to the GPU and they pop up on the screen. The projection matrices are set up so that everything is projected into 2D space; there is no 3D.

 

So, OGL and DX are not 3D specific. They are more like this generic blob that can do whatever you ask them to do (more or less.) You want 2D? Great, build yourself a shader and set up the correct matrices and you got it. 3D? Same story, create your shaders, set you states, read a couple math books and you are good to go.

 

Hey Jeffy,

 

You can use DirectX and OpenGL for 2D games as well. It's just a matter of setting up the right states and shaders to get things the way you want them. Most 2D games you see today are using either DirectX or OpenGL in some way to do their rendering. Getting started with either of these APIs is challenging though, simply due to the huge amount of things you have to learn at once before you can do anything useful. I remember when I was first getting started with DirectX 10 that it took me days before I had a simple triangle drawing on the screen.

 

So, that said, it is probably best to start at some intermediary and work your way up. That a way you can learn as you go and actually have fun instead of being overwhelmed by a bunch of stuff at once. As others have said, you may want to check out SDLor SFMLfor window creation and sprite drawing to get you started. Even if you are planning on learning the hard-core stuff such as OpenGL or DX I recommend using these libraries to take care of all the boilerplate code such as window creation and texture loading.

 

You may want to check this out at some point. It is a great tutorial series (or book really) that covers modern OpenGL. It is scary how many old fixed function tuts are still floating about...you want to avoid those, as they will do you disservice in the long run. The great thing about learning graphics programming is that the skills are easily transferable. If you know DirectX you can pick up on OpenGL fairly easily, and vise-versa.

 

 

The above is for if you want to do actual programming and learn the underlying concepts behind graphics programming. If you are more interested in creating a game right off the bat you may want to take a look at a 2D Game Engine such as GameMaker by YoYo Games. I've used GameMaker in the past and I found it to be a nice little engine. I've used Torque2D as well, but for some reason or the other I couldn't really get into it. I think I just didn't like the scripting language all that well. I would avoid Unity if you are only interested in 2D at the moment, because it is clunky to use for 2D development.

Yo zonozz,

 

From what I can remember, it is illegal in HLSL to pass the Position semantic to the pixel shader, at least in DirectX 9. Try creating a VS_OUTPUT that has a TEXCOORD semantic in addition to the POSITION semantic. Then, in your vertex shader, write the value of the position to both of the semantics. Have your PS_INPUT semantic read the TEXCOORD but not the position.

 

Something like this:

 

struct VS_OUTPUT

{

      float4 position : POSITION0;

      float4 pixelShaderPos : TEXCOORD1;

      float3 normal  : NORMAL0;

};

 

struct PS_INPUT

{

      float4 pixelShaderPos : TEXCOORD1;

      float3 normal  : NORMAL0;

};

I recommend looking into Assimp.

I'm somewhat curious how your Quad2D method is handling things under the hood. Is it buffering the sprites and then drawing them in all one big draw call, sorting them by texture, or does each call set the texture, vertex buffers, IA Layout, shaders, etc? If it is the latter then it is likely to not be all that efficient. You may want to look into mimicking the way SpriteBatch in XNA handles things. You tell it to Begin() and then you do a number of Draw() calls. When you are finished you say End(), which draws all the sprites in one go. This approach is generally more efficient.

 

As for me, I store all my sprites as points in a dynamic vertex buffer and expand them to quads in the Geometry shader. This makes managing the vertex buffers on the C side much easier.

The end goal of my project is to have two sprites moving around the screen, one separate clients controlled by a server. Right now, I just want my server to tell me which key I am sending it. As of now, all I get is:

 

Received a broadcast from 192.168.x.xxx:59145

Message: NONE

 

I just realized this. My derp.

You have a logical error in this if statement:

if (!keyboardState.IsKeyDown(Keys.W) || !keyboardState.IsKeyDown(Keys.A) || !keyboardState.IsKeyDown(Keys.S) || !keyboardState.IsKeyDown(Keys.D))

 

You are saying, if the W is not down or A is not down or S is not down or D is not down, then say we are not moving. You likely want this to be AND. If W And A And S And D are not down THEN send None. As it is now you will have to press WASD all at once to get something other than NONE to be sent.

 

 

The main problem though:

KeyboardState keyboardState = new KeyboardState();

should be

KeyboardState keyboardState = Keyboard.GetState();