Jump to content
  • Advertisement
Sign in to follow this  
poigwym

open source dx game

This topic is 819 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

where can i find open source dx game(dx11 may be better),  just for learn how to make a game without engine.

I need a game that use programmable pipeline.

 

 

 

 

Share this post


Link to post
Share on other sites
Advertisement

did you try a project hosting site, such as github or bitbucket or so?

there are literally tens of thousands programs there, no doubt some use dx stuff.

Share this post


Link to post
Share on other sites

I may have just what you're looking for possibly.

 

I have a very bare bones game engine project that was actually designed for someone like you that wants to learn from the source code. It's all raw (from scratch) code that declares a windows process and a window to run in, handles keyboard input, sets up a game timer, imports custom 3D models from Blender, and a game loop. I think there may also be a skybox class if I remember correctly.

 

It's not Unity by any means or Unreal engine, but it's a foundation to begin making your own 3D game from. And it's working code written in C++ for DX11.

 

Now, I will point out that DX is very finicky about your environment. You need a DX11 graphics card. It will probably only run on Windows 7 or maybe Vista the way it is currently written. If you want to run it on Win8 or Win10 you'll probably have to rewrite a few lines of code. It also requires that you have DirectX installed twice. It comes as part of the Windows SDK now, which must be installed. However, I'm using a very small amount of deprecated code. Mostly I think it was DX8 code for keyboard since DX11 doesn't know what a keyboard is. I think there's a couple other lines of code that are deprecated code. I tried to only use deprecated code where it made good sense. I tried my best to make everything as modern as possible using the latest and greatest everything. Anyway, you have to separately install DirectX even though it was installed as part of the SDK for the deprecated and Win7 code.

 

You could remove the keyboard code and handle the keyboard through the standard Windows event loop. I think I actually handle the escape key to close that way. So, there's kind of an example already in the code. But I read somewhere the old DX8 keyboard handler is a better solution because it's more responsive.

 

Anyway, you can download a video of the end result here. That will save you having to download the code without having any idea what you are downloading. From the video, you can see a triangle and a cube that were done procedurally in code. The ground I think was done the same way. I believe I made a class to handle those types of objects where you are feeding it a vertex buffer manually. You probably won't really do that in an actual game. What you are more likely to do is something like the toy car in the scene.

 

The toy car was done by me in Blender (not much of a modeler, but hey it works). The cube wheels where parented to the car body in Blender. They can be separately animated from the car body through rigid animation. I didn't animate the wheels in the code, but you could do it with probably about 5 lines of code. I did do some movement with the car, the cube, and the triangle.

 

And also notice that the camera allows you to move through the scene and look around. That's kinda important and something you might not notice right off just because it's expected, but it takes code to do that.

 

Anyway, I made the toy car in Blender and UV wrapped it. The numbers on the wheels prove that it is a textured model you are looking at. I learned Python to write my own custom model exporter (not to mention spent a month or two digging through Blender's data structures trying to figure out how to extract the model data). The download on my website is the entire Visual Studio project (2013 I think it was). So, it includes the model and texture, the Python script to export from Blender, the HLSL shader code, and the whole nine yards. I wrote a custom class to import the model data and another class for the actual model. It serializes the model class to a custom file so that it can load the data more efficiently the next time it loads. I called my model file format PUNC (Position, UV, Normal, Color because that's the data in it) and it supports rigid animation and texturing. You could probably expand it to support normal maps, specular maps, and so forth pretty easily with just a few lines of code and if you're an actual artist possibly make much better looking models than I can).

 

Anyway, the entire project file is on my website at VirtuallyProgramming.com.

 

Feel free to use it how you see fit. It's not an actual game, but the foundational code you need to build most any game. But there's not enough there for me to worry about copyrights or anything like that. I put it on the Internet for the whole world to learn from and use if they want. If you use the code in your own commercial game or something (or especially in a tutorial), you could mention my website and possibly credit BBeck, but my lawyers won't come looking for you if you don't.

 

I had intended to clean up the code, comment it like crazy, and then do a video on my YouTube channel walking through the code line by line explaining why every line of code is there. But I've gone off to other projects, and now I'm slowly working on rebuilding it in OpenGL 4.5 and then hopefully doing a video on that. Although, I enrolled in a game art class and that's eating up all the time I would normally spend on coding. So, who knows how long it will be.

 

Anyway, you asked for a game. I'm not sure if you meant 2D or 3D, but even 2D is basically the same as 3D in DX11 except you use an orthographic projection matrix instead of a perspective projection matrix. You draw 3D quads (rectangles) and texture them to make sprites. Otherwise, it's pretty much exactly the same as 3D. You can maybe simplify the HLSL shader a little if it's 2D. DX11 pretty much completely did away with 2D. (Actually, I think it was DX10 when they dumped whatever 2D was in DX9). Also, my YouTube channel has a series that will teach you the HLSL. I think the shader I use for the game engine is basically the final shader in my HLSL series. Those videos are designed to go in order, so don't skip any of it other than maybe the part at the beginning where I explain the XNA code (I wrote it in XNA, but HLSL is not really any different for DX11 and the videos explain the minor differences anyways - most of it is math that would still be valid even in GL Shader Language or Cg).

 

And it's not a full game like you asked for, but if you're new to this, this is probably more code than you want to bite off at once anyway. You may even want to download all the projects on my website because I have each project where I slowly built up the code. Going through each one, may make it easier to understand the code. I mean, just getting DX11 to draw a blank screen is like a major accomplishment that takes a ridiculous amount of code. Just studying that by itself may be enough code to start with. Then I take it a step further to make a very rudimentary model class that allows you to hard code the vertex buffer and put objects in the scene.  Again, quite a bit to learn there without adding more code. Then I added some skybox code to create a sky. Then I go on to do code to make a more proper model class that allows custom models to be imported from Blender which is a pretty big learning step too. And finally, I do a more streamlined model class.

 

I lost my main computer about the time I was finishing up this project and my source code with it. I don't know if that final project is the final version or not because I haven't spent that much time looking at it. Possibly, it needs more commenting and some cleanup because it may be the "next to last" version of the project rather than the last one. Still, it's within about a day of coding if it's not the final version. I'm glad I put that code on my website, otherwise I would have completely lost it when my hard drive failed.

 

Anyway, this code is complicated enough. You probably don't want to bite off the code for an entire actual game until what's in my code is completely mastered. An actual game is going to be a lot more code and a lot more complicated. And this gives you a good foundation to learn from. Being able to put objects in a scene, animate them, and move around the scene is really the place to start. You can go on to add sound, skinned animation, shadows, and all sorts of stuff that gets really complicated really fast. But this gives you a foundation to begin from.

 

Oh, also since I don't know your skill level, maybe I should explain the game loop. The code is designed for you only to make changes to the Game class which inherits from the DX class. All that other stuff is "library" stuff that you write once and then put in a library to call when you need it (you may want to change that library code or add to it, but to make a game you should not have to alter any of the code "in theory" except the Game class).

 

The Game class has an initialization method that gets called at startup. It has a Load method to load art assets at startup. It has an Update and Draw method which is your game loop that passes in a timer to time animations and such. This should all be very familiar to you if you've done XNA in the past. If not that's fine too.

 

But the idea of the game loop is that each loop is a "frame" like in old film movies. The animation happens because you are flashing a series of still pictures on the screen one after another. You need at least 30 per second to fool the eye for the illusion.

 

The game loop is doing the same thing. Each time Update and Draw are called you are drawing one still picture. The changes over time will make the viewer believe they are looking at animation rather than a series of drawings as long as the frame rate is over 30 frames per second (and some say 60 for games).

 

The Draw method is for drawing what is on the screen. The Update method is for all the other game code that does not draw. It's separated out into two methods because theoretically if the frame rate drops below 30 fps or so you can stop calling the Draw method and just update the game which should speed the game back up a bit. My code is not setup to do that. But they are separate methods, so you could add some code to do that sort of thing if you want.

 

If you're not familiar with XNA, you may not be familiar with Object Oriented Programming in games. Generally - even though the goal is to modify the Game class to make your game, you want as little code in the Game class as possible because there's going to be a lot of it. So, you write other classes to do what you need that are called by the Game class. I think my Skybox class may be a good example of that where the Draw method tells the Skybox object to draw itself rather than writing all that Draw code in the actual Draw method. Keep the Game class as clean as possible and do the work in the classes you build. Same goes for the Update method. If I were going to make a car class for example, it would probably have a model object, know how to draw itself, and know how to update itself as well.

 

I might also mention that my Blender exporter is not that intelligent. You probably have to select the model for it to work by right clicking on it in Object mode. If there are children meshes, click on the oldest parent. Also, you may need to use a triangulate modifier and apply it because I think Blender can get a bit crazy with the n-gons. And my stuff is built on the assumption that it is working with triangles. It might handle a quad, but when the n-gons go over that, it can get ugly.

Edited by BBeck

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!