On 5 January 2011 08:00, James Paige <[email protected]> wrote: > Newbie Power (and others) brought up adjustable frame rate on IRC. > People know about CTRL+ CTRL- debugging keys, and would like to be able > to do the same from a script... but how can we safely allow a feature > like that without adding headaches for ourselves later? > > I was previously worried about allowing this to be set at runtime, > thinking that when it was customizable it would only be set on a > whole-game basis in custom... but I am not sure that is a valid > position. > > I was also previously thinking that we should make all types of > animation speeds customizable first before allowing people to adjust > game frame rate... but now I am thinking that is an invalid argument... > plus, adding the frame rate customization now, would make it really easy > to locate all the places that need their own animation speed settings. > > How do you feel about this TMC? > > Also, even if we do allow frame rate setting, we should cap it to > something reasonable so people can't make games that depend on insanely > fast computers, and that will not run on normal speed ones. (which they > probably wouldn't be able to do anyway because of input issues?) > > Input issues! I almost forgot! Changing frame rates has some serious > consequences for input too, doesn't it?
The key repeat and repeat delay rates are currently dependent on the frame rate, which is horrible, requiring ugly stuff like slowkey and lots of bugs. I've been meaning to rewrite setkeys/keyval for a long time. > --- > James Introduction: Frame rate, script tick rate, logic rate, and key repeat rate are all currently equal, but we'd like to decouple some of them. frame rate : rate at which the screen is redrawn, including recalculation of slice, camera, npc, and battle sprites positions. logic/animation rate : rate at which NPCs and battle participants react and various things animate script tick rate : normally should be the same as the frame rate so that things like overhead displays work, but I'd like to stick an advanced option in Game (and possibly Custom) so that you can raise the frame rate without raising this, and play the majority of RPGs with smoother camera scrolling and movement. After interrogation of the responsible parties, several versions of the request, and reasons for them were given: -Some people wanted to be able to make the game temporarily speed up or slow down: they wanted to change the logic (tick) rate and the frame rate at once, for a fast-forward effect. -Some wanted to be able to set the logic rate in Custom and didn't care about script commands. -Some wanted it just for debugging, and said that ctrl +/- could be better. It's definitely a very useful debugging tool, but what improvements does it need? -Mike in his email seems to be the only person who actually asked for variable frame rate with fixed logic rate (for example to temporarily increase the frame rate for smooth scripted screen fades), which is what I thought this was about all along, and am against. Way too much complexity for very little use, compared to supporting locked logic+frame rates. About fast-forward effects: These might be supportable easily, depending on how input should be handled, which is not clear. If the key repeat/delay rate is not adjusted, then I can't aren't really see any input problems with supporting this, other than maybe changing the flicker rate of selected menu items. But maybe people would want the key repeat rate to increase t We'd need to add frame dropping, should be easy. Except for games that make heavy use of scripting, the large majority of CPU time is spent drawing the screen (except when someone misplaces a DIM as MenuDef somewhere in the menu logic, anyway), so (because of frame dropping) support for fast-forward is hardly going to increase our CPU requirements beyond what supporting high framerates would do. I think we should still have some limit. However fast-forward support should be a low priority; it's a gimmick. I'd like to talk about how animation rates should be timed once we support other logic/animation rates. Should lengths of frames be measured in ticks, or in number of standard 100th-of-a-second ticks or in fractions (fifths?) of a standard 18th-of-a-second tick? By these last two options, I mean that if your game configured to run at 36fps, then 1 1/18s tick unit of time is two frames, regardless of the actual frame rate (which is affected by system load). How will we support changing the frame rate in an existing game, or exporting an animation from one game to another? Those last two options make this easy; however they are more awkward to use, and if a whole number of frames does not fit into whatever is specified (we would surely design the UI to make this a hard mistake to make, though), then the frame time would have to be rounded. The alternative would be to measure everything simply in frames, and scan the whole game and multiply everything by a factor if you choose to change the logic rate. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
