0
101 May 01, 2012 at 13:23

I have made my first game now, it works fine when I run it in Visual Studio 2008 on my pc, but when I
send it to someone else it won’t work. I thought the debug.exe was the compiled game, but apparently
it isn’t. What am I doing wrong?

The error says the configuration isn’t right and it mentions the file sxstrace.exe.

Rimevan

#### 11 Replies

0
101 May 01, 2012 at 13:42

Debug.exe is obviously the debug version. You’ll want to send the release version instead. It’ll be smaller and run faster.

0
101 May 01, 2012 at 13:55

I have no idea where to find it, how do I compile my game?

EDIT: Nevermind, I found out how to create the release version. Thanks for helping me!

Rimevan

0
101 May 02, 2012 at 12:08

Since I don’t want to start another topic on such a small problem, I will put it in here. I have created the release version, but somehow
it is insanely fast (game is not playable this way). I thought the solution would be to restrict the framerate to a certain amount, but I don’t
know how I could do that. I use Visual Studio 2008. Does anyone know how to limit the fps (or tell me why the release version is way faster
than the debug version)?

Rimevan

0
101 May 02, 2012 at 13:20

It depends entirely on how you’ve coded your rendering. Essentially, you need to drop rendering when it’s ahead of schedule. IOW,

if ((timeNow - timeOfLastFrame) < (1 / fpsSetting))
{
// don't render
}


And, multiple divergent topics in one thread is 1) frowned upon, and 2) counter-productive, as people who have read the thread will not know to come back in because you switched conversation topics.

0
101 May 02, 2012 at 13:23

The speed of your game should never depend on how fast your computer is. Read these tutorials and see if you can implement a fixed timestep:

http://www.koonsolo.com/news/dewitters-gameloop/
http://gafferongames.com/game-physics/fix-your-timestep/

The reason the release version is faster is because the compiler will optimize the machine instructions more for the release. It will also skip some safety checks etc. I don’t know very much about compilers and debuggers, but I believe having the debugger monitoring the execution also slows it own a lot.

0
101 May 02, 2012 at 14:06

It depends entirely on how you’ve coded your rendering. Essentially, you need to drop rendering when it’s ahead of schedule. IOW,

if ((timeNow - timeOfLastFrame) < (1 / fpsSetting))
{
// don't render
}


And, multiple divergent topics in one thread is 1) frowned upon, and 2) counter-productive, as people who have read the thread will not know to come back in because you switched conversation topics.

I’m sorry for not creating a new topic, I will create a new one in the future.@geon

The speed of your game should never depend on how fast your computer is. Read these tutorials and see if you can implement a fixed timestep:

http://gafferongames…-your-timestep/

The reason the release version is faster is because the compiler will optimize the machine instructions more for the release. It will also skip some safety checks etc. I don’t know very much about compilers and debuggers, but I believe having the debugger monitoring the execution also slows it own a lot.

So based on ‘The speed of your game should never depend on how fast your computer is’ I could just slow everything down and it would be the same on every pc? In that case I could just let it ‘sleep’ every
other second to solve this.

Rimevan

0
101 May 02, 2012 at 14:11

That’s not how you should solve it. Read the articles, they explain how you should instead.

It pretty much comes down to getting the time difference between 2 consecutive frames and use that to make everything frame-rate-independent.

0
101 May 02, 2012 at 14:15

@Rimevan

So based on ‘The speed of your game should never depend on how fast your computer is’ I could just slow everything down and it would be the same on every pc? In that case I could just let it ‘sleep’ every
other second to solve this.

Well, that would slow it down, on average. Between the sleeping periods, it will still run just as fast, and it would be unplayable.

What you want is to make the simulation slower, while continue rendering with as high FPS as your monitor can handle.

You probably don’t want to call sleep(), since you can’t be sure your game will “wake up” in time for the next frame, and you’ll get strutting animation. If you use v-syncing, the driver should block while waiting for the next frame anyway, so you won’t burn CPU cycles and battery life for nothing.

0
101 May 02, 2012 at 14:26

This game is actually extremely simple, and sleep() worked perfectly. I will read the articles for future games though, because I now know this solution won’t work with more complex games. Thanks for helping me (again).

Rimevan

0
101 May 02, 2012 at 15:48

sleep() is definitely the wrong way to do it, especially if you use the really wrong way between rendering calls as you slow rendering for everyone.

0
101 May 02, 2012 at 16:23