You might want to consider a game that sleeps or waits for vsync instead of rendering as many times as possible. It's also a little better, I believe, to track performance in time, not FPS. Knowing your update is right at 60 UPS is nice - at least you know you have corrected your game loop now. Knowing it takes 12 ms on average, maybe with 18 ms spikes, is nicer. (I understand your update is nearly empty as of now, this is just an example.)
You won't get to be one of the guys here who talks about his awesome 4000 FPS game, but you might keep your CPU's fan from getting too loud.
Running at 4000+ FPS is definitely not a goal, just something it's doing. I'm not limiting it for now, just because I don't really have a need to aside from less cycles. Once I start adding things to the game, i'll see how they effect the FPS, and if it's capped, I won't know how it effects it unless it drops below my target. Then, when i'm confident that I won't be adding anything else that may significantly lower my FPS, I can work on capping it. My logic isn't currently based on FPS, but the amount of Update() passes per second, which I have set to 60 right now.
Also, I believe using any kind of Sleep() function when not explicitly programming multiple cores is bad. That's just what i've picked up over the years of learning, so until I get into that area if need be, I want to stay away from anything that puts the thread to sleep for now. I appreciate the suggestions though, definitely gives me things to think about!
Now, Ectara, I haven't really implemented any kind of time based logic, and I think that using a semi-fixed time step loop like this one, I read that it isn't necessary all the time. I could be way off, as I've only really spent the last few days deeply researching this. I came from XNA, which basically handled all this stuff for me. I did use ElapsedGameTime in XNA, which I think I can easily use here. That time function I used should keep track of the total time the game has been running, and if not, I can always use the less-precise SDL_GetTicks(). But say I was moving a sprite, and had something like this. This obviously wouldn't be all the logic, but I think it gets my point across:
SpritePositionX = 0
SpriteSpeed = 5
So, since I tried to get the updates to go the same amount of time (hence semi-fixed step, which is how http://gafferongames.com/game-physics/fix-your-timestep/ described it), each update if I were to move, I would do:
SpritePositionX = SpritePositionX + SpriteSpeed.
I know with game time based updating (which i'm not saying i WON'T use), since i'm trying to get Update() to run so many times per second, wouldn't it move 5 pixels each pass, which would be 60 x 5 pixels per second? I tried passing both dt and t to my Update method, and when playing around with variables increasing by 1 * some game time, I couldn't find a difference in increasing it by a static amount, like I used with SpriteSpeed, and increasing it by say, SpriteSpeed * gameTime. I understand the concept, but I can't really figure out if implementing it in my current design is necessary.
I could definitely be wrong on all of this, down to the entire game loop itself. Definitely not saying i'm right at all on anything, which is why i'm coming to you guys for help! Should I go by game time, which I think would look something like this:
Find the difference;
Calculate logic based on difference;
I'm assuming based on your comments above that the game loop I have now will work well, (I hope!), so I think any changes I make come down to whether to update my logic based on time or Update() passes.