More On Timing, Or No Timing...

what about not using any delta or fixed tiiming... what would be the consequences of your game if you just had a straight main loop, with no timing code whatsoever?

i've been doing some testing, and it appears that the stuttering issue i was having seems to disappear when i take out the fixed rate timing code...

--Mike

Wouldn't it run at different speed on different systems if you dropped all timing code. I remember playing a tank game that felt more like a rally game as it ran about 3-4 times faster on my machine then it was supposed to. Was kind of cool playing it that way actually. :-)

Ragnar

yes it would. No timing is utterly lame and totally unprofessional. I'm not even going to tag on "imho" to that because it's fact UNLESS your game is for a console or 8/16 bit home computer.

Even on those homecomputers there are upgradekits for a faster cpu.. :P Timing must be! No compromises!

Yes, one of the games I remember as having no timing restrictions on it is the original Theme Park.

Which runs fine on a P100 (or whatever machine was out at the time of release) But as processors became faster, the main loop could be processed faster, and as a result the game is completely unplayable in a moden machine now (as its so fast you loose before you even start)

They didn't even put in time code stuff in the 'Gold' release for Windows.

Same with the other way, if you play you game on a 1ghz PC and you have been developing it on a 3Ghz PC is will be more than 3 times slower (I made that figure up. But it just a ballpark thing)

Just to note, there are some places where you shouldn't (or don't have to) use timing. Servers and some Applications for example.

What's your fixed rate timing code like? You've mentioned it a few times now but I don't think we've seen it yet. Best thing I ever found explaining it was this:

http://www.gaffer.org/articles/Timestep.html

thx for all the input on this... it seems pretty apparent that some sort of timing algorithm must be part of the code...

ooops, i missed your post HC... here's what i've got so far... part of my OOP engine :)

( the mods are gonna kill me for making work for em... i didn't mean to turn this into a code thing, just to get some opinions )

  ;----------------------------------- main loop starts here
  ;      
  ;                    				   the game timer controls the speed of the logic
  ;                   				   and is separate from the video refresh timing
  ;
  Repeat


<b>    FPS=WaitTimer(GameTimer)			
    For k=1 To FPS
</b>
    
   ;------------------------------------ continually call each objects update() method here
   ; 
   ;
   ;							         add a new case select for each new class in the game
   ;									 so that its update() method can be called by the main
   ;									 loop
   ;
	For  obj.tObject=Each tObject
	  Select obj\subClass
	    ;------------------------------ default player updating     - DO NOT ALTER
	    Case "PLAYER"
		      UpdatePlayer(obj)
		;------------------------------ default sky updating        - DO NOT ALTER
		Case "SKY"
	      UpdateSky(obj)
		;------------------------------ default ocean updating      - DO NOT ALTER
	    Case "OCEAN"
	      UpdateOcean(obj)
	    Case "REFLECTION"
	      UpdateReflections(obj)
	
	    ;------------------------------ default game logic updating - DO NOT ALTER
		Case this\Title
	      theGame(obj)

	
.YOUR_UPDATE_FUNCTIONS
	    ;------------------------- ADD YOUR NEW UPDATE FUNCTION REFERENCES BELOW AS A CASE CLAUSE
        ;                          THESE POINT TO YOUR NEW SUBCLASS'S UPDATE FUNCTIONS 
        ;
	    ;                       ==  YOU MUST COMMENT OUT OR REMOVE UNUSED CLASS REFERENCES  ==   
	    ; 	
	    Case "BOUYANTBOX"
	      UpdateBouyantBoxes(obj)	
	    Case "SPLASH"
	      UpdateSplashes(obj)
	    Case "GATOCLASSSUB"
	      ;UpdateGatoClassSubs(obj)
		Case "ACTOR"
	      UpdateActors(obj)		

	    ;
	    ;-----------------------------------------------------------------------------------------
	
      End Select
<b>
	Next
   Next

</b>

    RenderWorld

  ; ----------------------------------------render text
  ;
   For txt.tText=Each tText
      If txt\txtString<>"" Then Text txt\x, txt\y,txt\txtString
   Next
  
  ;----------------------------------------- video refresh   
  ;

   If theGameObject\VSync=1
      VWait:Flip False
   Else
      Flip
   EndIf
   FlushKeys

  ;
  ;
    If KeyDown(1) Then theGameObject\Quit=1

Until this\Quit=1  

simple... straight forward... almost right out of the manual :) but, when i move to slower or faster machines, i get stuttering in the movement of the subs...

*** added ***
i just tested it on a 733mHz machine, and it does appear to run a lil slower, but it does so in a well behaved manner... no stuttering at all...

help me out here... i'm really missing something...

thx


--Mike

Here's mine:



While time.Update()
....logic here
wend



Literally, thats it. Pretty special magic happens in my time module.

The best is like console : locking the refresh ( 60hz + vsync) and code the game. With this methode, your game could be shmooth, more time for the computer betwen each flip ( and less cpu use, intead of a vsync off ), and the coding should be simpler.

...

reno... that sounds interesting... and in DBPro i use this...

how would i do this in Blitz3d... vwait(60)??

--Mike

you can't lock it in B3D, that's a Max thing. Happycat's article is the one I based my fixed rate logic with extra smoothing on. Did you try my framework demo Red? I wonder if you PC is running background tasks that cause mini delays and thus the same frame is shown say twice and then timing has to catch up in the next frame thus moves it more.

Red: Most games will need timing. Just look at how many old DOS games are unplayable today because they play too fast. You can get away with no timing in games like Chess, etc, but most games, you do need some form of timing.

Even the latest demo is jerky as hell on my systems :c(

Kuron: but totally smooth on mine, and improved on tons of others. There is nothing wrong with the timing, I can say that 100%, the jerking is down to BlitzMax and your hardware Sorry :-(

Odd, I have no problems with jerkiness in BMax or in the many BMax games and demos done by others I have downloaded and played. Nor games made with any other language. My hardware is 100% not the problem and it is rather arrogant for you to say so.

thx guys for all the input...

GA... ahhh, so locking the sync rate is BMax only... ok...

yeah, i took a look at your demo... runs smooth even on a fx5200... testing it now on a 733 mHz radeon 9200... and a 6100...

--Mike

Kuron: I've got to say shut up dude, of course it is the hardware/drivers. How come the timing is fine on a whole bunch of PCs, but not ones with certain Geforce cards then? Also some people have reported that shutting down background tasks stops the jerking. Furthermore some TFTs show stuttering and others don't. Are you experiencing jerking or vertical tearing, do you even know the difference? Some cards show vertical tearing and others don't, how can that NOT be hardware/drivers then? My timing routines don't affect Vsync! I have been researching this stuff every day for around a month now and tried tons of tests on tons of PCs. You are the arrogant one for thinking that your hardware is not the problem, you're in the same boat as millions of other PC users i.e. non-universal-standard hardware meaning developers can't write games that behave the same on all PCs, no matter what timing methods they use, sad but true. However I've been tirelessly trying new techniques to try to improve matters on some systems with various workarounds. I've already worked with Skidracer and others to fix and improve 3 major problems, what have you done except moan? Come back when you have some useful information ...

Red: Glad it worked fine, my timing is based on Happycat's article link. It took a while to figure out but it works very well imho. I look forward to hearing how it works on the other PCs too.

Red,

Any time I've tried to use deltatiming or frame tweening it's jerky as hell so I never us it anymore.

I lock the FPS in Blitz3d like so ..

global FPS = 30
global Timer = Createtimer( FPS )

while .....

 waittimer Timer
 ;update stuff
renderworld
flip

wend

On faster machines it will never run at more than 30 and on slower as fast as it can.

Stevie

thx StevieG...

that's pretty much what i'm doing now... i was mistaken when i said i took out the timing... in my code above i had an additional nested loop for some reason... what i wound up doing was removing just that, and it seems to be working fine across the board...

BIG THANKS to all...

--Mike

Hey, Ant,way to lose a potential customer, lol. If you are going to play store and sell a product, you need to be more mature and quit the condescending attitude.

In this case, no. I have no problems with tearing or jerky graphics in BMax. BMax and other BMax stuff runs fine on all of my systems as does everything else.

The only thing all my systems have in common, but as noted all other BMax stuff has run fine so far. If BMax itself (demos included, like the zombie for example, or countless demos and games released) doesn't have a problem on any of my systems, why should your demo?

What moron would try running a game with background tasks going?

We had a couple of those when I worked at Microprose, they were awful. AFAIK, TFTs still suck for gaming because of their slow refresh rates. I don't use them.

Jerking. Yes, I know the difference.

Bmax still has some major issues, but I have never run into jerking graphics until with your demo.

Yeah, Delta timing never worked right for me either. Its not a case of me implimenting incorrectly, its more a fact of some measurements get to precise for delta timeing to accuratly keep synced.

I use a frame lock similar to Stevie however I let certain logic continually update during the wait time (IE network, input, etc). Some systems can continue to work in that few millisec time while others (like entity movement, physics, etc) you want at a constant rate so as to keep it smooth.

Perhaps I am way off base.

Glad you got it sorted Red :-)

I'm a bit confused by

FPS=WaitTimer(GameTimer)	
For k=1 To FPS

but as long as it works now :-)

The majority of pc owners.

You see, technically savvy people are a hideous minority.

you were never a potential customer anyway, one minute you winge about prices, the next say how good it is. Are you bipolar? The Zombie demo has NO timing code in it at all, it's just fixed to a 60Hz flip. I can't be bothered with you any more, go and find someone else to annoy.

Feature list is GOOD! Implementation still seems to need some work. Rob has posted eamples that work flawlessly (as all other BMax stuff does) on my system.

That was my point. It seems in BMax the more people try to mess with timing, the worse it becomes. I really don't understand it as B2D/B+/B3 were fine DX wise and I never saw issues such as these reported.

Prices are VERY fair for commercial releases, but overpriced for people wanting to write freeware. If it worked properly on my systems would I buy it? Yes, if BMaxs other issues ever get fixed by the BRL team.

@HappyCat...

yeah... that ws the part that i wound up taking out ( i was confused also )... now it looks like it's working right...

--Mike

Unfortunately that's the problem coding for the PC - each machine is slightly different. So we have to jump through hoops to try and make our software not only run at the same speed on all computers - but make it run smoothly as well (which is much more difficult).

It seems there are several ways of doing this...

1) fixed frame rate - ie lock the main loop to some figure - such as 60FPS (16.66 ms). This only works well if the user runs their monitor refresh at 60Hz - but it doesn't allow any other processing of logic (such as AI) and doesn't allow for the fact a slower computer might not be able to keep-up.

2) Fixed logic - run the logic at a high rate - such as 200FPS and scale to whatever the user's PC can handle. This can produce some smooth programs, but running your logic 200 times per loop can effect lower spec PCs quite badly. But for simpler games this shouldn't be a problem because the rendering takes the longest amount of time - not logic. Faster PC's should be ok though.

3) Delta-time - run logic just once per loop and multiply your movement by the amount of time passed - the quicker your PC the smaller the movements and the smoother the program runs. However, it's tricky to get it running well on all systems and all games styles - collision detection can also be tricky.

Hey Red, Tweening tutorial:-
http://www.blitzbasic.co.nz/codearcs/codearcs.php?code=1497

Good summary Steve. I prefer option 2 personally, esp. if the logic is very efficient.

Just curious. If you run a game at a fixed framerate say 30fps, which should be enough to get reasonably smooth movement, will you get into trouble if the users screen is not set to 60hz, 90hz or 120hz, but for instance 72hz or 85hz which is not a multiple of 30.

Ragnar

One note on timing. To avoid stuttering you can't use the
current calculated delta for your timing you have to
average the timing over a couple of loops in the game.
If you have a spike in the delta it will show up during
that loop. Averaging smooths the delta to compensate for
a spike in the last loop. The only stutter you won't be
able to do anything about is the udates to the gpu from
DirectX and you see that in all commercial games unless
you have a pimped out system.

ragtag: yes, it will look naff, sometimes things will move one frames worth and other times two frames worth so they'll look jerky.

thx JB for the link to the tweening stuff...

good read Steve... i'm going with solution 2 as well... well, at least at the moment i am :)

--Mike

The only reason to have delta timing is that you might do more processing for a frame than there is time to do it based on when the flip should ideally happen. It is an attempt to put a band aid over the fact that you don't have enough cpu/gfx power. As such it can only ever be a half-measure. The gfx will jerk and the motion may not appear smooth. You can't expect anything more. Either that or get a faster computer, or design your game so that it doesn't `do too much` on most systems, so it can stay at 60hz or whatever. In the old days, Amiga etc, games were designed to always run at 50hz and it was considered very important that if you were aiming for 50hz there was NEVER any slowdown, and features would be designed or taken out to maintain that situation. These days games seem looser and not so aimed at consistency so they don't worry about it and hope their delta timing will fix everything. Delta timing is just a fallback for possibly poor design or just underpowered target pc's.

yeah it's a shame isn't it. Blitz was more fun on an Amiga ...

Trouble is, you can't be sure what features the end user even has enabled. I mean, everyone has different preferences, so some people are going to turn on all the fancy features even though the framerate will suffer, while other people are going to strip down the visuals in order to have a smooth framerate. I mean, you refer to designers removing features in order to preserve the framerate, but that just wouldn't fly these days. You gotta put in the feature and then leave it up to the user to decide whether or not to turn it on.

This of course assumes your game allows the user to change the graphics settings for the game, but if you are designing a PC game (ie. not a static platform) then you probably want to allow that.

As for delta-timing being jittery, what ice9 said. You gotsta average out the frame times in order to smooth out the delta-timing. Personally I don't bother with frame tweening or fixed logic or whatever just because delta-timing is much simpler conceptually (to me anyway) and gives just as good results.