I was worried that it might be a little too slow to call a Render or update function through a pointer. Especially since all my rendering is done in software. I'm probably still going to keep it like that since there's no penalty like with other methods.
If that ever becomes the bottleneck in your code, you're in pretty excellent shape. It will not be an issue.
Just because it's faster. You said I can just use subversion or something and sync the base code into a new project?
What you're doing is unlikely to be faster. It will be, at best, on par. It's likely to actually be slower in practice, if for no other reason than you are compiling the code for all your games all the time, especially when you change common header files.
I'm not suggesting you use Subversion (I mean, you should use version control in general but that's a whole different subject). Rather I'm suggesting you use your IDEs built-in functionality to create different projects and create dependencies between those. Instead of creating one project in which you re-invent your own method of doing what the IDE can already do better.
For example, if you're using Visual Studio, you have a solution file (whatever.sln). A solution file can contain multiple projects (.vcxproj files in the case of C++); you have at least one by default. You're trying to put everything in one .vcxproj and do some unusual preprocessor/lexical/language "tricks" to switch out which game you're building, running and debugging.
But you can also create more .vcxprojs. You can create one .vcxproj per game. On the disk, you organize your code like this:
MySolution.sln
CommonCode/
- source code for your common utilities, "engine" functionality, et cetera -- anything that would be shared -- goes here
Asteroids/
- Asteroids.vcxproj
- source code specific to the Asteroids game goes here.
Breakout/
- Breakout.vcxproj
- source code specific to the Breakout game goes here.
Each .vcxproj can reference the common code and include it all. But within VS, you can set any individual project to be the "startup" project, which means that's the one it will build and run when you hit F5 (or whatever).
For bonus points you'll want to actually create a project that builds your common code into a static library and have the rest of game projects link against that, because manually referencing the common source code in every project becomes cumbersome fast.
This gives you a way to have multiple games, sharing code, in one solution and switch between them trivially without having to actually modify any of your code... and it's the way the rest of the world accomplishes this task. Even if you don't use VS almost every IDE worth using has a similar set of functionality.
