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