Signing this thanks post simply because by the time my game is done I will have been the biggest pain in the ass here. You guys deserve all the thanks we can give.

Hm,so I was messing around with time delta again but, as seems to always be the case, I was never satisfied with the smoothness of motion at sub 60 FPS. Then it occured to me, that the sturring frame rate under load tended to jump around a bit which cased the skip. If I used v-sync overrided at an amount around my average expected FPS it was very playable and smooth with no 'skips'. So instead of these issues necessarily "being my fault" or my code(though I'm sure it only makes the problem worse!) it is instead just a natural effect of inconsistent framerate.

So my suggestions!

First, for the average user, I think some sort of time delta 'smoothing' option would be nice, which would simply prevent sudden drops in time delta ( say, using the average of the last 60 frames, so that sudden 10 FPS dip doesn't make things look terrible). I'd also like to do this my self in time ovrride but would need some features to do it.

Mainly Get_FPS (I could of sworn this was in there! if it isn't I can't find it. Get_RefreshRate would be good too because then I could set the timescale to match the game speed for the player on different refresh rates to get consistent speed. I would still like 'Set DeltaTimeOverride" for organizational purposes but of course that be low priority.

Also in the realm of controlling all these things -- would it be possible to have options to turn V-Sync on and off? V-Sync gives some players trouble or causes an FPS hit they can't afford. It would be nice to be able to have an option to let the player decide. I for one never play with V-sync because I like frame rate more in the games I tend to play -- granted once I get my new machine working that'll change (since I won't be strapped for power ), but I know alot of players are in my position.

Granted this might not be possible for all I know, nor would it be high priority since I don't think anyone is even near completing a finished game.

So yeah, come on! Make Time Override an AWESOME POWER USER option by helping users take control of frame rate/game speed more.

Been awhile! Time to push my usual grumpy agenda.

Issues with time delta are, in most cases relatively small. The issue arises at the lower end of the framerate - basically when the frame rate drops from 1-10 under legitimately strenuous conditions. I did a number of posts with examples of this as tested on older machines.

Currently if you want to make a game that requires exactness there is no perfect answer. I tried to beg up and down for a method that would separate logic updates from graphical updates to insure total consistency at the expense of more processor load (Which in my case I deemed to be fully worthwhile and probably wouid also be good for danmaku shooters and fighting games). Ashley wouldn't do it, citing it as wasteful (is not ;_;) but I believe also because it would stop people form using Delta time. And lets be honest, for most games, Delta Time is what the best choice is and for most people a method like mine would more be a cop-out than a legitimate consideration. We got delta time override which is nice but I think undersupported (I would reaaally still like to be able to check a monitors refresh rate, display FPS(I could of sworn you could but I can't find it right now) and stuff. And being able to change the override indpendant of time scale would be nice too).

But enough crying about the stuff I wish I had (and still wish I had, to Ashley's chagrin! )

Anyways, I think a good way to get around your issue would be say.... Not directly use timedelta in your math. Do something like, at the start of every tick, set "global variable whatever" to timedelta. What you can also do in that check is set a minimal 'FPS' speed. If the FPS falls below that number, timedelta won't decrease further. Well it will, but not the actual value you're using. So the game will start slowing time down. If you also set that value to "Timedelta * Timescale" you get all the benefits but also control over minimal frame rate -- and since all the major inconsistencies in game play you might experience only happen on extremely low FPSs, this won't be a problem.

Also a note about extremely low FPS issues.While a game might run above the threshhold the issue is the tendency for a strained computer to have hangups (run mostly 30 fps, occasionally drop super low for a second etc etc). So realistically speaking anywhere from 20-30 FPS this is a possibility if it happens at the right time. So as long as your 'minimal FPS' is above 30, you should be good. I'd say 60 is a bit too strict. But conversely under this sort of setup you can allow the player the option to choose!

I'm thinking of using this my self, since the variance at higher FPS is pretty negligible -- within.. oh, 3 pixels at worst? Realistically more like 1.

Edit: ack. I just realized this wouldn't work for me because I'm dependant on the exact timing of animations. Boo hiss. But it may still work for you!

You know, I'm an idiot and never even though of what 'and' did. I just sort of ignored it for some strange reason. Yeah, nevermind my suggestion. I think it would still be nice at some point though.

Still. REAAAALLY want GetRefreshRate. :<

I was actually thinking of an implmentation of that. While I still think it'd be a nice use the command/input setup that currently exists (since jump and jump2 are really just the same thing, in terms of function, if necessarily I could definitely do something like that. Also good to hear about the OR thing. I had some issues with it at one point early on and just avoided similar situations since.

Yes, you could go "if A is pressed or if B is pressed" on a simple level.

As things get more complicated, event wise, things get messy. I request this because it'd just simply make situations like this easier and would likely mesh well with future joystick support (where both keyboard and gamepad could be be useable at the same time). Not to mention that more than 1 or statement in an event seems to be funky. At least it was last time I checked (many versions ago).

It'd be really nice to be able to set multiple inputs for one action. Sure, you can work around this, but it'd certainly add a lot of code bloat in many situations (such as already ORed events and stuff). Low priority, but I'm guessing not terribly hard to implement possibly. Still something I'd like to see.

ALSO GETREFRESHRATE |:< (;_; I'm not crazy I'm telling you, it's useful!)

On more of a plugin end, someone really needs to get a gamepad plugin going. I wish I had the knowledge to get on that for everyone.

I keep my self pretty busy. I got to school for graphic design and art and work as an independent computer technician (like geek squad only I charge less but make a lot more since I don't have to share my earnings. :3).

Casually, besides making games, I draw (though not terribly well. http://kayin.pyoko.org has my art), play fighting games fairly competitively (as In a travel to tournaments) and basically take up little hobbies here and their like yo-yos, or magic tricks or butterfly knives. Little dexterity hobbies. Right now I'm also learning to solve rubik's cube fast. I'm down to a minute and 30 seconds average. I want to push my self to under a minute average. I don't think I have the time and attention to reach the '20 second' mark. I'm also an active roleplayer and general geek.

The search option when choosing events/condition s also doesn't seem to work -- at least not in the system object. A minor issue, but I always really liked that feature.

one thing i did think though, surely instead of timedelta you can just have whatever constant you wanted?? - then you could change it whenever...

The problem here is the syncing up of stuff like animation, which use timedelta -- or setting time scale or whatever. If stuff like that wasn't an issue, I could just use V-Sync and mode without using timedelta.

edit: but yeah, Ashley's solution is around the lines of what I theorize would work. Though it'd be nicer to have both, since now if I wanna use timescale for the intended purpose, I'll have to do like... precentile, annoying stuff.

Granted I can live with it like this, so thanks. (also still - Get Refreshrate! <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /> )

Yeah. Most math will probably be accurate enough on nice, whole time deltas. The issue again is the dip in frame rate, especially sudden, quick dips.

The general idea is with these features, I have control of when time delta changes, how it changes and how much it changes during slow down. I can set minimum FPSs, add options to adjust how frame loss is handled for the player and a number of other things. This makes overriding time delta a real nice and powerful advanced feature. It gets the job done right now, but I think those few changes would make it awesome. <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

I brought this up before, but to bring it up where it should be, I'd like to be able to set the time override during run time. Also being able to retrieve a monitors refresh rate would be very nice.