Mark's frametweening code - 60fps or 20fps?
Blitz3D Forums/Blitz3D Programming/Mark's frametweening code - 60fps or 20fps?
| ||
| Hopefully someone can explain to me how this frametweening code mod works, or more importantly, if I shouldn't do it. For the code in the box below, if I leave it as it is (this is how Mark's example code is) I get 20 to 30fps on my 2nd crap test PC. However, if I change this line - ;game logic loop
For frameLimit = 1 To frameTicksto this - ;game logic loop
For frameLimit = 0 To frameTicksI get 60fps. So, what I want to know is, why does this happen, and why is the original frametweening code set to 1, and am I messing something up by changing it to a zero? I have noticed that on a really simple program that puts no load on the system, changing the 1 to a 0 causes it to behave a bit erratically, but on a full program it almost doubles the framerate. I am confused as to why. thanks James |
| ||
| The FPS should be based on the number of flips per second, I don't understand the logic in your method above. |
| ||
| The purpose of this code is to determine how many update ticks should be run to catch the game system up with how much time has actually passed. If the game system is already caught up, the number of update ticks will be zero and the same game state will be rendered. Tweening allows multiple renderings from the same game state to appear to be moving correctly. By forcing the game to run an extra game system update every frame, (by changing "for 1" to "for 0",) you have forced the system to calculate game system updates into the future. The system keeps coming back with frameTicks=0 (or even negative numbers) because it knows it's already worked out enough game logic and it's time to render another frame. Secondly, as skidracer pointed out, you are incorrectly interpretting the FPS. FPS != gameFPS/frameTicks, and certainly not = gameFPS if frameTicks = 0. gameFPS is simply the desired FPS of the game. You cannot accurately calculate the FPS of the game by using a constant you choose yourself. P.S. Those variable names hurt my brain, I know you probably didn't come up with them. |
| ||
| OK, the code I use is the same as the original frame-tweening code posted in the archives by BlitzSupport, and according to his comments is the best system available - it is here - http://www.blitzbasic.com/codearcs/codearcs.php?code=9 I haven't changed anything about it, but I did miss off the gameFPS constant from my code example - it is set to 60. You cannot accurately calculate the FPS of the game by using a constant you choose yourself I understand this, it gives results of either 60fps or 30fps (60/2 using integer maths) but it does all work the way I want, and apparently the way Mark wanted also if you read the archives post. Skidracer : according to the code archives, you reckon this method is the best available - Simon Armstrong ('Skidmarks' developer) describes Mark's code as 'the Bible' on 3D frame-tweening, so you *know* it doesn't get any better than this! ;) ..so I don't see why you don't understand the logic? Was it just because I missed off the CONST gameFPS = 60 declaration? From what I can see by debuglogging the variables in the code archives example, frameTicks alternates between 0 and 1, so the loop should drop out straight away about half the time (when frameTicks=0). If I change the 1 to a 0 in the loop, frameTicks alternates between -1 and 0, so the loop should again drop out 50% of the time (when frameTicks=-1). So why does one method give 60fps and one 20fps, with the game playing exactly the same in both methods? I still don't understand this very well.... If someone has some different frametweening code I'd be very interested to see it. |
| ||
| Oh hold on, now I see - if I change the 1 to a 0, Captureworld() is only called every other loop, so the system presumably has half as much work to do, which would explain the double in framerate. Hmm, so that means that the rendertweening is only using updated captured info every other loop, with the physics and controls etc.. updating every loop, so the visual update positions etc.. must lag 1 frame behind the actual physics, but only every other frame. So that explains why the game still runs the same, but the rendertweening is only having to do half as much. Captureworld() is not being called 50% of the time. Well that seems OK to me, seeing as you can't tell the difference in the game but it runs twice as fast. According to the docs - CaptureWorld 'captures' the properties (position, rotation, scale, alpha etc) of each entity in the 3D world. So I don't do this every other loop, the tweening just uses the old positions and lots of time is saved in the main program loop. That seems way too easy...perhaps I am overlooking something here??? |
| ||
;calculate FPS If (frameTicks>0) FPS = gameFPS/frameTicks Else FPS = gameFPS EndIfAs you've been told before, this code is entirely incorrect. All of your assumptions are therefore based on flawed measurements. I haven't changed anything about it This isn't a valid reason to ignore what people are telling you is wrong with your code. It's also not true, as the above code is not found in the link you posted. Use a conventional method of measuring FPS. |
| ||
| RENDER TWEENING TIP! May I suggest from my experience, that you better put a cap on the frameTicks... because when you alt+tab away from the game and return a minute later the system tries to catch up and the whole thig freezes. Try it :) Almost no-one takes this into consideration. It would be good to add this in the code-archive entry. Add this line... If frameTicks>7 Then frameTicks=7:frametime=MilliSecs() (I use maximum 7 updates per render... but you can use whatever you want.) before the... For frameLimit = 1 To frameTicks |
| ||
| Use a conventional method of measuring FPS. Please show me how then. |
| ||
| Inlude the code in your game... Just call the fps function in the render loop to get how many real renders per second... easy. |
| ||
| OK, I'll give it a try, thanks. |
| ||
| Hi Vorderman. You might want to take a look at this: http://www.blitzbasic.co.nz/codearcs/codearcs.php?code=1497 |
| ||
| (from John Blackledge's post) Someone suggested that the variable 'ticks' might sometimes be zero, and that this would be a bad idea. So I added: If ticks<1 Then ticks = 1 before For k=1 To ticks Do NOT do this! I think that this was the reason for my characters 'speed-walking' every so often. As soon as I removed it the problem went away. I guess it's a case of 'trust Mark's code'. I find it quite strange that two people so far have wanted to fiddle with the ticks calculation. Your time would be better invested in understanding the original code. It's not terribly complicated. Allow me to try to explain, and feel free to ask questions: It renders as frequently as possible, updating the game as many times as necessary to keep the GAME (not the graphics) running at gameFPS (which should be called gameTPS - ticks per second.) The graphics will run at the fastest FPS possible. After every render, it checks how much time has passed and determines how many game updates (ticks) need to be calculated to bring the game back up to speed. It's all about keeping the game running at a constant speed. If the game updates are taking a long time to calculate, several game updates may need to be done before rendering (ticks > 1). If the game updates are not taking very long to calculate, there may be time to render a single game update multiple times (ticks = 0). Frame tweening makes rendering the same game update multiple times look good. |
| ||
| Thanks for that explanation. Obviously MY explanation in the tutorial was totally wasted ;-) |
| ||
| But I still like to remid that there is one flaw in the original Mark's frametweening code... and it's the thing I brought up a couple posts earlier. You all should really cap the maximum amount of ticks... or you'll be doomed when someone alt+tabs. |
| ||
| Can't disagree with Bouncer - that really is a pain. You need to seriously restrict alt-tab or detect it and allow for it. BTW my tutorial was written 2 years ago. Don't just hammer me (or Mark), but please feel free to to rewrite / update that code and repost it. As I've so often stressed, at the time I was using a lot of animated characters, not running and shooting but sauntering and talking, so any glitches on a slow machine would really show up. I found that tweening was the only system that provided smooth continuous animation, even on a dog-slow jerky machine. |
| ||
| Anyone wanting to PREVENT Alt+TABbing can check out my dll in the Block Intrusive keys Userlibs thread |
| ||
| ... which does of course beg the question should you suppress alt-tab? We're in 2005 now, multitasking has been a reality for a decade for PC's (longer, on other platforms). I think it would be far more ethical to allow for alt-tab rather than suppressing it. |
| ||
| We should also move past the 'double-post' feature of web forums ;) |
   |