A Couple Mac Development Questions

[Fls'Zen]

Hi,

I've been reviewing the OTTD mac code and have a couple questions that I'm sure someone can help me out with.

The first question has to do with calls to InteractiveRandom();, without the result of the calls being assigned. It is called by graphics routines in video/cocoa/event.mm, video/allegro_v.cpp, video/dedicated_v.cpp, video/sdl_v.cpp, and win32_v.cpp. It also is called in openttd.cpp's GameLoop() method, which is called by all of the previously mentioned graphics routines. I haven't been able to determine what purpose these calls to InteractiveRandom() are serving, and I really would like to know!

My second question has to do with the fast-forward implementation. From what I've seen in the forums, read in the code, and the several video implementations I've looked at, the general strategy is to run GameLoop() and then render the screen as fast as possible instead of sticking to the MILLISECONDS_PER_TICK interval. The issue I run into on my mac, and perhaps others run into it as well, is fast-forward does not really fast-forwarding due to it taking quite a long time, sometimes the full amount of tick time (or more) to render the screen. (I have a 2560 x 1440 screen. Obviously it runs fast when I have the screen windowed and, at most, half that size.) I have found that, when in fast forward mode, if GameLoop() is run more than once per frame, say 32 times, before updating the display then fast forward goes nice and fast, even when rendering my full screen. Perhaps an improved fast-foward implementation would estimate how many times GameLoop() could run before the next tick. Instead of pounding out a series of GameLoop, render, GameLoop, render, it could do a number of GameLoops, then render, keeping the frame rate matched closely to MILLISECONDS_PER_TICK. My question here is more of a request for comments and feedback on the idea of running GameLoop multiple times without rendering each time in fast-forward mode.

Thank you for your help!

[Alberth]

Hi,

The first question has to do with calls to InteractiveRandom();, without the result of the calls being assigned. It is called by graphics routines in video/cocoa/event.mm, video/allegro_v.cpp, video/dedicated_v.cpp, video/sdl_v.cpp, and win32_v.cpp. It also is called in openttd.cpp's GameLoop() method, which is called by all of the previously mentioned graphics routines. I haven't been able to determine what purpose these calls to InteractiveRandom() are serving, and I really would like to know!

I don't know either, but I suspect it has to do with staying in sync in an MP game.

In an MP (multi-player) game, each machine runs the full game, and only commands are exchanged (perhaps a bit more, I don't know).
Obviously, you want the game to behave identical at every machine. Since the game use random numbers as part of the decision what to do, every machine needs to draw the same number of random number samples, even if they are not used.

My second question has to do with the fast-forward implementation. From what I've seen in the forums, read in the code, and the several video implementations I've looked at, the general strategy is to run GameLoop() and then render the screen as fast as possible instead of sticking to the MILLISECONDS_PER_TICK interval. The issue I run into on my mac, and perhaps others run into it as well, is fast-forward does not really fast-forwarding due to it taking quite a long time, sometimes the full amount of tick time (or more) to render the screen. (I have a 2560 x 1440 screen. Obviously it runs fast when I have the screen windowed and, at most, half that size.) I have found that, when in fast forward mode, if GameLoop() is run more than once per frame, say 32 times, before updating the display then fast forward goes nice and fast, even when rendering my full screen. Perhaps an improved fast-foward implementation would estimate how many times GameLoop() could run before the next tick. Instead of pounding out a series of GameLoop, render, GameLoop, render, it could do a number of GameLoops, then render, keeping the frame rate matched closely to MILLISECONDS_PER_TICK. My question here is more of a request for comments and feedback on the idea of running GameLoop multiple times without rendering each time in fast-forward mode.

My first reaction is to do stuff at the right place only.
As you said, other platforms can be affected too, so skipping display during FF sounds like a multi-platform issue/feature rather than a Mac issue/feature. I can imagine an advanced settings where a user can set how many frames he/she wants skipped, and the various video-backends getting extended for that setting.

[frosch]

The interactive-random generator is the one which does not have to run in sync on all clients. It is used to randomize client-side things, so only stuff which is directly triggered by user or script interactions, not by the game state.
Since there is no need to synchronize it (and it will in fact not run in sync even if synchronized at some point), there is not much point in calling it without using the result.
The only reason I can imagine why this was done is to try to improve the randomness. Once started with a certain seed a random number generator is deterministic wrt. its output, so the random numbers only depend on the order when they are queried. However, querying numbers at a constant rate, make the actual random queries also depend on the time when they are done.


Wrt. the drawing in fast-forward mode. I think skipping frames should be fine, but it should be limited. Usually drawing-speed is not much affected when a game progresses (when zoomed in at least). The amount of visible stuff stays almost the same, while otoh the game state becomes constantly slower. So, making the fast-forward speed depend on the drawing speed makes fast-forward less fast for small game states at the start of the game, while it hardly affects big game states. I think this behaviour is useful, so skipping frames should be limited to 2 or 3. As Albert said, this could be a config setting, though maybe not a user-visible one in the GUI, just in some hidden thing in openttd.cfg.

[Eddi]

possible strategy for frameskip:

1. run the game loop
2. check if MILLISECONDS_PER_TICK or some MAX_SKIP value was passed since drawing the screen, if no, goto 1
3. draw the screen, goto 1

this should auto-adapt to the slowness of the gameloop in further developed game

[Fls'Zen]

Thank you all for your for your feedback!

I'm not too worried about the InteractiveRandom() call being in there, I doubt it would ever affect performance considering what does compared to the game loop and graphics rendering steps.


Based on your feedback, I'm thinking that two options would be useful to go along with the fast-forward changes I'm thinking about.

One option would be to enable running the game loop multiple times, but only drawing graphics at the normal rate of one frame per tick of the system clock. Making it an option allows user to keep the old way or use the new way. Since I'm new to the community, I'm guessing that the preferred strategy is to try and not make too many decisions for the users and let them opt-in to new stuff.

The other option would be to tell the system that it's acceptable to lower the frame rate during fast-forward. It would either be a number of frames to skip as mentioned in the thread, or I was thinking that perhaps it could be specified it in frames-per-second. So a user could say, "30 fps (MILLISECONDS_PER_TICK) is nice for normal mode, but in fast forward, 25fps is acceptable." I haven't looked at all the available settings yet, so I'm not sure if specifying it one way or the other would fit better with what's already there.

I will be investigating this more this weekend. Making it adaptive as Eddi and frosch suggest is on my to-do list. I'm probably going to average the time it takes for the last few calls to the GameLoop and rendering functions, then do a little arithmetic to determine how many GameLoops per frame are appropriate. I'll of course also look into how the settings work.

[Eddi]

if you're spending so much time on this part of the code, consider refactoring it so the gameloop/fastforward handling could be moved out of the OS-dependent parts...

[Fls'Zen]

if you're spending so much time on this part of the code, consider refactoring it so the gameloop/fastforward handling could be moved out of the OS-dependent parts...

Yeah, I really like that idea! I'll probably do the implementation for mac without worrying about how the other platform loops work (realizing that they will be rather similar), then look into refactoring the implementation so it applies, or can be applied easily, to the rest of the platforms.

[Rubidium]

Why worry about the speed of fast forward if there are so many things broken for Mac OS X? Also, if you write it specifically for Mac OS X it will never get accepted (until it's done for all backends).

[Fls'Zen]

Why worry about the speed of fast forward if there are so many things broken for Mac OS X? Also, if you write it specifically for Mac OS X it will never get accepted (until it's done for all backends).

Looking at the fast-forward implementation is a good way to get my feet wet with the source code and the intricacies of how the game's input, processing, and output are wired up. It's also an area of concern I have as a user since it's not as simple as pressing Tab to fast forward. (I have to shrink my window for it to go more than about 10% faster—refer my first post).

I am looking at the open bugs for the platform as well. A couple of them look like they're going to be hard to reproduce, especially since I currently only have access to 10.7, an unsupported platform. (I'm working on getting a supported platform set up.)