Timing Code Made Easy?
BlitzMax Forums/BlitzMax Programming/Timing Code Made Easy?
| ||
| Any pitfalls to using this code? I found it in the awesome "Annihilation" game source code. When I did some sprite tests, the animation was a little more jittery compared to my delta logic, but for someone who wants a fixed logic framework, this might be ideal. |
| ||
| What's it like with Flip 1? |
| ||
| Runs fine with Flip 1. The usual jitter is there ofcourse. I've emailed the person using this code in his games and asked him to verify: Basically it seems it does the following: If render speed is faster than logic speed, then it (repeats until) enough cycles have passed to compensate. If render speed is slower than logic speed, then it calls the UpdateLogic() function enough times to keep the logic flowing at the requested speed. Is that how it works then I can see why it would work for just about any situation. I will probably end up having uses for both styles of timing. |
| ||
| I think that code is a version of the other fixed logic code elsewhere on these forums. I did once think that there was scope for a universal timing module where you set TIMEMODE=xxxx where xxxx = FIXEDSTEP or FIXEDSTEPTWEEN or DELTA or FRAMELIMIT or CUSTOM1 or whatever. |
| ||
| This version has no tweening. It's alot easier to comprehend and code. I've done some tests with this and my delta methods, both give very useable results. Flip = 0: Delta time yields smoother animation. Fixed logic shows more jitters. I don't have jitter correction for fixed logic so this could possibly be improved. Flip = 1: Both can produce smooth as butter animation when rendering at monitor refresh rate. When render speed is slower than the monitor refresh rate, fixed logic can introduce the jitters because there is larger movements between frame renders. Coding: Delta is capable of producing better results on higher end machines due to there is no capping on the logic or render rates. However fixed logic has it's advantages mainly because it's easier to comprehend and code, resulting in quicker development time. Big& confirmed my thoughts on how the fixed logic code works. So it really comes down to coder preference. Both options are valid for game design. Do you want to code with "every x number of frames do this" or "every VARms that has passed do this". :) |
| ||
| http://jgoware.com/mge/mge6.zip The above demo shows the fixed logic code in use. Press 1 or 2 to slow down / speed up the logic rate, which ofcouse speeds up or slows down the moving objects. You can also run it in full screen or windowed, vsync on or off. You probably won't see too much jitter in full screen with vsync on because it's not taxing the gpu at all. But when the render speed is slower than the logic speed, that's when the jitts show up. ;) I have to admit, this seems like a very doable way to code a game. Now I'm all confoosed. lol.. |
| ||
| Tweening is easy as pie - http://www.blitzbasic.com/Community/posts.php?topic=70516 Your example is fixed steps, but if framerate is faster than logc you're rendering same stuff until you catch up, this is where linear interpolation comes in. |
| ||
| Hi HN, yep, it's in fixed steps, but it's oh so very easy to code, just like the old days. :) lol.. The linear interpolation is really cool, but the idea of saving a before state for 100's or 1000's of objects seems daunting, plus when using algos that use sin, cos, patterns, offsets I can see where it would require alot more preplanning, etc. If I was coding an engine for 1 game I could see where tweening could be implemented from the group up, but not too sure if tweening should be added to a general use / prototyping engine. Do you have any finished demos or games that use this tweening method? Would love to see tweening in action in a real world app. Thanks. |
| ||
| I used the exact method in the first post for my Blitz Plus games, it was called the Retro64 method at the time when I got it off the forum 2.5 years ago (wow). So I've used it for all the free games here: http://www.greyaliengames.com/free.php and also for my commercial titles Xmas Bonus and Easter Bonus, and basically it was fine. BUT on really slow machines the logic can take too long and it spirals into anout of control catchup loop so I limited the number of ticks in order to make the game slow down to catch up instead. For my BMax titles, I used a combination of Fixed Rate Logic AND DeltaTime (I explained this in a recent thread). For my next game I've added Jitter Correction. It's pretty much the best you can get I think - very smooth (on certain PCs ;-)) I've never used Deltatiming on it's own because I like fixed rate logic (from Amiga days). Also I've never used tweening as I felt that drawing would be over complicated. |
| ||
| Yah, the top post seems to make the mose sense logically. Except I'm a bit confused where the jitter correction code would be added in the loop? And if you add a delta to the logic update, does But all of these styles seem to work about equal when running on good hardware, the fixed logic method runs the risk of more jitterness on very slow machines, but again the ease of fixed logic coding perhaps out weighs that. Good stuff, thanks for your thougts GA! (I can't help but like your Orion shooter, jeesh I love games like that!) ;) |
| ||
| you seem to have cut off your sentence about delta time there. Anyway, All Jitter Correction is you keep an array of previous time differences per frame and if you get a big difference one frame you don't catchup that whole amount, you catchup the average amount instead. Yeah Orion is cool but doesn't do much yet. I made a DOS version in C++ and assembler that did more. One day I'll make a good one just for fun. But I'm too busy right now trying to make a living plus these days there are tons of great freeware Japanese bullet curtain shooters. |
| ||
| weird on the reply being cut off... Yah, that's the exact same principal I've been using in my delta timer, but..... holy loopty loop, I've added support for fixed rate logic in the same loop as my delta timing. More experiementaion in usage is required, but it could be the "missing link" in my engine. Instead of processing input every loop like delta time usually does, now I can say "process input at every x fps". So I end up having a delta time logic loop and a fixed rate logic loop. It all appears to be running fine, however the old noggin is working overtime comprehending all this! lol.. p.s. Oh yah, lots of nice Japanimation shooters. :) :) :) |
| ||
| Here's a demo of delta (everything moving, animating, etc) and fixed logic (inputs, player/enemy shots, etc). Would be great if a few of you could run the demo for me, thanks! Clicky |
| ||
| Are there any inputs or controls as it seems to simply display a black screen which cannot be exited without a reboot. |
| ||
| Looks like I'd better wait a bit before testing this... |
| ||
| I don't blame you GA, so would I!! wow, very sorry TonyG... unbelievable. This is the kind of WTF? that I had with VB6 and DirectX, I tested it on all 3 of my test boxes before uploading it and referencing it here, it worked fine on those boxes. Why on earth this would not work is beyond me. From one coder to the next, I can guarantee there is nothing special in this code at all. Looks like I need to do some more Blitxmax compatibility research before I start pouring some serious development resources into this language. Very frustrated over this. |
| ||
| Ran it again. First, your input box has Fullscreen : Yes or Cancel This time I took the Cancel Option which I'd guessed was Windowed mode (and easier to get out of in case of problems). VSync : Yes or Cancel I took the Yes option (and later the Cancel option) Things displayed OK and all seemed smooth. I don't really want to take the FullScreen 'Yes' option again. |
| ||
| Thanks Tony, much appreciated. Full screen is 800x600x32, probably not available on your box? |
| ||
| 800,600,32 is available and works OK with my Bmax programs. |
| ||
| runs fine on my system |
| ||
| I'll test it later, I just have Bmax open, email open, code folders open, spreadsheets open cos I'm working on my game. I wanna close everything safely in case I need a reset. |
| ||
| @Tonyg - strange that it's not working for you in full screen mode, thanks for trying. @HrdNutz - thanks! @Ga - No prob, don't do anything until those biz apps are closed!!! I've got it posted in the showcase section to get a show of hands if it's running or not. So far it seems to be running ok. It was mainly a test to see if the animation was smooth enough for games, I'll have to bump up the overall system checks to make sure the graphics request is valid. ;) |
| ||
| Works fine here in full-screen + windowed. And totally smooth (but then everything is on my PC). 20FPS and 30FPS don't look so hot of course. I noticed you are plotting the stars at integer coords. I love the explosions, very nice. You've mixed an anim + particles right? |
| ||
| runs fine on my system I love the explosions, very nice. You've mixed an anim + particles right? love too these explosions. i'm interesting to know how to add this to my project ! How to do this ? MGE could you post info about this ? |
| ||
| I used a combination of Fixed Rate Logic AND DeltaTime Yep, that's what that Gaffer's Fix Your Timestep article is. It combines FRL and DT and if I read it correctly it has jitter correction in it too. That article has helped a LOT of people. |
| ||
| Thanks for checking this out! Tech wise, this was just an experiment to see how the new delta + optional fixed logic coding would work. I've had quite a few people say it's working good enough, so now I can continue on. whew! Thanks again. @GA - Yepper, an anim + particles (sprites) for the explosion. Each explosion is 64x64, 32 frames. This demo has 2 different explosions. The stars are var double not integer, but I think the Plot command converts to int? @hub - Thanks for checking it out. The anim/particle handling is built into the sprite engine. Hard to explain but very easy to use. Check out the blog for on going dev progress. @Chroma - It has certainly woke me up on the subject, given me lots of ideas to play with. Good stuff! |
| ||
| i'm interested by the source for the explosion to adapt it for my game (not really the sprite engine, just particle/explosion). Could you sell only this ? When have you plan to release your game engine ? |
| ||
| ah yeah probably plot rounds, DrawLine certainly does. I thought that article has fixed rate logic and tweening not Delta time and no it doesn't have jitter correction in it as there is not "history" stored of previous time differences. |
| ||
| Yep, that's what that Gaffer's Fix Your Timestep article is. It combines FRL and DT and if I read it correctly it has jitter correction in it too. No, it isn't, it doesn't, and it doesn't in that order. The timestep is fixed so there is no need to use a delta multiplier. It combines FRL and Tweening. It doesn't have jitter correction, but that's because you don't need jitter correction if you do it properly in the first place. You only need jitter correction if you're A) doing your timing wrong or B) ( reportedly, I haven't witnessed it as I don't use it ) using Max2D, which seems to have problems when background tasks are involved, which don't happen in other engines. |
| ||
| This looks pretty complicated but here is a simple way to think about it. After the deltaTime has been added to the accumulator and the physics steps of size dt have been performed, if the physics and display fps are not integer multiples of each other, then some time will remain in the accumulator. This remainder is effectively a measure of just how much more time is required before another whole physics step can be taken. For example, a remainder of dt/2 means that we are currently halfway between the current physics step and the next one. A remainder of dt*0.1 means that the update is 1/10th of the way between the previous and current states. Yep, he's using DT. Maybe not in the traditional sense, but it's in there. So, yes, it does combine FRL and DT techniques. And if we need to throw in some tweening to keep you happy, we can do that too. ;) |
| ||
| Chroma: He's not using delta time in the traditional sense because otherwise it would be passed into the logic, it is in fact being passed into the draw in order to do tweening. Gabriel: Hey I said that already ;-) but it's nice to have some backup hehe. Yeah basically B) is true, trust me, I've spent *long* enough looking into this stuff. However, jitter can occur because of i) background tasks consuming too much time (or even your own game having a logic or draw spike) and then the timing tries to catch up all in one go which results in a JERK which Jitter Correction helps to reduce by not catchup up in one go ii) millisecs is an integer and thus you'll get stuff like 15/16/17 millisecs between frames (at 60Hz) and your objects will move proportionally to that and occasionally you'll see some tiny "moire" effect on the movement because millisecs is "rounded" and thus hangs around on millisec too long or skips ahead to the next millisec a fraction too early. Jitter Corrections uses the AVERAGE of 15/16/17 and thus you can remove that "moire" effect - at least I managed to. Hope this makes sense. OK I'm kinda all timed out... My timing code is the best it's ever been and people can find out how I've done it by reading all my posts or buying my framework ;-) |
| ||
| Hehe, there's plenty of timing examples around without having to shell out $55!! :p |
| ||
| absolutely, that's why I'm not writing about it any more, it's all been said and done many times |
| ||
| poor me, I bought a framework only to know how the "retro64 timming" works XD |
| ||
| well of course the timing is about 1% or less of the framework :-) |
| ||
| I gotta say that there have been many people putting a lot of effort in timing solutions ever since B3D. but I don't think anybody (at least on these forums) has put anywhere near the effort that Grey has for BMax. You can find his posts about this (and the people helping ) going back years. I myself have used Mark's B3D tweening code in B3D and a homemade method of tweening for max since it came out. but Max really does seem to make it harder (than B3D) to keep perfectly smooth code. But Grey's anti-jitter demos look real good for helping that.... |
| ||
| has put anywhere near the effort that Grey has for BMax I disagree. Every BMax game that's been made has a timing solution. So a LOT of people are doing it right imo. To give credit to just one individual is a bit arrogant. Because it all started somewhere in the past and all this latest timing code was built off someone else's code. They're all just revisions of what the coding pioneers did years ago when we were just toddlers. |
| ||
| That's the beauty of coding, there is no such thing as "THE" way to do something. What makes sense to someone else may make no sense to me. :) |
| ||
| Sorry, if I offended you but I didn't give credit to just one individual for all of the timing. Maybe I didn't "give" enough credit to everybody else, but I was just countering what I though was a VERY undeserved rip from you a few posts up. I don't even own his software yet I don't think you are giving him the credit he deserves... I was just pointing out that he spent a lot of time (discussions/tests/code) trying to get to the bottom of some of issues that BLITZMAX seems to have with smooth timing. [edit] So a LOT of people are doing it right imo. and if you have followed these discussions you would know that people have been complaining (even when doing it right) about it not be -constantly- smooth in BMax |
| ||
| Why not test the user's system at start to see what it can handle, and use the appropriate method for their particular case? Or, if you have a 'minimum system requirement' for your game, write for that common denominator so that there is no need for 'slow system' fixes. The downside to this is that if a user has a kickbutt system, he will not see any added benefit. But so what? If your minimum system is, say, 1.5Ghz with a 64Mb video card and 512Mb of ram then you can certainly program a 3.58Mhz Super Nintendo-level game for that... :) If Windows can't provide the required performance, then shame on Windows... Russell |
| ||
| People tend to run games without even checking the min specs. Also for casual games the mins specs probably need to be 500MHzCPU, Win98 64MB RAM, and 32MB Video unfortunately to ensure maximum market penetration. |
| ||
| "people have been complaining (even when doing it right) about it not be -constantly- smooth in BMax" I tend to think it's not a Bmax issue, I've coded engines in several differrent langauges and so far my runtime with Blitzmax is pretty much identical to my past efforts as far as system hiccups, jitters, etc. Remember the overall media bandwidth on these computers can be (P)retty (C)logged. :) lol.. |
| ||
| so have many of us here. I didn't have these issues in Blitz3d or my own dx engine compiled in visual c. there is a lot of discussion on this going back more than a year.... the conclusion has been that BMax seems a little more sensitive to background tasks. Be my guest and rehash it all but there A LOT of past discussions on this. |
| ||
| ^^ There are no bmax specific problems you guys speak of. Only issues are: 1ms timer, and single thread only. Both have workarounds. L2P :P |
| ||
| Well there's also the DX7 lag problem which has now got a fix in the module, that can't be ideal either. |
   |