Dennis Schridde schreef: > Am Mittwoch, 2. Mai 2007 schrieb Kamaze: > >> Preamble: I'm absolute tired, so please be torantly to some writing >> mistakes and maybe unstructured parts. *g* :) >> >> Well, if WZ runs in Fullscreen mode it doesn't really interest if it >> reserves all CPU time. (AFAIK!) But for laptopusers this is bad, because >> (at least on windows) if the CPU has too much to do (means, most cpu >> time isn't reserved for the idle process) the fan begins to run etc... >> >> But if the game runs in windowed mode, it is nicer if the game 'shares' >> his reserved CPU time. (Sleep(0) / Sleep(1) - I know that Sleep has most >> a resolution about ~10ms but that makes the Taskmanager happy) >> >> >>> Doesn't the scheduler distribute CPU time between all applications >>> anyway? I don't think we can force it to give us all the CPU. >>> >> Sure it does, but it does it more friendlier if the sheduler has CPU >> time in the idleprocess. >> > "idleprocess"? If you are idle, why would you want to feed that time into a > process? Makes no sense to me to eat all the time you managed to free. > > If you want WZ to share more time with other programs, lower the fps limit... > I think kamaze means you should give some tiny bit of reserve CPU time to the CPU scheduler (which it can then distribute to other processes/threads as required). >>> Currently we only request as much as to keep a certain framerate. Which >>> hits the limits on slow PCs, what I don't think is bad (since why would >>> we like to drop the fps even more). >>> >> This is nonesense for me. >> Warzone has (afaik) a framerate independent game logic. >> So it isn't necesarry to limit or try to reach a certain FPS. >> > This is nonsense imho, too. > Why would you want to use a constant delay if you could have a dynamic one? > Do you really need even more fps on your high performance PC and even less > fps > on the tiny old rack? > I really don't understand what problem you try to create here. > I think we should (for the moment) just stick with SDL-Framerate. But apart from that we _need_ to have an explicit sleep/sdl_delay call, simply to yield our own process for others. Btw OpenAL runs in a separate thread as well, so if we would hog all CPU it might even result in sound quirks. > And for the game logics: Yes, they should be independend from the > input/output > system. > There are 3 ways I currently imagine how this could work: > 1. Use SDL_framerate for the mainloop and skip over every subsystem which > requests a lower fps than that. > 2. Control the subsystems via events. > 3. Use threads. > Effort is probably increasing from 1 to 3, while the positive effect should > improve in the same direction. > I assume that with all these options you mean to somehow prioritize the game logic above I/O ? Events seem the easiest way of controlling that.
Threads will gain us little while costing a lot of trouble. The main reason for using threads should be to be able to take advantage of systems with multiple processors. If all you want is to make sure some part of the processing (i.e. game logic in this case) gets prioritized above other parts (graphics rendering). Then threads will require explicit serialization, i.e. suspending the graphics thread until the game logic thread has finished one cycle. And if you do that you would never have needed threads to accomplish the same in the first place. So my advice, if your working on an event based system already: stick with it. -- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
