Flimflam

Please don't use MFC for new code.

 

It's ancient, unsupported, non-idiomatic C++, and full of evil pitfalls and gotchas. It really needs to just go die in a corner somewhere.

 

I really wish Microsoft would create an appropriate replacement for it. I always wondered why C++ didn't get some sort of WinForms library. Then again, these days things like Qt are around. 

If you're using ID3DXSprite, it requires a texture to use. If you want to continue using that interface, the best choice you have is simply using a 1x1 texture. This will have completely negligible effects on performance. 

- MMOs (You know, ripping players of their money while making them feel they're a part of a bigger community)

Why the chip on your shoulder regarding MMOs?

Microsoft's decisions lately have generally left me feeling disappointed... They look eager to rid themselves of "freeloading" developers despite their products being a positive thing for the platform. I knew the moment Microsoft tried to get rid of the proper Express editions where we were heading. 

Absolutely. XNA is still a fantastic framework for its intended platforms. Don't be discouraged when you hear about a tool or utility you use is no longer receiving updates. It is true that could easily spell death for a product that either has stability problems or needs long term maintenance but for something like XNA which is already very solid, there is little to worry about.

Change this line:

direction = (Vector2)mousePosition - Position;     //get the direction from arrow to cursor 

 

to this:

direction = target - Position;     //get the direction from arrow to cursor 

You need to define your target vector outside the scope of the function, so each time the function gets called, target doesn't get reset. Move your declaration of "target" to the same place you defined oldState, then remove the "target = mousePosition;" line.

 

Also, unrelated but in your distance checking code, you can replace "move.Equals(true)" with just "move".

... suggesting that your modify your...

 

Oh no, I didn't mean to imply that. I am honestly just wondering how others parse their files, either parse while reading or parse after copying to string and closing file.

 

If you're working with large files then it would make sense to parse the data as you read it, otherwise you could run into memory problems and the like. For small files, this isn't really something you would generally need to concern yourself with, so the standard open -> read -> close -> parse would make perfect sense. 

You can't give them the individual DLL files that constitute the XNA redist, however you can include the redist installer with your application, so they won't need to go to Microsoft's webpage to get it.

They were compact because they had to be (space on those cartridges was very limiting), and because the method of storing/creating the information was different. Since size and power today is not a big issue anymore, we can get away with cutting a lot of corners, and using much higher quality assets. Sounds are stored as full waveforms, Graphics are large, etc. Back on older consoles, music was somewhat similar in nature to the old MIDI format we have on PCs, and graphics were very optimized tiles that tended to compress well, rather than large images rendered onto the screen whole. 

(It still amuses me that C++ remains one of the only languages where people go out of their way to avoid the standard, library instead of learning how to use it properly, based on 10 year old hearsay and rumours...)

People are just too obsessed with optimization, and I think when they consider how the library is designed (templates in templates in templates), think they can trim the fat and reap the benefits. I think the biggest problem is a lot of people don't even consider the standard library part of C++. That it was something tacked on after the fact, and started off pretty poorly. 

 

Then there's missteps like Microsoft's implementation doing silly things that degrades performance on simple operations unless you add messy definitions to disable them, even in release builds. It just puts a bad taste in everyones mouth and confuses the issue, perpetuating the idea that it's slow.

 

It took me quite a while before I trusted the standard library before I ultimately moved to C#. I still feel weird about std::string sometimes, and I don't even know why. It just feels so external to the core language for something so fundimental.

C# requires very heavy weight dependencies, .NET on Windows, and Mono on everything else.  You are looking at increasing your install process upwards of a gigabyte or more.  Although it is possible to use C# on non windows systems I wouldn't really call it a practical solution.  There is always Java but my personal opinion is that this can cause some slight lag in the loading process (traditionally Java performs a bit slower than C++ due to the interpreter that must intercept and parse the byte code).  If you are using lightweight graphics and don't mind adding a few extra seconds to your loading screens I would recommend java.  If performance is critical your a little stuck with C++.

 

I'm curious under what circumstances you would ever need even close to 1GB or more space using C# under any OS? The Client Profile for 4.0 which is all you need to do most projects (unless you need some really obscure .NET features--unlikely), is a 30MB download in its entirety, and mono can be even smaller.

 

C# won't require a bigger set of dependencies than Java would. It's more than a practical solution these days.

What you have to realize is that making a draw call has a cost. And so you want to reduce that cost.

If I have 10 mesh in the scene, 5 of them are the same, I have to repeat the following 10 times to draw them all:
- Set world matrix
- Draw

What you mean by reducing draw calls? I think you can't draw more than 1 mesh in one draw call.

You should look into vertex buffers. It allows you to condense a large amount of geometry into a single batch which you can then draw together with one call.

Playing other games and seeing how they tackle the issue of controls is one of the best things you can do.

However, here's some common key configurations I would expect to find in almost any third person action game (right handed):

Keyboard:
W - Forward
S - Back
A - Strafe Left
D - Strafe Right
C - Crouch
LShift - Sprint
E - Interact
F - Grenade/Thrown item/etc

Mouse:
Left Button - Primary Attack
Right Button - Alternate Attack / Precision Fire (such as iron-sights if gun-based)
Middle - Various / same as keyboard F

You know, I've always wondered, when they created the C++11 spec, why did they create "nullptr" instead of just using the reserved but functionless "null" keyword that already exists?

Was it because people were creating their own functionality for it via macros or what have you?

"null" is a keyword in C++? I didn't know that... Or are you thinking of a different language?

No, not officially. My wording was a bit misleading. In fact thinking back, I'm just confusing the functionality of an old compiler that had reserved it. I'm unaware if any others have since.