I've been coding in C++ for awhile now (been through three courses) and I've gathered a big list of just little dumb questions that are too small to deserve their own forum posts and I've just been unable to find any clear answers for. For reference, I'm currently trying to make a game from mostly scratch.

Just a quick note before hand, I'm not desperate for any answers at the moment and really just want to dump these so for future reference and so that any other beginners don't have to go through the shame of asking. A good amount of them aren't C++ specific so sorry if this seems like the wrong place to post. I'm not trying to waste anyone's time with my rambling unless they really want to help :D


I'll try and organize these to make it a little easier to read.

The first set are for Visual Studio and IDE's in general.

1. The way I was taught in all of my classes was use ctrl+shift+B to compile/build my code and ctrl+F5 to run it. However now that I'm trying to get into this myself I'm finding so many ways to both compile/build code and to run it. Is there much of a difference between all these different methods?

2. I've been using compile and build interchangeably, but is there an actual difference?

3. I was taught to just run my code without debugging (ctrl+F5 instead of F5), but know looking back is there any reason why you wouldn't want to debug code?

4. I can switch between debug and release at the top. I'm assuming debug mode is for debugging and release is for the release of the code, but is there a difference between the two? Wouldn't the code stay the same?

5. I can also switch between x64 and x86. I'm not too informed about it but I understand it's for 32 and 64 bit systems. Again, is there a difference relating to the code? Will changing that affect what systems will be able to run my program? Are there any computers that still run a 32 bit system or has everyone switched to 64?

6. Say I finish a program and want to send someone a .exe file to run it. How would I go about doing that? How do I make sure everything the program uses (pictures for example)is packaged in a way that the program can use it? Will others be able to see/access the raw code? Is there a way to prevent that?

Now on to actual C++ programming:

7. I understand using .h files in order to describe(?) .cpp is meant to help with runtimes, but how? Doesn't the program still need to run the .cpp files being described? Won't that just add another file to run and increase runtimes?

8. What are resource files? Are they simply a shortcut to a resource in the folder or is there something else to them?

9. One thing I've been trying to research are state machines. From what I've been able to gather they are just a system to detect what state an object is currently in. However how do they differ from just having an integer that the program can detect as different states? For example 1=standing still, 2=walking, and 3=running.

10. Is there really a best/ most effecient way to handle framerates? Is there a way to break the system so game logic is not attached to the framerate? I understand rendering/drawing everything on screen has to be done every frame and therefore can't be detached.

That's all I can think of at the moment. Thank you for making it this far and I thank you even more if you decide to take the time to answer anything. :D

I understand using .h files in order to describe(?) .cpp is meant to help with runtimes, but how?

Headers are critical when a program involves more than one C++ source file. Suppose file1.cpp and file2.cpp both use class X. File x.h contains the class declaration so they can #include "x.h". If x contains both the declaration and the definition of the methods then you'd get multiply defined methods (unless they are inline).

One thing I've been trying to research are state machines.

Read up on finite state machines. Not only are these interesting theoretical machines (all computers are implementations of finite state machines) but they can be a really useful model for solving problems, especially event-driven programs. I just suggested an FSM recently (although I didn't mention that the solution was an FSM):

http://www.cplusplus.com/forum/general/219854/

1) the shortcut in various tools varies of course. At the end of the day, it compiles and links the code, pretty much the same under the hood but it can vary from a button click to a text command to a makefile.

2) Depends on context. Build means "make the target executable or library" and compile means "check syntax and create the object file" (compile does not always mean LINK when being precise).

3) Once code is working, it runs much, much faster without the debug junk inserted into the executable. This is called "release code". Large programs can run a full order of magnitude slower with debug junk in it, and it also may not even run right on the target machine (Microsoft is bad about debug executables being unable to run on machines that lack visual studio installed).

4) above ^^

5) The executable is very different -- memory models, size of integers, specific chip command are not available on the 32 bits (newer instructions) and more. There are a lot of people still running old machines out there, yes. Older folks, who bought a computer years ago and use it rarely; my mom is sill on a 32 bit machine. Also embedded computers still have a 32 bit option. Poorer areas/countries still use old machines. And my workplace still uses a blasted mainframe, from freaking 1982 or something.

6) there are tools to create an installer, but you can honestly zip up the *release* version and any necessary files/dlls and drop it on the target machine and it will run. There are tools to figure out what libraries it uses also, and more. Installing is not necessary until you get a large software package. They can't see the code if you don't send it, but if its the debug version, they can, its in the executable with the junk. Anyone can disassemble a program and figure out how it works, if they are really, really needing to know.

8) resource files are a Microsoftism and store things like images that you put on the buttons, icons, and other stuff that support the program.

9) state machines are a concept. HOW you code it is up to you. An enum (named integers) for the states is perfectly good. You are confusing the algorithm vs the implementation here, maybe.

10) graphics is complex. There are many, many tricks and it depends on if its 3-d or 2-d, windowed or fullscreen, opengl vs directdraw vs direct3d vs others ... the question isn't answerable "in general". Need specifics. In general you thread graphics on a timer outside the game code, and it just draws the "now" and stuff that is in progress/changing isn't committed yet and isn't drawn yet.

Thanks both of you that actually cleared up a lot of the fog in my mind of what I'm doing! It was a little overwhelming going into it. I figured after three courses of C++ I would have a good sense of what's happening, nope. I only have one followup question.

The executable is very different -- memory models, size of integers, specific chip command are not available on the 32 bits

So what I'm getting from this is I can make it 64 bits and get some fancy new tech at the cost of potentially cutting people out from using my program if they use a 32 bit system? The project I'm working on right now is a fairly basic 2-D game that I don't think would need any of that. I'm still very early on in it so that has yet to be determined. So I suppose for now I'll stick with 32 bit, but if I really need something I should be able to switch it to 64 bit.

Also

You are confusing the algorithm vs the implementation here, maybe.

Yeah, your right. I thought there might have been some sort of "state" variable or object I was never told about. Knowing its my own creation will definitely help, plus thanks to dhayden I think I have good concept of what I need to make now.

you can actually compile the thing targeting both 32 and 64, put both in the installer, detect the system type, and install the correct one. That is some of the fancy stuff I was talking about that the installer tool provides you.

you can make a finite state machine with a graph/tree/list like data structure, but its a royal pain and inefficient. It actually is the machine, though... check condition, follow pointer to next state, check condition, follow pointer to next state.... until state is "done" state. The integer approach, possibly tied to a map container, is very slick.

you can actually compile the thing targeting both 32 and 64

I didn't even consider that an option, interesting. Would detecting system type be handled by the installer itself or would that be some extra code I need to write? One thing I should probably mention is I want to hopefully try and get my game on Steam, and from what I understand Steam has its own installer system. That I'll have to look into myself but that's not until I'm done anyway.

The integer approach, possibly tied to a map container, is very slick.

The player in my case will have two states: what action they are currently doing, and what type of land they are currently standing on as some may affect stats. I'm trying to keep it as basic as possible both for my own sanity and to hopefully make it run a bit better.

the installer can determine the system capability.

i don't know how steam works, but I am sure it has a way to handle this.