Reputation: 583 Enlightened
- Active Posts:
- 1,294 (1.41 per day)
- 24-April 12
- Profile Views:
- Last Active:
- Yesterday, 07:43 PM
- OS Preference:
- Favorite Browser:
- Internet Explorer
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
- Expert In:
- Game Programming, XNA
Posts I've Made
Posted 30 Oct 2014So, download Unity and play around with it. You won't be using C++ with Unity. You can use C# or Java to script for it. Unity itself was probably built using C++ and OpenGL. (Also, probably DirectX 11 as well since it supports some DX stuff).
So, your computer is just a machine that runs machine language code. Machine language is ugly and no one likes it or really uses it (it has it's place but its not commonly used directly). C++ is a language that you can write instruction for the computer to use to do stuff. A compiler, such as the one you find in Visual Studio for Visual C++, will compile your C++ code into machine language instructions that tell the computer what to do.
Everything, the computer does is in machine instructions. C++ is one way of giving the computer those instructions. When you write a program, it's written in a language like C++ or some other language that's compiled to machine instructions.
To make things more complicated there are "interpreted" languages where someone builds an "interpreter" in C++ which then interprets some language that they make up into machine instructions. That's basically how Java, Python, and C# work where they go through an interpreter which issues machine instructions based on the language commands from that language. This has some advantages and disadvantages but is generally considered slower than C++.
C++ can be used in many environments including MacOS and Linux. So, it's not just a Windows thing. If you want to do Windows with C++, you need to learn the Win32 API or some SDK built around the Win32 API (there used to be a couple of them like OWL and MFC but all of this is becoming less common). Win32 basically is Windows in terms of programming. (Although, this was as of Windows 7 and I'm not sure exactly what they're using in the latest versions of Windows).
When you write a Windows program in C++, whether it's a game or anything else, you need to use the Win32 API to make Windows do it's thing. (You can do console apps, but that's still going through Windows and not what we use for games anyway.)
Well, Windows blocks access to the graphics card which is a major problem. You have to go through Windows to get to the graphics card and Windows has traditionally been slow at this although it's vastly improved over the past decade with GDI+ and Silverlight and such.
There was originally another problem with the fact that every manufacturer made a different graphics card with completely different capabilities.
To solve these problems Microsoft created DirectX. DirectX allows you to bypass Windows and Win32 and go directly to the graphics card (almost too directly really). This also provides a standardized way of working with the many different types of graphics cards that are out there.
Theoretically, you can use any language to work with DirectX as it is an API. I've seen people use C# and I think it's at least theoretically possible to use Visual Basic. But I would not recommend using anything other than C++ for DX because most of the examples you will find will be for C++. It will be even more difficult to get someone to help you if you are doing DX in C# or especially Visual Basic. And finding tutorials and books will be few and far between.
So, to write a game or really any graphics program in C++, you use C++ as the basic language to do all the work in and you call the Win32 API from C++ to ask Windows to give you a process and a Window to run your program in. (That's about all the Win32 you really need to know to program DX games. You can pretty much copy and paste those few pages of code and not have to really worry about anything else in Win32.) Then you call the DX API using C++ to initialize the DX system and then put you in touch with the graphics card. Then you make repeated calls to the DX API from C++ to make everything else happen.)
OpenGL is basically the same thing as DirectX except DX is very Windows specific and OpenGL can be used in other environments like Linux as well as Windows. Both are really only supposed to do graphics. Although, DX has other APIs that ship with it to handle things like the Xbox 360 controller, sound, and keyboard input. You'll have to use other APIs with OpenGL to get those capabilities and for Windows you may want to use DX to provide those other capabilities to OpenGL. SDL is another option from what I hear.
When they made Unity, they probably used C++ and OpenGL as well as DX and the Win32 API. Unity runs on so many operating systems that they probably used a lot more than just that. But now that they've created Unity, they've done about 80% of the work for you.
Now you can just use the Unity program without knowing anything about Win32, OpenGL, DX or even C++. You'll want to learn C# or Java to write scripts for Unity, because scripting is where all the power in Unity is at.
Basically, in Unity, all you do is import art assets (music files, 3D models, animations, etc.) and write scripts to create your game.
You could do this in C++ and DX, but you'll be recreating a lot of what the Unity people have already created for you and C++ with DX is in many ways far more difficult. You can immediately jump in and start doing game making stuff with Unity. And you'll learn a tremendous amount about what goes into creating a game. It's invaluable experience if you've never done this stuff before.
All that said, I'm personally going with C++ and DX and learning to do this stuff from scratch the hard way. But that's just because I'm a masochist. No seriously, I enjoy the learning process and understand things at the deepest level and that's C++ with either DX or OpenGL. I like Unity but for me I'd rather dive off into the deep end. Then again, I'm less concerned with producing a finished product than I am enjoying the journey and learning from it.
Posted 25 Oct 2014I think what you're looking for is a tutorial on "Tile Based Collision Engines". Get on YouTube and search for "tile engine XNA" I know there is at least a few tutorials that are XNA based on that.
But, like modi123_1 said, the general concept is to make an array with an array element that represents each tile. Assign number codes that represent the type of tile it is. Draw the tiles according to their values in the array. Use the array for things like collision detection to tell if a tile contains a solid object like a wall. Use the array for path finding to make enemies chase you smart enough to go around solid objects yet still get to you.
Posted 25 Oct 2014I haven't seen much of anything on collision detection.
Are you using Blender as a game engine, or are you exporting a model to something else? And if so, what?
Spheres are even more easy than collision boxes to implement.
For the wagon above you should probably have the wagon body as a parent of the wheels. Hacking my way through Blender's Python code I noticed that there may be something there for collision geometry for each sub-mesh. I'm in the process of writing my own custom Blender Python export script right now. So, I'm trying to figure out Blender's data structures and how to extract that data. I haven't specifically worried about collision detection yet because I'm just not there yet. But for a wagon like that, I might be inclined to define a collision sphere and a collision box for each sub-mesh and see if I could export that data.
One problem you would come across very quickly is that for a moving object you have to use OBBs (Oriented Bounding Boxes) for the collision detection. AABBs (Axis Aligned Bounding Boxes) are just not going to work on moving objects because by definition you cannot turn an AABB. If you used boxes to represent round wheels, it might be best to keep them flat against the ground rather than rotating with the wheel, but you still have to yaw the entire vehicle along with the wheels. So, you would pretty certainly need OBBs.
If you're worried about the shape of the collision geometry not matching the object, it just gets far more complicated after OBBs. OBBs are pretty ugly mathematically. After that, you're probably looking at collision hulls. You can check every single triangle in the object's geometry to see if another object intersects it. That could be a very expensive operation. I've never really seen it implemented. But I know that you can at least simplify that by making a collision object that is a greatly simplified version of the actual object.
So for the wagon wheels, for example, you could make a hexagon cylinder. That would not be as many triangles as the actual wheel geometry. That would be what they call a "collision hull" I believe.
Posted 21 Oct 2014It sounds like your problem is that you are not taking into account the viewports. If you're using render targets, the mouse coordinates need to be relative to the render target and not to the screen. So, they have to be translated. The render target is a screen within a screen and objects drawn to it will be relative to the render target, not the screen. So if you expect those coordinates to match the mouse coordinates, you have to code to match them back up.
There was another issue I had where the coordinates were slightly off in windowed mode, but fine in full screen mode. I'm not sure I ever really got that one solved, but it was off by about 10 pixels. Sounds like in your case it's completely off.
Posted 11 Oct 2014I don't particularly see anything wrong with your SpriteBatch although I hardly ever use SpriteBatch in 3D and probably don't have all the necessary steps memorized.
But I don't see any declaration for ScreenManager which is on the line immediately before spriteBatch.Begin(). That looks suspect.
What is the exact error message and is it the first error message in the chain of error messages? Are we sure that it's the spriteBatch on line 224 that's the problem? Could there be another spriteBatch call in a section of code that is not listed here (perhaps in the missing ScreenManager or GameManager code? Have you tried using the debugger to step through the code right up to the point where the error occurs?
- Member Title:
- Here to help.
- Age Unknown
- Birthday Unknown
- Dallas, Texas, US of A, Planet Earth, Sol System, Milky Way Galaxy
- Rock music composition and performance, Grunge Music, Bebop (think Thelonios Monk), Swing (think Cab Calloway), Gaming, Astronomy, RPGs, Scuba, Sail Boats, Furniture Building, Cooking, Rocky Patel Cigars, Character Driven Dramas(like HBO's Deadwood), Story Telling (plot writing), Linguistics, Economics, Target Shooting, Electronics (don't know as much as I'd like to), all aspects of 3D game programing including music, physics, modeling, texturing, annimation, probability, AI, lighting, etc., Texas Holdem' Poker, Learning, Dogs, the love of my life (my pit bull), guns (especially 19th century black powder), putting make-up on ogres, etc.
- Programming Languages:
- C, C++, C#, Visual Basic, Java, Pascal, T-SQL, HTML, FoxPro, ASP.Net(very little), Assembler, Machine Code(conceptually anyway)
- Website URL: