I chuckled a bit, seeing the warning message for overriding time delta, though it's certainly true. Thanks -- I probably won't get to play with it for a bit though (though I'm going to try).

One thing though that I don't like is that, as far as I can tell, I can't set the override at run time. I'd reallyreallyreally like this feature eventually, though I don't really need to worry about it yet...... Though, I could just use Set Timescale to get the same effect, couldn't I...? I'd test it instead of asking, but I'm in the middle of the woods right now.

Either way it'd be nice to have it seperate -- for organizational purposes, though it could easily be worked around. Thanks though, I'll be glad to be able to get back to work on the engine.

Well I think most issues where such a feature would be useful would benefit more from a case specific solution than a general solution as suggested -- though it's a very neat one!

Ah well, though. That sounds fair enough.

random feature that could be useful. "Object Completely Overlapped by X". I know theres times I wish I could do this to detect things like ledges and the likes. I think it would be a much appreciated feature!

I tested it on 4 computers and 2 fixed frames. Two out a range of 100, the other two were more reluctent to make large jumps and put out about 50 eventually. 2 laptops, and 2 desktops. So it seems to vary between systems to an extent but most will probably be capable of producing these anomolies when struck with low FPS.

Granted with the time delta override this is all a moot point.

Okay, as I suspected, real FPS loss is a factor here. In for example, when running a game around 20-30 FPS, it's not unusual for there to be large, quick dips in the FPS. When running the game at 1-5 FPS, there can be skips as large as 30 pixels.

When setting to fixed rate 30, the frame rate isn't likely to drop like this, since you probably have more than enough power to maintain a consistent frame rate. But in the real world, dips like this can cause huge discrepancies.

So with a 'fixed' delta time, this isn't an issue and you can set a the frame rate and set minimal speeds and ignore sudden dips.

As for high speed objects, I doubt that'll be a problem, as long as the frame rate/delta time stays consistence.

That sounds excellent, but some more things to consider. I think the reason I'm getting bigger numbers when it comes to test is because, unlike say, using constant 15 fps, my 15 fps environment is 'real'(as in the computer is set to not be able to catch up)In situations around 15-30 FPS, frame rate is very unstable, causing, I think, further innaccuracies are caused through this, such as the big '32' pixel leap with that one test.

So what I would recommend is a way to get the real time delta, even in this mode, and further a way to SET the artificial time delta. so in this situation I could 'update' the artificial time delta to match the display to get proper speeds and, even if it does cause some differences, these differences will be consistent and more predictable/testable. Heck, I could even have it 'forbid' certain exact time delta values that would allow a timer to overrun for one tick. I could even have it update periodically in 'safe' situations, such as when the player grounded. I could even give the players an option on how slow down effects them (instead of doing two builds, IWBTG style).

I like this solution a lot. While it's not as precise still in that different delta times may act slightly differently (which I can potentially solve!) it gives a lot of useability options I like and a lot more control over how frame loss is handled (if you like my idea of course). I think you'll like it too, though, as it gets rid of the factor of variable speeds.

Thank you Ashely, I'm glad this thread reached a comprise that is in everyone's benefit.

Jeswen: Well remember,this is the default options for jumping. You jump, I dunno... 300 pixels? Maybe less, but it's a lot. If someone is making a retroish game I'd imagine the variance would be quite less. In fact, let me test this

(Insert testing)

Okay, maybe not. at 500 jump strength I got a variance of.... .. 10 pixels. Granted this didn't happen in subsequent tests, but this is the stuff I worry about. Either way, its probably still less likely.

(edit: Oh, I see. XD Ah well.)

Arcticus: I did testing on this subject already. As has been explained in the obnoxious amount of text, time based movement can suffer from differing amount of movement and jump height based on FPSs. If you don't rely on behaviors, things will sync up perfectly frameby frame. Of course, Ashley has stated many disadvantages to this, that I think stand true for most developers.

Ashley: Clearly you never played IWBTG! As it stands I would not be able to make a similar game, as it was a game with a lot of pixel perfect jumping and traps. Granted it's also a very silly game and a design philosophy (or lack of one

Anyways, about timers, wouldn't possibly looping the event twice when necessarily be good for keeping things in sync? This point is more hazy to me then other ones, but it's just a thought.

As for the 'waste of processing', in a way I'm going to disagree. I think you're thinking on a very display oriented manner. The wayI look at it, the logic has to be run anyways. Its an exact system. Much like having an event run every 20 ms, I want all my events to run 60 times a second. Granted some people don't need it to be an exact system, but as constructs user base grows, I believe the demand for something like this will increase. I mean, I can think of things in three ways.

You sacrifice visuals and speed independence for exactness (me right now)

You sacrifice exactness for for visual, speed independence (What most people would be good with)

You sacrifice performance for exactness, speed independence and good visuals. (What I'd prefer)

You're concerned about the quality of construct games visually, but with constant fps mode, you give an undesirable out for people like me (and those in the future). With a third option you maintain the visual integrity, at the sacrifice of performance. Sort of a middle ground approach.

Much like the idea you had to have a warning prompt when selecting constant FPS, you could simply go over the costs and advantages of each mode and by all means, say standard V-Sync is best. I actually do think its a better fit for most people, but the 3rd option will be very usual when people realize the power of construct as a game development platform. I'm sure you're worried about the option being an 'easy out' for some people, but as of now, the 'easy out' is Constant FPS, which has numerous disadvantages, but will likely get used anyways. I certainly will be if I can't get a time delta system that works to my requirements. Again, I don't think I'll be the only one. So please seriously consider this. Discourage it as much as you want when you select it (probably a good idea), but I think having a system that delivers the maximum amount of flexibility to the needs of developers while maintaining visual integrity is in everyone's best interests.

> An issue here, for example, is the need to alter the timing on a frame by frame basis. I could, say, make a string variable for each animation that stores the right information and then play it off.I know I can do it, but it'd be nice if I didn't have to make all these alternatives to features already in construct.

>

I don't mean to sound flamey here, and I definitely don't mean any disrespect... but if you can do it, then why don't you? Ashley has stated his case for why Construct is made the way it is. You're asking for a rather fundamental change to Construct's engine, and all for a problem that's very specific to what you need done (and no one else).

The level of precision that you're seeking is something that I think only God and a handful of fighting game enthusiasts who can think between animation frames would appreciate. The kind of players like my ex-roommate Karl who own their own fighting game stick and carry it with them on the bus to the arcade to practice for tournaments. Not that there's anything wrong with that... he was really friggin good.

Anyway, my point is this: If one is seeking a change to the way Construct works, and one is in the minority of users who need this change, and this change can be accomplished with events, then the logical answer is to just make it with events.

Such is the burden of specialization. It takes more work, and fewer people appreciate it.

I don't mean it as a fundamental change, but as a possible option. If it were too much of an undertaking, I wouldn't fault Ashley for not implementing it. Also your room mate sounds like me. My stick just happens to be right next to me right now, and I went as far as making it my self (with help) out of aluminum. So I admit, in a lot of ways, I'm on the obsessed side.

But I do thing the issue in variable jump height, even in the default behavior, is problematic. Its a big deal when someone can or can't jump some where, and more problematic when things can take a more sudden jump randomly. I think this a rather important thing to address.

Anyways, fortunately I'm not working on anything currently where I need to worry about whither or not I'm going to switch to time delta later or anything, so I can wait to hear what can or will be done if anything. I'm prepared to do what I need to, to make a good game. I don't want to shoot my self in the foot, but I don't want to shoot my self in the head either.

[quote:131hqgya]strain the fps

Just a quick tip - set a fixed framerate of 15 or so in application properties. It's a nice way to simulate a low framerate.

[quote:131hqgya]On consistent FPSsof 60, the cubes mostly behave properly and stop in the same spot every time. Sometimes they're off by a pixel, with the Yellow being most consistent.

There are inaccuracies in a timer based game. Ticks will not fall on the same timer values every time. For example, if you have "Timer less than 50 ms" as a condition, the first execution could have tick 5 falling at 49ms (condition evaluates to true), or tick 5 falling at 51ms (condition evaluates to false). This is the difference between running the actions either 4 times or 5 times - resulting in a maximum error of one tick. So you can calculate the maximum possible values of motion etc. in your games: over 50ms that's a maximum of timedelta summing up to 0.05, and if you move at 100 pixels per second, that's a maximum of 5 pixels covered. Any errors will result in a smaller value - so you can ensure the player cannot reach locations they could not otherwise reach. It does bias advantage to the higher framerated players - they are less likely to have their values reduced by these one-tick errors - but it is a subtle variation. You can do a few things to get around it too - for example, if the timer is greater than 50ms, set the position to the maximum possible distance. You'll have a box that moves across at a uniform speed and always lands up in the same place. A few more events, yes, but I am pretty sure this is how commercial games do it as well.

In other words, the error is small, only ever reduces from the maximum value, and gets smaller the higher the framerate. I know you might feel differently, but I think a level of imprecision is going to be inherent and necessary in all games. If someone's crappy PC jumps 7 pixels short I don't think the game is THAT unfair, and I doubt anybody would ever notice either. And I doubt your game requires you to pole vault on to 5 pixel wide platforms!

It may seem nice in your mind to be able to calculate the precise values that occur over a tick based game, but I doubt a 10 pixel error would ruin your game, and it'll be a smaller error for the 95% of us that can achieve a non-hilariously-bad framerate. In a practical sense, I doubt it matters. Do you think the player can reliably perform the same actions to within a 10 pixel accuracy? And the advantages of using a v-synced timer based game are huge.

I've said everything I can to try and persuade you to avoid tick-based code - and I'm sorry to insist, but I don't want to implement features that might encourage people to go down a tick-based route, because I really think it's a poor way to design games. I want Construct users to be guided in to making well-designed games - even if it is slightly more difficult!

And no, of course this is nothing personal and I'm not offended by anything you say. This is a technical discussion, and I'm just trying to convey the pros and cons of both ways

I am very sad to hear this. I really feel strongly as a game developer working on an imprecise scale is acceptable, but I respect your disagreement. As much as I would like to V-Sync the game, consistency is far more a concern of mine. Perhaps I'll do a little more testing to see if I can reduce the variations to something I find tolerable. But would you at least humor me with two answers.

1) You said precision in time based events will be improved in the next release. Does this mean I can perform time based activities on a much faster scale -- say, reducing each burst of movement from say.. 6 to 1 or 2, to try and minimize the variations?

2) In what way would separating logic and display be either impossible or undesirable? It seems to me most games run in this way and would have the benefits of both tick based precision and computer speed/FPS independence for V-Syncing. I want this suggestion to stop haunting me.

If you're really that hard set on tick-based animation, there's nothing stopping you from doing it.

Set your animations to no loop, and 0 frames per second. That way they won't auto-play on their own.

Then make a custom tick-based animation routine of your own, manually setting the animation frame when you need it. I can't imagine this would take more than a handful of events.

An issue here, for example, is the need to alter the timing on a frame by frame basis. I could, say, make a string variable for each animation that stores the right information and then play it off.I know I can do it, but it'd be nice if I didn't have to make all these alternatives to features already in construct.

Anyways it's not that I'm set on a tick based system (Or else I wouldn't keep going back to pull my hair our and mess with this stuff), I'm set on precision. I want things to play out the same way every time, regardless of speed. This is more important to me than tearing or playability at low FPSs, though these things are ALSO important. Right now I'm finding my self stuck between a rock and a hard place and I'm more hoping Ashley will seem the same problem I do and will have some sort of solution. I'm totally willing to work with timedelta at this point, if it can supply what I need.

(I still think the idea (until Ashley tells me why )

Okay, last post till I get a reply. I just did my last bit of testing for now, but under enough strain even the build in platform behavior varied, sometimes as much as 10 pixels (!!!). 14-15 frames per-second is a pretty rough time but I saw variation in the realm of 3-5 at 30ish. This is very problematic in my opinion overall.

Honestly that is currently a deal breaker for me. My gut says I should accept zero variations in jump height or time based movement. My realistic mentality says I can suck up 1-3, though it's more the rare high end that worries me(People getitng to places they aren't supposed to yet due to lag is worrisome to me, especially if there are larger, rarer jumps).

I make a plea that, if you cannot address these issues (and for most people I'd imagine this isn't a breaking issue), I quietly beg you for a way to allow animations to move on a tick scale. Currently I'm using time delta (Ironically) to figure out the FPS of the game and setting all animation speed to that, which works 'okay' but I'm sure it has to be flaky in some ways. I'd rather take speed inconsistencies between machines then gameplay inconsistencies by a LOT.

(But i'm hoping you actually acknowledge and address the underlying issue instead)

As always, sorry for being a pain in the ass.

(Sorry for the triple post -- you should consider allowing edits at any time, but I would just like to apologize if I'm coming off as harsh, because I'm just quite frustrated with all of this and I do not want to sacrifice quality. I am actually still experimenting with Time Delta and completely rebuilding parts of the engine, but still, the above has me very concerned. Sorry again. )

... And my concerns begin to rear their ugly heads. For now I'm ceasing all work to convert to VSync/Delta Time.

But I will not do so without showing WHY, in hopes that I am either missing something or, if there is a problem, that it gets addressed with an adequate solution.

http://kayin.pyoko.org/hatevsyncmode.cap

The actual test is the two cubes at the start. It's put in the engine as to help strain the fps. As you can see if you bother looking (no need) the delta time implementation on the actual engine is probably pretty sloppy. I was sort of messing with ways to try and make it work smoothly at low FPS, when I noticed some inconsistencies. Not sue if these were a result of me missing something, I made the test (three linesof code at the bottom). Fortunately for me,when I unplug my laptop I can throttle down the CPU, allowing me to test at much more flaky FPSs. Some of you might not be able to test this as I imagine a lot of people can run it at a high, stable FPS, but the results are real.

On consistent FPSsof 60, the cubes mostly behave properly and stop in the same spot every time. Sometimes they're off by a pixel, with the Yellow being most consistent.

At lower FPSs, (30-45) they stop in different directions. The Yellow one is still the most consistent (Though not consistent enough in my opinion) and the blue one is often radially off. Using R to restart the event, occasionaly even the yellow one stops as much as around 30 pixels too far.

This is totally unacceptable in my opinion, and these are very simple examples. I cannot risk inconsistent jumping distances or anything else. I think I can tolerate tearing and slow down (my actual preference, personally), over these issues.