4. I was thinking if I used some globals that would be used commonly, I could sacrifice a tiny bit of RAM to gain some speed from not having to create and destroy them so often. Misconception?
Yes. Making the variable global pollutes the name space, any savings are insignificant.
Say for example you have a map class with public members width and height. All you need is a reference to the map object and you can access these variables.
If you keep a pointer to the map object then you spend an extra 32/64 bits to store the memory address and there might be 1 extra look up (go to map object, access member). Hardly a huge cost.
5. I don't usually do that (I never expect anybody else to look at my code), but I actually have comments in this stuff. I'm slowly adding more as I work on different sections.
It's design methodology. When you come back to that code to add something or hunt down some bug you'll be looking at a function and trying to work out if it's correct or not. Before I write any functions I write the class definition and comments on what the functions are supposed to do.
Some other comments:
In input.cpp:
bool eXit = false;
This kind of variable naming is asking for trouble. In map.cpp
const int TileSize = 32;
this is also not good: you have hard coded a global variable and the value is only accessible in a specific source file.
In screen.hpp:
const int screenWidth = 640; //Hardcoded for the Zaurus
const int screenHeight = 480; //Hardcoded for the Zaurus
You should #define this in some global configuration and #include it here. Then, when you want to recompile for another platform you can just change these variables.
In map.cpp:
if(tens == '0' or tens == '1' or tens == '2' or tens == '3' or tens == '4' or tens == '5' or tens == '6' or tens == '7' or tens == '8' or tens == '9')
{
if(tens == '0')
{
intTens = 0;
}
etc
Very ouch!
Some comments on the layout:
Why don't you have a map class ?
Likewise a screen class ?
It would group together related functions and variables, improve the readability of your code
Why is CanMove() not a member of Character class ?
If you make an enumerated type for direction, then you can have code like myCharacter.Move(NORTH) which is a lot easier to read than myCharacter.Move(2).