On 13 January 2011 01:13, Ralph Versteegen <[email protected]> wrote: > 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
Opps, sorry for the confusion (I was confused when I initially wrote this): animation frames should of course be calculated per-frame, not per-logic-tick. Scratch "/animation". > 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. If it sounds like I'm contradicting what I said earlier about adding an option for smoother scrolling in old games: my objection is to adding a script command to do this, though the complexity is probably the same; I should have stuck to my original future-compatibility justification. > 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. Mistake: that's nothing to do with input, of course. > But maybe people would want the key repeat rate > to increase t to increase as well, for example if bullets are fired at the repeat rate. But we don't need to support this. People can emulate it by scripting their own repeat rates. > 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
