i will concede most of your points on this.. though I don't see how implementing something to keep logic and game speed moving at the same speed, despite display would possibly would possibly decrease the quality of games, but i take your word that you can't implement it and that the two options don't actually do anything together in MMf2 (I couldn't really test it due to the lack of scrolling in the game).

That said, while I concede your point about input windows, it was more serving as an example of something possibly ending up working weird on a time based scale. When I refer to 'precise' i mean that i will arrive to the same conclusion every time and that I can predict what will happen on every frame. i agree that slow down is in no way elegant or desirable, but I wouldn't describe it as imprecise. Right now if I were to decrease a value in respects to time delta, I couldn't for example safely do my whole 'equal' statement thing. I'm of course very glad to hear that timers will work fine, but I wanted confirmation.

Anyways, I would describe this as imprecise. I cannot be sure what the variable will be when it crosses the the desired number, and even if i set a range, frame rates of 30 or 15 could skip right over it. Can I work around it? Sure, and I am (thank you too for the reassuring information i needed to do so), and i'll be fine... but I still will be sad not to have that sort of comfort.

Anyways at this point this is mostly semantics (so no need to argue , I'm just clarifying what -I- think of as imprecise... I mean, unless you really want to ;P). Even if i don't like the few cons that exist, the pros are still very desirable.

Anyways, I think I'm good for now, as long as timers behave right (and they seem to). One small thing. I might have some other concerns at a later point regarding this, but i'm going to wait till i can test them before assuming the worst. As always, thank you for your patience with my stubborn ass.

Edit: Oh and faggatron gives a good example of what I see as impercise. Fortunately though my engine seemed to be mostly okay with the change over.

> Secondly, shouldn't there be a way to the game adjust automatically? I'm used to hearing good technical reasons for why things can't happen around here (so I'm expecting a 'no'), but I still have to bring it up just in case. I didn't have to do anything like this in Multimedia fusion 2, I could simply set the game to skip frames instead of slow down. I'm going to imagine that most of the FPS problems for most games are on the rendering end -- isn't it possible to still run logic for 60 frames while only updating things visually at a more sustainable frame rate? Or if not, some other solution?

>

I can't think of a way to automate the timedelta adjustments. The built in behaviors ideally would do everything you wanted, and with a timedelta based engine, but I guess we're not there yet. And as faggatron said, the engine can't tell the difference between continuous and one-off movement, so it isn't really possible to add it. I don't think it is a complicated thing for users to code, even if it is frustrating to retro-fit it on to a tick based engine - I think TimeDelta is an appropriate and good solution to the problem. For example, running events at 60FPS and displaying at 75FPS means at some point you display the same frame twice without running any events, so you're not actually genuinely achieving 75FPS. It would be pointless.

I can't think of any reason you wouldn't want to use a V-synced display for games (other than complaining about TimeDelta!) and I can't think of any legitimate uses for anything to be tick-based in Construct. It should all be based off real seconds. That's technically the best solution, which results in best quality games. If MMF2 doesn't implement it, it doesn't mean it works fine, it still suffers from all the problems of tick-based engines. I say this a lot, and I'll say it again: use V-sync, and use timedelta based engines! It's the only way to design a game that isn't going to tear the display, and isn't going to run at different speeds for different people. If you have a fixed framerate, your games will look ugly because they can't V-sync. And if your game slows down due to poor hardware, it will start crawling along reaaallly slow. Timedelta engines keep the gameplay going at the intended speed even if the system can't hit V-sync framerates.

The whole premise of a fixed framerate is flawed because if a user's system can't achieve that framerate, nothing you've coded runs at the intended speed. You can fix your framerate at 60fps if you want, but someone's old PC might end up running it at 20fps anyway! Do you want the game to run three times slower than it should for them?

I'm not out to shout you down here or anything - I just think there's a clear case for never using fixed framerate and always using V-sync. I might even add a warning dialog if you choose a fixed framerate. It's not suitable for games. TimeDelta is not a difficult concept and game designers should go to the trouble of learning just a little about it, in order to design games which are fairer, better quality, and more professional.

Convinced?

it's not that I'm necessarily unconvinced -- which is why I am currently working toward this end -- it's that I think the situation is suboptimal. With the added stability and sensibility and just overall goodness presented by Construct, this is a trade I'm willing to make.

I just checked in MMF2 and I Can V-Sync it while insuring machine independent speed -- well, within reason. At really poor frame rates (15ish?) the game does slow down, but whatever (who's going to play a game at less than 15 frames per second?). IWBTG never really needed it so i never bothered, but it doesn't seem to do anything to the logic of the game. I just get less frames per second.

So the way i'm looking at things, what are they doing that you can't replicate? Pretty much everything else in construct, if not already superior to MMF2, is being on the track to soon surpass it. Anyways from my experience, it's not that objects are moved in a deltatime-ish fashion when subject to slowdown, but that logic is handled separately from display. if i have a value increase by 1 every cycle and a 60 frame game is only running at 50 frames per second, I still end up with 60 at the same time.

Anyways, I'll be okay. I'm just speaking for what I think would be beneficial for construct and what, from my end (which is limited, as I do not have the knowledge to understand the constructs source) seems like it should be, in some way, possible. In the end, I'm just giving my feedback, which you can do whatever you want with.

I will miss the precision of doing things tick based though and will be very happy if you DO come up with a way to handle this -- but if not, I don't doubt you'll be working on plenty of other great things. I'm just giving my two cents as someone who is serious about making games and has some experience with other software and a good idea of what he'd like to see in the hopes of both bettering construct and my own game. I just hope some of the stuff is helpful feedback and not headache inducing griping.

> I don't have a good way to drop or boost my frame rate,

>

Set framerate mode to unlimited to boost and fix it on like 20 to drop.

> Anyways, my question is whats the best way to keep a decreasing value in sync witht he actions on screen? Especially since the (every X) action doesn't have the resolution to try and match 1 tick in 60 frames. I can do it for 20 milliseconds which might be close enough, but not as smooth. Is there a better way? I can use delta time of course, but I fear dealing with these values as decimals. Thoughts?

>

cant you just use timedelta then use int(x) where you need it? (Construct's never really given my any problems with using floats for anything apart from using the % function)

I was playing IWTBTG because someone mentioned it. (you're a bastard

Heh, I forgot Fixed Frameratewould actually work BECAUSE of delta time. I'm just used to it slowing down the whiole game. Anyways the problem with decreasing by a float is when I use "=" statements in my timers. I guess I could handle this by checking for rounded values... But another example is the strings I use to detect the fighting game-esque inputs. Basically when they're running they look like...

'**,*,*,*,*,*,*,*,*,*,*,*,6,2,3' with the * representing the countdown before the input window has expired and the numbers representing directions as if on a num pad (a notation we fighter fags love, even though I could just make them all one character with the way the command reader works. ). Anyways, the string slowly decays with each element of the string getting eaten every tick, until there are no more *s. When that happens, you have ran out of time since your first input to execute the move (In this case a Dragon Punch/Shoryuken). It basically defines how fast you have to input the entire motion.

Obviously I can't delta time this, but doing it at 20ms besides per tick would work, though I'm not sure what sort of random elements this might introduce.. For example, the input window dropping by one frame/20ms since the last two characters end up getting eaten before the next frame shows. At 30 fps, this would be highly likely. A variance of 1/60th of a second isn't problem inducing (especially if the input window is reasonable), but its the time of imperfections I worry about when dealing with delta time.What if I NEEDED it to be exact?

I worry about this crap too much.

Okay, I've made a deal of progress, and it seems most stuf is up to par. But since I don't have a good way to drop or boost my frame rate, I can't test a few things so I want to as another timing issue (someone should just rename this thread to something more accurate XD).

Anyways, my question is whats the best way to keep a decreasing value in sync witht he actions on screen? Especially since the (every X) action doesn't have the resolution to try and match 1 tick in 60 frames. I can do it for 20 milliseconds which might be close enough, but not as smooth. Is there a better way? I can use delta time of course, but I fear dealing with these values as decimals. Thoughts?

I don't think time delta is a 'problem'. Most people who are going to move to a custom path should be able to grasp time delta. I do and for a basic platformer engine or something like IWBTG, I would be able to handle it. The problem arises now because I'm doing something and demanding a lot of precision from it. The more I think about it the more I think I can convert it to work. Anyways, a few things.

First, I'd suggest a command along the lines of 'move object by time", which will move an object to whatever coordinates over a length of time. This doesn't accomplish anything that can't be handled now, but would address the needs of many people working on the behavioral level and would simpify some stuff for advanced users. Doesn't help me with what I'm doing, but I think it'd a good 'accessibility' thing. (also have a tick version plz )

Secondly, shouldn't there be a way to the game adjust automatically? I'm used to hearing good technical reasons for why things can't happen around here (so I'm expecting a 'no'), but I still have to bring it up just in case. I didn't have to do anything like this in Multimedia fusion 2, I could simply set the game to skip frames instead of slow down. I'm going to imagine that most of the FPS problems for most games are on the rendering end -- isn't it possible to still run logic for 60 frames while only updating things visually at a more sustainable frame rate? Or if not, some other solution? I mean, it certainly has been done before, but I can't be sure the limitations presented by the way Construct is designed that would allow/disallow certain solutions.

Construct can certainly live with timedelta,that's for sure, but automating things like other game makers have would certainly go a long way on helping along more advanced construct functions while not confusing lower level developers.

Anyways, I'm going to go play with converting my engine to see if it'll work. Either way I'll live, but I hope my suggestions are both workable and desirable.

Edit: Oh and don't worry Jayjay, I already hijacked my own thread.

V-Sync introduces a lot of issues currently. Such as the frame rate dropping and attacks still moving at full speed. I'm planning to see how implement delta time, which would make V-Sync work fine.

Dashing in the air isn't realistic, but neither is double jumping or even jumping 3 times your own height. BUT ITS CERTAINLY FUN! Anyways, a running attack might be a decent idea I'll definitely consider, though I have to consider how it'll interact with other moves.

I've been thinking about that, actually. I think the best thing to do, especially to get feedback on the way I'm doing things and how they can be improved, I need to stop being a sissy marry and post that shit up (it's not like anyone can steal anything anyways)... So

Here it is!

Hopefully now I can get some real opinions.

Well, I figured I should post this up, especially after having some discussion with delta time and other issues (since right now it runs under constant 60 fps rather than V-Sync).

http://kayin.pyoko.org/enginewip.

What does this engine do?

* Custom platform engine

* Variable based motion customization

* Double/triple/whatever Jumping and wall jumping (hold away from the service and press up)

* Dashing and air dashing (which dash momentum) by double tapping forward on the ground or air

* Back dashing! (press away twice in air or when crouching)

* Attacks with the Z key! Standing, crouching and jumping! (With two more buttons worth of attakcs PLUS command normals being implented)

* Buffers and chain combos as well as jump cancelable normals! (Air JCing doesn't work 100% yet)

* Technically you can do QCFs and SRKs, but you won't hear the sound involved since it's not included. They don't do anything, but if you check the code you can see how it works.

This is on the way to a metroidvania with fighting games mechanics. So.... I dunno, I'm open to any ideas to clean up the code or implement stuff like delta timing or whatever.

Seriously. Ashley's right. I tried various framerate tests, and when switching between monitors, it not only looked like utter crap at another refresh rate, but it played wrong too. Timedeltas are the only way to go to ensure a consistent play experience on multiple machines. What's more, timedelta's really easy to implement. Instead of Set object x position to "sprite.x +1" it's "sprite.x +(1*timedelta)" to get it to move one pixel per second. Want it 60? Use 60*timedelta. Easy.

That is a vast over simplification of the issues presented to me and I do not dismiss timedelta lightly. If only everything I'm doing is as easy as moving a sprite by X.

First of, no behaviors are being used. Things actually run very consistently for me on different computers and monitors (even though there is occasional tearing), since there is no real conflict between time based and delta based events. Everything is custom movement -- and perhaps the basic section of movement would work with delta time, but things aren't that simple! Types of movement (dashing or sliding) is based on ticking down timer. These could both be delta timed, but now the counting variable is a decimal, and it's now harder to track when it reaches certain values (I'd have to approximate the range it might span and risk things going off twice blahblahblah), Moves can combo and gatling into each other and variances in decreasing vales can cause unexpected things to be able to link (even if it's off by a frame).

EVERYTHING has to run on the same time scale so EVERYTHING has to use delta time. It's not like a basic game where the logic is simple collision issues where it doesn't matter if they trigger out of sync with movement. This is a serious logistical problem that is not as simple as "use delta time". Even if I do decide to go crazy and try and work out a way to delta time to work, it is far from simple (unless Ashley tells me it really is that simple and I feel done. By the way Ashley, the bug file I sent you is an older version of what I'm talking about. So you can look at it to get an idea if I'm full of shit or not if you feel compelled, because an expert opinion on this would be helpful). Even if I got it to work, I'd still feel weird inconsistencies.

Anyways, thats why I'm considering all my options.

Now, to digress my own topic. Okay - I've been using Constant Framerate because I guess I'm really really anal about things working the same way every time. While using delta time to fix general movement speed wouldn't be too hard, I'm going to venture a guess that I'm probably working on one of the most complex construct games at this time (since I'm dumb and am not waiting for 1.0 ) -- while also not being the most qualified person to do it.. Thus creating what will be a huge, unwieldy engine held together by duct tape (Perhaps I'm too hard on my self. :O)! Anyways, delta time would have to be applied to pretty much every event and I'd have to worry about variables that used to have a clean, whole number progression changed to decimal progression (can't use = anymore :<) and blahblahblah. Could it be done? I'd guess 'Probably' -- but not by me!

Anyways, I did some testing with V-Sync to see if the timing issues with refresh rate is really that bad. Perhaps something was wrong on my end, but it seemed like instead of trying to run at 120 frames per second, it just tried to sync up as closely as it can (Interlacing frames?). Now if that is right, running V-Synced wouldn't be that bad, speed wise (I'd rather things be faster or slower and work consistently than let things possibly playing differently on other machines). Problem was, animations were still moving at the same speed they normally would, which is hella bad for me, because I key some events to the timing of animations (Attacks, generally. Most other stuff isn't as important). Now if I could realistically make the engine run at full speed on any engine this wouldn't be an issue, but as I've pointed out above, I don't believe that is realistically feasible.

So now I have some things to consider...

Do I try and work delta time into the engine? (noooo ;__;)

Do I make my own animation engine to run animations on a per tick basis? (Would be obnoxious to do, but no reason it shouldn't work)

Do I keep developing at fixed rate 60? (Oh god I wish that was the best option)

OR

Do I beg for an option in a future build that can set animation to a tick based timing, rather than a delta timing? (I like this one a lot and I think there is a case to be made for a feature like this!)

And just for the hell of it, any way we could eventually get an option to turn vsync on and off in game? I think this would make a useful option in a games setting screen, though I could always just compile two different EXEs. Not a huge deal, but I figured I'd ask while I've digressed this far, even though I'm guessing 'no'.

Anyways, sorry for being long winded and probably coming off as stubborn!

I've been wondering how the 'speed' setting actually transfers in real world time. I can't really test it (since step by steping it makes animations break), sdo instead of trying to work out some weird other test out at 5am, I figured I might as well ask so I can get an answer from someone who actually knows what they're talking about by the time I wake up.

I'm GUESSING that the number relates to how many frames play in a second and if I want to run one frame of naimation ever one tick (running at 60 FPS) I would set animation speed to 60. That said, if I set it to 100, are animation frames culled?

Alternatively, 100 could be one frame every frame (100% speed).

Or it could be something completely different. And if I achieve 1 frame per tick, I can assume that adjusting the frame speed, I can finely set how many ticks a frame of animation is displayed (frame speed 5 for 5 frames, for example)

Basically I want to know how fast to run an animation to get exactly one frame every tick at 60 fps The rest of the questions are just curiousities and clarifactions.

Thanks in advance.

> Would be nice to have gravity on ball behavior. Sometimes ya just want some bouncing, and physics are overkill. <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

>

But they are already!

> I'm pretty sure most people know what and how the filter thing works. It should never be a replacement for a replace colour for another colour though, it would be quite a waste to have to separate many parts of an object just to change a single colour.

>

Ekhem <img src="{SMILIES_PATH}/icon_rolleyes.gif" alt=":roll:" title="Rolling Eyes" />

Let me rephrase, as I foolishly misspoke. ADJUSTABLE GRAVITY. Sorry kids. <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" />

Would be nice to have gravity on ball behavior. Sometimes ya just want some bouncing, and physics are overkill. <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />