> 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.