Game timing - am I way off the mark here?
BlitzMax Forums/BlitzMax Programming/Game timing - am I way off the mark here?
| ||
| Ok so here's my situation: In my current project I am using a fixed logic + graphics update of 60hz. Up until recently this has worked great and has given me the Amiga feel I've been looking for. However recently, I am throwing around a lot more sprites than I first thought, and while it's fine on my Core Duo machine, it is struggling and jumping down to 30hz on my aging G4 1Ghz, a machine I'd like to be around the minimum spec. I am very far into my code at this point (it's almost finished). I have kept the rendering seperate from the sprites movement, which gives me some flexibility. What I was thinking was simply to detect, using Millisecs(), the time elapsed since the last redraw, and if it is greater than 1/60 of a second to simply run the logic again before redrawing. Is this technique feasible? Or would I still have to implement delta timing? In which case, what is specifically involved... I know there are several topics about this, but I'd like a roundup, in simple terms, of your various strategies, and especially information from anyone who's had to add timing code at a late stage of development. Any help would be greatly appreciated - my only alternative is to raise the system specs for my game, eliminating a large part of the market. |
| ||
| Even if you raise the system specs, people with crap machines will still download it. I'm a bit dubious of the technique you mentioned but hey it's worth a try. Also have you timed the drawing and logic, it's definitely the drawing that's taking the longest on the slow machines is it? |
| ||
| Yeah I'm pretty sure it's the drawing rather than the logic, although I haven't timed it. I have multi-layered maps, and the jump to 30fps seems to occur when I have an extra layer there, rather than more game objects. I'm just worried about using delta time at this stage because I have so many game timers and separate physics routines that I'd almost definitely screw up if I switch. Also as it's a platformer I'm concerned about things like collision and jumping height varying with delta time. Really stumped on this one, this area's definitely not my forte. |
| ||
| Ok perhaps I'm phrasing the question wrong... Let me put it another way: 1. What are the alternatives to delta time? 2. If none of them are viable, what is the best way to integrate delta timing to an already bloated codebase, and what are the potential pitfalls? What exactly need to be multiplied by dT? Sorry to pester you with this, I'm just kinda worried about it. Oh, and thanks once again Grey for your swift response. |
| ||
| If you can get your head around it, render tweening is just about the best timing method you can find. It has all the advantages of delta timing with none of the disadvantages. Namely, it still runs at the same speed on all machines ( whether they're too fast or too slow ) but because the delta is fixed you don't have to use a delta multiplier and the tweening makes it perfectly smooth. You do need to use floating point values for all your positions though in order for it to be smooth, but that's true of delta timing anyway. |
| ||
| Drop your frame refreh to 30. No one will really notice, that is whatever it was giving you the 60Hrzt change it to 30, then you get twice as much graphics you can draw. |
| ||
| Sorry Sonic, been away. Well there's always fixed rate logic which does more logic loops to catch up if the drawing too too long, hand on that's what you described in your first post. you can also chuck a bit of delta time in there too to make it smoother (it's what I do in my game framework). I have often linked to a web page about it called "Fix your Timestep" or something but that link is on the PC and I'm on the Mac now. I've never used render tweening so I can't comment on that. yeah basically to use Delta you need all game coordinates as floating point and all speeds as floating point. Anytime you move an object by a certain speed, that speed must be multiplied by delta. If you alter an acceleration (rate of change in speed), that must be multplied by delta. If you have any timers or counters and your reduce/increase them by say 1 every frame, then you need to change them by 1*Delta (or just Delta) per frame and naturally the counters must be floating point. Finally if you are planning on making random events happen you might want to read this: http://greyaliengames.com/blog/oops-dodgy-random-numbers-with-deltatime/ hope this helps. good luck. |
   |