Request a tutorial.

  • (5 Pages)
  • +
  • « First
  • 3
  • 4
  • 5

64 Replies - 58047 Views - Last Post: 22 April 2016 - 01:43 AM

#61 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 779
  • View blog
  • Posts: 1,871
  • Joined: 24-April 12

Re: Request a tutorial.

Posted 14 September 2015 - 03:34 PM

Welcome to the forum!

I recommend checking out the Tutorials section for game programming tutorials here. You might start with this one

http://www.dreaminco...s-and-textures/

If you are fairly comfortable in C#, XNA is pretty easy. XNA is different than Unity in the way it works, substantially different.

You probably want to start with more simple tasks first, rather than jumping into doing a 2D platformer for your first project. Start by learning to draw a few sprites on the screen. Then learn how to move them using the keyboard or game controller. Then learn about the different types of collision detection. Learn about sprite batches and animating sprites using them.

You can probably find tutorials for XNA 4.0 or MonoGame on YouTube for 2D side scrolling platformers when you're ready.

Also, you can check out my stuff at VirtuallyProgramming.com although I only have a couple of things that are not 3D, but there's a lot of XNA stuff. Also, in my links section I have a link to RB Whitaker's website and he does a lot of 2D XNA stuff that you should definately check out.

Basically the way XNA works is that you select a template to create your program under File=>New=>Project and select "Windows Game" for a game that runs on Windows. The template will create a bunch of stuff for you. It will create a Program.cs file that you normally don't have to mess with at all. And it will create a Game1.cs file which is where you will write your code. You can call your own .cs files from Game1 if you like.

There are also two projects created. One is your main project where the cs files I just mentioned are at. But the other is a Content project where you need to add any textures for sprites and other art files such as sound files. XNA will compile the art files in the Content project into its own internal format (.XNB) automatically.

If you look through Game1.cs you will see several methods/functions that you are expected to change in order to make your game. The Initialize() method is where you put any code you want to run when the game first starts other than loading art assets. The next method is the LoadContent() method which will also run once at startup, but it is mainly for loading your art assets like the textures for your sprites and sound files and 3D models. The UnloadContent() method is where you remove art assets from memory, but I've never seen anyone use it for anything other than one time. So, basically forget about it for now.

After that, the game loop starts running. As I explained in my "Learning 3D Game Programming" road map post, the game loop is much like old film cameras. You can read that post for more detail, but basically roughly 60 times per second it goes through this loop.

One pass through the loop is called a "frame". The Update() method is where you put all your game code. This gets called by the loop every frame or about 60 times per second. Basically, all your code that doesn't draw stuff to the screen goes here or is called from here. The Draw() method is also called every frame or roughly 60 times per second.

In the Draw() method, you are drawing one screen or one "frame". If you've ever seen those flip books where you flip through the pages to do animation, that's basically what you're doing here; you're drawing one screen and then the next time the loop calls the Draw() method you will draw the next screen. And if you slowly change things between frames, the person watching the screen will think they are seeing animation. It will create the illusion that things are moving. You're really drawing still images, but by drawing them 60 times a second, any changes will appear as animation.

Draw() and Update() work very closely together. Update() is where you have all the code that changes everything every frame. And Draw() is where you have all the code to draw the current scene, or frame of the scene.

XNA is very "open ended". It doesn't do much of anything for you the way Unity does. And you can mostly do things the way you choose to do them.
Was This Post Helpful? 0
  • +
  • -

#62 AlbinoPopstar  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 4
  • Joined: 15-April 16

Re: Request a tutorial.

Posted 15 April 2016 - 07:50 PM

Hello everybody! I'm new, so please take care of me.

I am a beginner who has some experience with programming but very little with XNA.

I'm using XNA because I want to make a 2D physics engine, something along the lines of this video. I tried using C++ and DirectX first, but found it quite difficult to even draw a triangle. So I decided on XNA and it's worked out quite well so far, since I was able to make a very simple platformer using this tutorial. Well, it all went fine and dandy, and I figured once I knew how to make a platformer, a physics engine was just a few steps away. Oh boy! Well, I've been on a journey for the past week, where I've come up with very interesting things and found out about many other interesting things.

Here's a picture of one interesting thing:

Posted Image


I'll give a basic run-down of the image for those interested, it's actually pretty cool. This image pertains to the rotational velocity of a square depending on where a force acts upon it. The shaded triangles represent how fast the square would rotate if a force acted on a certain point (you can see this follows a pattern). The dotted lines represent asymptotes where an acting force would produce no rotation and instead move the square in that linear direction.

I got very obsessed with rotation because I couldn't find a way to use the rectangle collision bound box as a way to make the object rotate.

Well, I know very little about XNA as I've said before, and so I'm still looking for tutorials and resources. I'm hoping someone can either help me with my project or give me a book or pdf that goes over everything in XNA 4.0 (like a general reference guide with an introduction and everything, a la "The C Programming Language").

Thank you for your help in advance!


P.S. Right now I'm looking for a way to draw polygons with local coordinates where the center of mass would be point (0,0) and the edges and vertices would all be defined in the polygon's local coordinate system. This would allow for an easy way to define rotation upon collision, but maybe there's a better way I haven't thought of yet.
Was This Post Helpful? 0
  • +
  • -

#63 AlbinoPopstar  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 4
  • Joined: 15-April 16

Re: Request a tutorial.

Posted 17 April 2016 - 12:24 AM

Whoops, just found out XNA is dead and its MonoGame now.

Apologies, carry on then.
Was This Post Helpful? 0
  • +
  • -

#64 SixOfEleven  Icon User is offline

  • Against the Grain
  • member icon

Reputation: 976
  • View blog
  • Posts: 6,430
  • Joined: 18-October 08

Re: Request a tutorial.

Posted 18 April 2016 - 02:01 AM

While XNA is no longer in development it is still a good framework. XNA/MonoGame are very similar. What worked well in XNA is pretty close to the same in MonoGame. XNA is still a useful tool so keep working with it. Once you think you're done with XNA them move to MonoGame and apply your knowledge there. There is a tutorial here on drawing primitives http://www.dreaminco...rectangle-etc/. It might be useful for drawing more general polygons. Here is also a tutorial on 2D collision detection that discusses rotation, scaling, etc. http://xbox.create.m...xel_transformed
Was This Post Helpful? 0
  • +
  • -

#65 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 779
  • View blog
  • Posts: 1,871
  • Joined: 24-April 12

Re: Request a tutorial.

Posted 22 April 2016 - 01:43 AM

I still tend to think of it as XNA, although maybe it's time to go to Monogame. A lot of the tutorials and almost all the books were written for XNA. The XNA 3.1 books were the best and it's so radically different from 4.0 for 3D that you almost have to treat them as two completely different frameworks. It's very difficult for beginners to translate between one and the other. Most of that affects 3D alot more than 2D though I believe. MonoGame is basically XNA 4.0 but they've improved it and had to make some changes to make it multi-platform.

I miss it. I have been thinking about doing some XNA projects the past few days. Instead I'm trying to get back into learning OpenGL which I expect is far more complicated. I figured out how to do DX11, but it's almost time to learn DX12 if I'm going to continue down the DX path. (I do almost exclusively 3D.)

Anyway, I did a fun little tutorial (at least I had fun with it) that is very closely related to what you are talking about years ago. It's two pages and the better part is on the second page, which is almost hidden (on accident) the way I wrote it.

But I got interested in trying to figure out how to apply an impulse to an object to make it move. It's the basis for all vehicle physics and I originally approached the problem in 3D but it confused me. So, I broke it down to its basic elements in 2D and created one of my favorite XNA programs. It's almost a game. The project is linked from the tutorial page. It's complete XNA source code. (XNA 4.0 I believe.)

It's a little 2D spaceship that uses real world physics to move around the screen. I explain the logic behind it in the tutorial. And in the program I apply the theory to make a 2D spaceship with 3 rocket engines to push it through space. The easy one is to have one engine centered behind the craft. But what happens when you have two engines behind it that are not centered? What happens when you turn one of them off or one engine pushes harder than the other? And what if you can vector the main centered engine to angle it so that it pushes the craft at an angle rather than straight forward? I had to go through the whole physics of applying a force anywhere on an object and calculating the result. What it basically boils down to is that if you apply an impulse at a 90 degree angle from the object's center of mass it will go to 100% torque/spin. And if you apply the impulse directly towards the object's center of mass it will go to 100% push in that direction and 0% torque/spin. Any angle you push at between those two extremes will be proportionally divided between push and torque. In space, you get rid of all the other variables like friction and fluid dynamics (wind resistance). So, once you apply the force it will continue in that state forever until you apply another force to it. Apply the opposite force and you can shut it down if you don't over do it and reverse it.

So, the simulation becomes kind of a game if you try to steer the ship around the screen. Because it was never intended as an actual game, if you ever go off screen it's nearly impossible to steer the ship back to the screen. And it's very easy to over do the controls and steer off screen. So the "game" is to steer the ship around the screen without ever steering off screen where the "game" is over because you'll never find your way back to the screen 99% of the time (in theory it's 100% possible but once you get that far out of control you have no idea where it went or what you need to do in order to steer back to the screen). So, you apply a little force here and a little force there to steer around the screen and just don't over do it. Most of the time the engines are off; you just burn them long enough to steer and get some forward momentum.

But this could easily be used to make a game. If you imagined it vertical instead of horizontal you could apply gravity and make it a rocket trying to take off from a planet without crashing. Instead of impulse from rocket engines, you could use the same principles to determine the push and torque of a missile hitting the hull at a different spot (assuming the armor plating holds up and the missile does not destroy the ship). Technically, for every action there is an opposite and equal reaction; so if the ship fires its own missile, the missile would push on the ship as much as itself and push the ship backwards in the opposite direction the missile is firing.

The past couple of days I've been thinking about making something more of a game in 3D with 3D space ships that use these same principles.

And XNA is a great platform to learn on in order to work towards DirectX. I can't even begin to tell you how much it helped me learn DX. And when you get ready for it, I have working DX11 code to get some basic 3D going. This is a video of what the DX11 code does. Complete source code is on the website page. It's pretty basic, but it's all the code necessary to get DX11 running and start putting 3D models on the screen. I could have easily animated the wheels on the car. The code is setup to support it, but I just didn't get around to it. It's 1,000 times easier to do in XNA and in fact I put the same car model to work in an XNA tutorial where I do rotate the wheels. I believe that's my "Toy Car" sample on my examples page. You can see what the Toy Car code looks like when it's running in the intro video on my YouTube channel. It flashes on the screen real quick in the intro.

Oh. I also wanted to mention that my 2D physics tutorial there does not use collision detection at all. I think you don't want to use collision detection or bounding boxes for that. If for example, I wanted to have missiles being shot at the ship and the ship to move appropriately to the force assuming the armor plating or shields hold the ship together when the missile explodes on the hull, I would use the bounding box to determine that the missile did hit and then calculate the distance and angle from the center of mass, but I would only use the bounding box for the initial detection of the collision, not in calculating the impulse. If I wanted to get super precise, I might use pixel collision detection to figure out exactly where on the hull it hit rather than a bounding box. The more complex you make the shape of the ship, the more difficult it is to figure out all the angles involved, but it's the same theory no matter how complex it gets.

This post has been edited by BBeck: 22 April 2016 - 01:46 AM

Was This Post Helpful? 0
  • +
  • -

  • (5 Pages)
  • +
  • « First
  • 3
  • 4
  • 5