Framerate Dependant mode?:

The game I'm working on now is a puzzle-platformer/shmup'. After a good bit of thought on the mechanics of the game, I've come to the conclusion that it would be better to have it slow down than to skip frames/lose accuracy.

Since most of C2's behaviors are built to function framerate independantly, this has caused me a bit of a conundrum. Here's what I've come up with, placed in context of basic mod of the shooter template(arrow/wasd to move, mouse: look, lmb:fire, rmb:alt fire).

The relevant part is event 4 (and, also 5) bracketed by comments with DELTA-TIME BYPASS (sounds like a dr who plot device...<img src="smileys/smiley5.gif" border="0" align="middle" />) in CAPS:

dropbox.com/s/jhrzbidknfb0f7h/GiveAndTake_TimscaleExperiments_1.capx

I guess it's pretty self explanatory: divide the current fps with the intended fps, then multiply the timescale by the result. This seem to work great on my end, but I'm wondering if anyone else has tried this, and if it's a reliable approach?

I also tried setting it by a framerate average of the past three frames, which seemed to work okay, but was more prone to some occasional herky-jerkyness from the inherent lag.

Also, Ashley: would you consider adding an option in project proprties for a framerate dependant mode? Looks like CC used to have this: it was called "override TimeDelta". I know most games that would need this are physics based -- and in that case, the option already exists -- but there are those of us who would prefer slowdown to skipping. Pretty please?

Cheers, Tim

Well...okay...this one didn't seem to go over very well. <img src="smileys/smiley24.gif" border="0" align="middle" />

After more testing, I've come to the conclusion that, while the above approach works, it's less than ideal because of the inherent lag. It's still my best bet, as far as I can tell, but it definately doesn't produce consistent behavior.

Ashley, not trying to nag, but would a framerate dependant mode be possible? I'd just like to know one way or the other.

Cheers,T

Yeah, this would be nice. I'd really like to be able to rely on Construct's in-built behaviors with out having to craft my own just to get around delta time. ;-;

I mean, it feels like the idea is that eventually computers will be fast enough that this won't matter, but right now I'm having trouble on a fairly fast computer whenever I try to stream or there are random FPS spikes / lags... and I can't even begin to imagine how awful it'd be on mobile platforms.

Once again, I totally respect where Ashley is coming from on this, but since we're not in the age of everyone-having-a-fast-computer, would be nice to have this as an option for devs like us who don't mind the FPS slow down and want consistent behavior.

Actually, this has been a blessing and a curse for me. I coded my own event-based bullet movements, and got much better performance than the built in Bullet behavior. However, there are other behaviors I'd like to use, but can't due to the delta time thing. It's frustrating...

I understand delta-time, but find it really annoying. It reminds me of when a digtal tv signal breaks up, or lag in an online game...somehow, it just sets my nerves on end WAY more than simple slowdown.

That being said, I understand why delta time is useful, and would even advocate its use in certain games and circumstances. It's not a 'One-size-fits-all' solution, though, and trying to avoid it obviates some of the most useful functions in construct.

Sigh...

Going to go ahead and bump this and request a frame-rate dependent mode for the various behaviors that move objects. Collisions in the game I'm working on fail at around 15 fps, and while I don't intend for people to play at that FPS, I don't want this to be a viable mechanic for cheating since I want to include things like rankings. My game is unplayable at 15 fps anyway since it relies on crisp control.

A setting to allow us to set the minimum frame rate to something else (currently it's 10 fps according to the docs) would be great and I imagine simple.

Juryiel

Did you take a look at my capx in the first post? It's sort of a hack, but it doesn't work that badly. Actually, I think you could do something similar with dt which would probably be more reliable -- currently I use the fps to modify the timescale. But I haven't tried it yet.

https://www.dropbox.com/s/jhrzbidknfb0f ... nts_1.capx