Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Pacho]

quote:Originally posted by puke:
<STRONG>its the slowdown to 50 thats the problem.  how much would be lost if the game only rendered every other or every third frame, or something?

also, setting everyones speed to 1 will slow down the game, considreably.  sure, more will get done in less time.  dwarfs will move very fast.  but time will crawl.  seasons will take forever to roll over.  and any events you might be waiting for, well they we be awfully slow in coming.</STRONG>

It should run just as fast, the only thing that changes is that the dwarves take less ticks to move.

[Veroule]

The speed was actually one of the things that rubbed me wrong from the very begginning.  I haven't really gotten too far in breaking apart the program, but a few simple things I figured out so far:

The main message loop calls into a high level "game" routine at every pass.  This is what causes it to continuously peg the processor.  OOP at its worst.

It uses a 1 millisecond Wait API call just before the redraw.  The elapsed time is checked at each pass and calculated to determine whether it is time to draw a frame according to the fps limit. This is what makes it so other programs can preempt and still be snappy.  Same calculation done everytime it loops.  If you are really going to do it this way calculate once, Wait for a slightly smaller time slice and then check the time once.

Before each frame is drawn the keyboard state is polled about 6 times with GetKeyState, and that is just at the main menu.  That API call is not very efficient either.

Actual game movement is also done as a subroutine under the same high level routine.  Meaning 10 fps doesn't just make the graphics crawl, each frame represents a single step for all the game objects.

-------
I haven't actually gotten around to hunting for any callback functions yet.  Game play is just too much fun.  I can still suggest seperating the graphics and the objects and putting each on its own TimerProc.

Game play is much more important.  DF definitely has excellent play.

[ April 19, 2007: Message edited by: Veroule ]

[Zhentar]

Inspired by this thread, I decided to check something. I went into my video card options and set it to force vsync to off. Suddenly, my dwarves were on speed!

[Toady One]

Veroule, the code for Kobold Quest is available, and the message loop is mostly the same.  You don't have to disassemble anything.

In any case, I don't know much about windows programming, but if I remember, you said were using old drivers for one of the pieces of your dual monitor setup, so I really doubt the keyboard etc. calls in the main routine are the problem here.  The FPS problems in large forts are unrelated to the issue you're having in the title screen.  For your setup, it just needs to call the GL routines only for tiles that need updates, most likely, and call them less often.  It renders the window whenever the game AI etc. advances, so as to keep the visuals in line with what's actually there, but it could update the screen at a different rate, sure.  However, I don't know very much about callback functions or TimerProc or whatever.

The main speed problem for most users comes from large numbers of dwarves in large forts.

[Aquillion]

Hmm.  What the game really needs is an option to abstract all the dwarves in your fortress down to a single really really big dwarf.  That'd fix the speed issues right up.

...players who are really bothered by things can always just make their dwarves move faster in the init files as described above, that's sorta a speedup.

[ April 19, 2007: Message edited by: Aquillion ]

[KikkyMonk]

VSync was the issue. I was stuck at 60 FPS on the title screen and about 50 FPS even with the starting 7 dwarfs. I turned VSync off and now im jamming at 400-500.

Fun!

[herrbdog]

However, running that fast (as I have found out), a pee break can lead to your entire fortress being dead before you get back, if you forget to pause.