11 replies to this topic

[Rimevan]

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

[geon]

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

[Rimevan]

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

[Rimevan]

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

[alphadog]

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.

[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://www.koonsolo....tters-gameloop/
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.

[Rimevan]

alphadog, on 02 May 2012 - 01:20 PM, said:

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, on 02 May 2012 - 01:23 PM, said:

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....tters-gameloop/
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

[Tottel]

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.

[geon]

Rimevan, on 02 May 2012 - 02:06 PM, said:

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.

[Rimevan]

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

[alphadog]

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.

[Rimevan]

alphadog, on 02 May 2012 - 03:48 PM, said:

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.

The game is just one file, so it skips everything, not just the rendering.

Rimevan