Reputation: 654 Enlightened
- Active Posts:
- 1,521 (1.35 per day)
- 24-April 12
- Profile Views:
- Last Active:
- Today, 04:16 AM
- 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 27 May 2015I took C in college and had been doing VB back since VB6 and then into VB.Net. I never actually "learned" C#. I took a look at it and instantly understood it. I just started coding. It's mostly just a difference in syntax for .Net. Everything will be extremely familiar. If you know C, then the syntax will also be instantly understood.
I highly recommend RB Whitiker's book. I went through it as my "formal training" in C# after working in C# for a couple of years. Sure enough, he taught me a few things I had missed. It's called "the Player's Guide" and he teaches XNA game programming, but don't let that fool you. There's nothing in the book related to game programming. I'm not sure why he chose that title except maybe to make the book a bit more "approachable". It's just a pure C# book. I think it's a great book for anyone from a beginner to someone who's been doing C# for years but had no formal training in it and needs to learn the language more thoroughly. It gets into some fairly advanced stuff, but he presents it in a way that is understandable for even absolute beginners.
Posted 27 May 2015I went ahead and posted the latest code to my website. This code is roughly the same thing that was posted as "Blender Models" but I added code to serialize the RigidModel class out to a custom .RMF binary file. I also built a C# program that is included in the project that reads the .RMF file and shows it's contents in a human readable form since the actual file is just a stream of bytes that I can hardly read and I know what's in it. But most of all, it fixes the bug where it would not compile in 32 it. I compiled it in 32 bit and ran it before I uploaded it just to make sure one last time.
Next, I'm probably going to do away with all the model code and rewrite the RigidModel class to load from an .RMF file instead of the Python export file. That should be pretty quick to load as opposed to loading and compiling the Python file that is taking like 60 seconds for a model with about 1,000 polygons in it. I'll probably write a console app as a separate app to compile the Python files after that. Or I could make it part of the C# program or write an MFC app to do it if I learn MFC in time.
Posted 27 May 2015Databases are primarily used for large amounts of data such as 100MB+. They are also used for data that must be managed.
If you have 1,000 records that the program keeps and works with but there is no need to access these records by anything other than the program, then a database is generally a bit overkill. But if you have a billion records that need to be sorted through in less than a second, you need a database.
Also, if you have half a billion records and you need people to manage that data possibly between multiple applications you don't want to have to teach every new person you hire your custom data formats and how to read your binary files. If you have to spend 6 months training every new employee on the ins and outs of how to manage your data that's a problem. Whereas you can hire someone pretty much off the streets who already knows a given database. They may not know your data, so there may still be some learning, but at least they know how to access and work with your data since they know the database.
There are also issues of security and backup. Databases provide security to allow only certain people certain access to the data. And if it is critical company data, you don't want it to only reside on one computer; you want backups of it. If we're talking a billion or 100 billion records that are always in use, backing up the data may require a strategy more than running a tape backup. If the data is in constant use, a normal backup will likely skip it every time and never back it up, not to mention that backing up a terabyte of data throughout the day every day so that there is no possibility that you lose even a single piece of data is not something normal backups are designed for.
As for using very small databases like SQL Compact Edition, the primary advantage I see there is if you need to actually mess with the data and the data is not maintained exclusively through your program or especially if end users are likely to need to mess with the data without going through your program.
There might also be some network issues about how you are going to make the data available to many users on the network simultaneously even if it's a relatively small amount of data like 100,000 records. Without a database, you might have concurrency problems with two users trying to change the same piece of data at once.
Posted 26 May 2015I was afraid of C++ for far too long. It's not that much different than any other programming language by itself. By itself, probably the only thing that makes it more difficult than C# is pointers and memory management. The fact that it is native (unmanaged) code certainly makes it a bit more difficult because most people have a lot of trouble with understanding pointers.
Then on top of that, you have the fact that that by itself only allows you to write console apps that are all text based and less impressive than 1980's DOS apps.
To get something like Windows Forms without going to .NET (CLI) and managed code - which begs the question "Why are you not using C# if you are going to do .Net and managed code?", you have to use a library like MFC. MFC is it's own learning curve on top of C++ and it's a pretty big one. Honestly, I've been trying to learn MFC here lately.
Another problem with MFC is I think it's already deprecated; I think they don't use it anymore in Window 8 let alone Windows 10. So learning it means you're learning an outdated technology. But I found it to be not that well documented and it's all just a wrapper for WIN32.
Real Windows programming is WIN32 programming (at least it was until Windows 8). WIN32 is not object oriented and was designed somewhere around the Windows 3.1 days. It's old and in and of itself not easy to learn as it also is pretty poorly documented, although I've learned to program in it to one extent or another over many years. MFC just turns WIN32 into a class library to make it object oriented. So, to learn MFC you pretty much need to learn WIN32 which is just as hard to learn as MFC and probably harder to learn than C++.
The good news for DX programmers is that you only have to use about 100 lines of WIN32 code to use DX and you can pretty much copy and paste the code every single time without exception. The only WIN32 I can think of you might use is if you want to handles some Windows Events and tap into the Windows Event Loop. You may want to process keyboard commands this way although I chose to use DirectInput from DX8 (yes, that's right DX8) rather than using the Windows Event Loop. So then, all you need to know of WIN32 is how to get it to give you a Windows Process to run under and an actual window to run in (even if you run in full screen mode). That's pretty much it. You really don't have to get very deep in WIN32 to do DX, and you don't have to even know what MFC is let alone how to program for it.
The bad news is that without at least a solid knowledge of WIN32, if not MFC, you are only going to be able to write console apps to build your tools with that are not DirectX apps. At the moment I've been using C#.Net for writing tools, but that's part of the reason I've been trying to put in some time to learn MFC. (I'm also working on MFC because I was reading Ivor Horton's C++ book in order to brush up on my C++ and learn C++ 11 as well as C++ 14. If I'm going to put code samples and tutorials on the Internet, I figured I didn't want to be writing them in outdated versions of C++. And I made it to the chapters on MFC.)
Then on top of this, DirectX is a COM object, or a series of COM objects. You don't have to know a lot about COM to use it other than COM objects pretty much manage their own memory and you don't have to de-allocate their memory. However, it is extremely important that you release them when no longer used because that's how they know it's no longer needed and can be de-allocated. COM objects have a counter and when you release them it decrements the counter. It won't release it from memory unless the counter hits zero. I think that's mostly all you need to know about COM for DX.
But there is another issue that arises and that is that DX, partially because it's a COM object, really likes pointers and so you are kind of forced to use pointers pretty regularly.
Combine that with the fact that you are going to want to pass a lot of these big memory hogs by reference to avoid duplicating them in memory and you're going to have to be really comfortable with pointers really quick at a level that causes most students to drop out of C++ class.
I'm starting to get comfortable with pointers. There are some books out there on the subject, but I think a lot of it is understanding the fundamentals of pointers and then just practicing and working through solving some pointer problems.
So, there is some valid reason to fear C++, but not so much the language (unless you mean pointers and memory management) but more all the libraries you have to use with it to get it to do things like DX and MFC. I let it intimidate me for many years before taking a C class in college that showed me my fears were over exaggerated just from everyone telling me how
"hard" it was. It's really not, and the other stuff is learn-able although it takes a lot of effort to learn it.
I started trying to write a guide on installing DX11, but it's complicated and I'm no expert. Probably the thing I dread most about C++ programming is linker errors. Everything in the actual code compiles great without a single problem and then I get linker errors and there's no hint what the actual problem is. I have really solid debugging skills when it comes to stepping through code with a debugger, but if I can't get it to link that's of no use at all. And I don't think I've ever seen a single linker error that ever made any sense to me. It just spouts some useless babble and then I blindly go off trying to find what the problem is. I compile often to get any linker errors as soon as possible because then I'll know which section of new code caused the linker error. I wish I had better skills at debugging linker problems.
Anyway, there are several things that could be keeping it from linking. Obviously, any linking error likely means it can't find part of the code it's looking for which begs the question of whether it's being told to look in the right places for it. There's also the question of what code it is looking for. I've never heard of "_vsnprintf" and this an error coming out of my code! That's why I hate linker errors; they mean absolutely nothing to me and I never know how to fix them although I always get them fixed in the end.
The first thing you should be aware of is that the "I probably shouldn't have" version of the code with the model class in it that I posted has a known bug in 32 bit. Try compiling in 64 bit. I don't think I introduced the bug until I brought in the model class, and so earlier examples will likely compile in 32 bit with no problem. It all compiles fine in 64 bit which is why I did not notice the issue until after I put it on the website. Normally, I compile in 32 bit then compile in 64 bit, but apparently I forgot to attempt to compile in 32 bit on that example.
There was an issue where SIMD instructions require you to do specific memory alignment when using Matrices (which you use all the time in DX). The memory alignment is not an issue in 64 bit and so it compiles just fine. But it blows up like an H-Bomb in 32 bit.
I fixed the bug by using a somewhat older method of coding that I had not wanted to use but I noticed all the book authors like Frank Luna were doing it the older way and figured out that this is why. It was easier just to avoid the issue rather than fixing it.
That brings up the next issue, which is that I use a fair amount of deprecated code in my examples. I wanted to use all the latest and greatest techniques and really made it a point to try and do so. But I soon found out DX is kind of in a state of disarray where Microsoft is kind of trying to force everyone to go to Windows 8 and Windows 10 but we don't want to go. Their answer to a lot of the problems is "Use Windows 8 or Windows 10". Maybe I'll go to Windows 10 this fall, I'll make the decision later this year. But for now I'm not leaving Windows 7. I bought Windows 7 specifically to avoid Windows 8 and would still be using Windows Vista if it were not for the fact that it is ending its support life and spending hundreds of dollars to go to Windows 7 rather than the much cheaper Windows 8 bought me more support life. I'm never going to Windows 8. We'll see about Windows 10 later. For now, I'm only coding for Windows 7.
And DX is kind of stuck in the middle of this. Nothing higher than DX11.0 will run in Vista and you had better have the latest Service Packs. DX11.1 I guess is what all my stuff is and won't run unless you have at least Windows 7 SP1 installed. DX11.2 requires at least Windows 8 but I don't see the point since you about 12 people on the planet are using Windows 8. ;-) If you are writing Win8 software, you aren't going to have many users to sell it to.
But there are some very significant differences between each version there. My stuff is very much DX11.1 for Windows 7 and anything outside of that is likely to have some issues that require at least small code changes. That means you also have to have a graphics card installed that supports DX11.1 which is probably going to be a more recent one purchased in the last few years.
In theory you can get DX11 to run in DX9 mode, but in practice I've found it not to be easy. My work computer is running Windows 7 SP1. Of course it doesn't really have a graphics card and I doubt it supports DX11. I tried to get it to run some of my DX11 code in DX9 mode but never did get it to run.
DirectX is extremely hardware dependent as well as very OS dependent. I don't have a lot of different systems I can test on, so I haven't faced most of these compatibility issues or tried to get code that runs on older machines or even on newer Win8 or Win10 machines. I'm not sure what all kinds of issues you could run into if not running Windows 7 SP1 with a DX11.1 compatible graphics card. But most of that should be a runtime problem instead of a linker problem.
With the linker, I would expect either some code is missing or it doesn't know how to find it.
One issue is that, partially because it's Windows 7 and partially just because they decided not to include a lot of stuff in DX11, I use a fair amount of deprecated code. I tried to use the latest and greatest where possible. But in the end I ended up using a lot of deprecated stuff just like all the authors of the DX11 books (discovering there's a reason they do this). A big example is that I use DirectInput from DX8 to handle the keyboard. DX11, at least with Win7, does not give you any "good" way to handle keyboard input. They stopped supporting the keyboard with DX9. You can use the WIN32 event loop to handle keyboard and I think I coded it to handle the Escape key to exit. But I think DirectInput gives you more direct access to the keyboard instead of waiting and hoping the Windows Event Loop tells your app about the keyboard events going on. This is largely a matter of choice but some of the DX books I have recommend using DX8's DirectInput.
But that along with several other things I use are deprecated from DX11. They are not in the newest version of DX11 which is included in the Windows SDK.
"Supposedly" if you have Windows 7 SP1 installed along with the latest updates from Microsoft you already have the latest version of DX11.1 on your machine. I've found this version does NOT include even DX11 functionality that is considered deprecated let alone anything from older version of DirectX. In order to get that older functionality to work (specifically I'm using some older DX11 stuff that requires it when compiling shaders) you have to install DX11 separately by installing it manually. So, you basically have to have DX11 installed twice, once as part of the Windows SDK and then also as a manual DX11 installation. The manual DX installation is only required if you use the deprecated functionality, but I've found that you need to be in Windows 8 or higher to have any real hope of not using deprecated functionality. I try to use anything deprecated as least as possible, but unfortunately it's very hard to avoid because MS doesn't give you good current ways of getting it done in Windows 7.
One problem I encounter was D3DX11CompileFromFile. It says DX11 right in the name! But it's deprecated. Go figure! That's an excellent example of what I'm talking about. They expect you to use newer Win8 functions, but I'm not in Win8, I'm in Win7! So, I can't really use Win8 functionality and the Win7 functionality I need is "deprecated" which means they didn't bother to include this DirectX 11 code in the Windows SDK with all the other DX11 code. So, now, I have no other choice but to install the second manual installation of DX11!
It seems no matter what you do, it's a nasty install especially if you aren't willing to cave and just go buy Windows 8 and forget about developing for any earlier version.
Here is a link to Microsoft's downloads:
Now I would think that loading the project file "should" have copied the VC++ Directories as part of the project. But it may have lost those. I've found that to be the source of a lot of linker errors. In the project's properties there is "Configuration Properties" and "VC++ Directories" is under that. I use the following setting which I had to enter manually with every new project:
EDIT:Corrected these to match what I have in production where the code is working. Notice it uses both the Windows SDK and the DX SDK. I'm not 100% certain this is correct or the best way to do it, but it works on my machine. Again note that this is for 32 bit and you need x64 for 64 bit.
Executable Directories: $(WindowsSDK_ExecutablePath);$(ExecutablePath);$(DXSDK_DIR)Utilities\Bin\x86
Include Directories: $(WindowsSDK_IncludePath);$(IncludePath);$(DXSDK_DIR)Include
Library Directories: $(DXSDK_DIR)Lib\x86;$(WindowsSDK_LibraryPath);$(LibraryPath)
This helps the compiler and linker to find the Windows SDK and then the manual install of DirectX 11. It has to use the latest from the SDK when ever possible or it gets really confused, but then when it's something missing from the Windows SDK, like DirectInput for the keyboards or D3DX11CompileFromFile, it needs to then look in the manual DX11 installation for it.
That doesn't look right. I'll try and see what I have on my main computer since I'm copying this from the laptop where the code doesn't run. I'll change that to correct it later tonight when I can pull it off a computer where the code is actually running. Also note that any place where it says _x86 that is for 32 bit code and a 32 bit compile. Under the settings for the 64 bit compile all those need to be changed to _x64.
But this is why I tend to steer absolute beginners away from DX. Just getting the thing installed in the first place is a real chore. It just gets harder after that.
XNA really allows you to focus on game programming stuff and not even have to deal with this low level OS stuff that doesn't really even have anything to do with game programming but is absolutely necessary to get DX even running let alone doing something. Making a skybox or a terrain is pretty much the same in any environment you are in and so you can learn that stuff somewhere like XNA without having to worry about non-game programming stuff getting in the way. The problem with Unity is that it is so high level that it pretty much obfuscates this stuff completely away from you. You have no idea how a skybox is implemented under the hood because Unity handles all of that stuff and more for you with a few simple commands. In XNA you actually have to code that stuff yourself from scratch. In DX11 you not only have to code that stuff from scratch but you've got 100 additional things to worry about just to get a simple example of it running such as whether your matrices data storage is 16 bit memory aligned for the 32 bit compile of your code and what to do about it if not and you're using DirectXMath. Matrices just "work" in XNA, you don't have to worry about how they are allocated or deallocated on the heap or learn about SIMD instruction sets. DirectX with C++ is a whole new ball game.
Posted 25 May 2015So, I figured out how to do annotations on YouTube to make "chapters". It's not quite the same as dividing the chapters up into separate videos, but it at least allows someone to skip 20 minutes of my describing what vectors are and how they are used and get straight to the math if that's all that someone cares about.
I think modi123_1's sentiment is right in that rushing to the "easy way out" is a recipe for failure. Game programming is a field where you have to be willing to do what it takes and not give up. You have to be very independent and able to go get your own answers most of the time. And you have to learn to wade through large amounts of boring information that you probably already half know on a regular basis, or you'll never figure it out. Also, I recorded what I did for a reason and I would not have bothered making a two hour video if I didn't think what was being said was important.
On the other hand, if you've already watched it once, or if I'm covering ground you are already very familiar with and you just want to get some info on Vector Multiplication for example, then an index or table of contents, at the least, should be helpful.
And then there's the fact that I ramble and go on tangents that in my mind are important and related, but are maybe difficult to follow for someone trying to get to the core subject.
And also, when you find a new source whether it's a book or a tutorial video, most of the time it's going to waste your time and at best only contain a few useful pieces of information that you have to spend hours of digging to get that one piece of info wanted. If you just want to figure out vector multiplication and already otherwise are very familiar with vectors you might want to skip directly to that chapter. And if you're just evaluating the source, you probably want to kind of skim through the table of contents to find out what's covered, how good the presentation is, and whether what you're looking for is even covered at all.
So, I finally added some annotations as two tables of contents. Being video format it's hard to get a lot on one screen and so I broke it up into an intro section and a math section with a table of contents for each.
- 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: