Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / TBM Problem

Author
Message
Kryogenik
16
Years of Service
User Offline
Joined: 22nd Sep 2009
Location: Heidelberg, Germany
Posted: 10th Jun 2010 00:34
Link
I added timer based movement a little while ago, but everything got jerky. It runs everything at the right speed regardless of fps, but it's jerky, almost like the frame rate is too low. But it isn't. Anyone know whats up? Thanks

Codesurge is so awesome, thanks Hyrichter.
Back to top
Profile PM
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 10th Jun 2010 01:34
Link
One alternative is to add smoothing. The jerky movement from TBM is exactly why I added smoothing to mine.

Try this code,



Multiply your speeds by factor#.

You'll also want to set your speeds according to your game's scale. Like if in your game 1 DBPro unit = 1 meter then setting your speed to 1 will move you 1 meter per second.

Back to top
Profile PM Email Website
sladeiw
17
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 10th Jun 2010 01:43
Link
Ooh a timer movement thread....

[Runs for cover]
Back to top
Profile PM
Sasuke
20
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 10th Jun 2010 02:25 Edited at: 10th Jun 2010 02:26
Link
sladeiw beat me to hilarity

A dream is a fantasy, if you achieve that fantasy it was never a dream to begin with.
Back to top
Profile PM Email
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 10th Jun 2010 18:37
Link
@Kryogenik,
Did that work for you?

@Sladeiw & Sasuke,
LOL..

Back to top
Profile PM Email Website
Kryogenik
16
Years of Service
User Offline
Joined: 22nd Sep 2009
Location: Heidelberg, Germany
Posted: 13th Jun 2010 18:03
Link
@Kistech Sorry for the late reply/thread bump, but I lost internet for 2 weeks and since I've gotten it back, I can't stop playing TF2 and lost track of this thread Anyway, I put the code you posted into my game, and nothing happens. Everything stands still. I changed it a little so I wouldn't have to go in and change all the places I multiplied something by my old timer variable and change it to factor, but I don't think I "broke" the code. I don't understand how the code works, though. I sort of get it, the way it checks previous factor things to add smoothing, but my brain hurts looking at it. Could you walk me through it? Thanks.
@sladeiw Lol
@Sasuke You'll get it eventually...

Codesurge is so awesome, thanks Hyrichter.
Back to top
Profile PM
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 14th Jun 2010 00:50
Link
Sure, here's a simple example.



Use the arrow keys to move the block around.

The code works like this.

Flast# holds the timer value of the last loop.
Each time you call the function, it puts into Diff# the number of milliseconds that have passed since the last loop.

You then divide the result by 1000.0 to get the proper decimal representation of milliseconds.

Multiplying your chosen speed value by this result will give you the amount the object should move in those milliseconds. So your speed value should be however many DBPro units you want the object to travel per second. The way this is set up, no matter if you decide to control your loop speed using SYNC RATE or by turning VSYNC on, or some other method, your speeds will remain consistent, and will always equal X DBPro units per second.

The loop for smoothing basically just takes the values from the last 30 loops and averages them, so you don't end up with a sudden compensation if the framerate drops and then comes back up. It averages that over a very short amount of time, thus making the movement appear smoother.

How you end up with jerky movement is when a few loops together happen to run really fast, which makes Diff# very small, and the resulting factor is essentially 0.00000. So when you multiply your speed by the factor, it comes out 0.0000 and nothing moves for that loop. The smoothing fixes that.

NOTE: I changed the hitimer() values to timer() in case you didn't have IanM's matrix1utils. If you do have them, hitimer() is theoretically more reliable and accurate.

Back to top
Profile PM Email Website
luskos
19
Years of Service
User Offline
Joined: 28th Jun 2007
Location:
Posted: 15th Jun 2010 04:51
Link
How can this apply to play object and loop object?Excuse me for my ignorance.I try to figure it out but i`m kind of hard learner.The chance to undersand fully how TBM works is to reinvent it, probably.No mather how much you chew it, i need to work for a while with it to understand the concept.So how can be used with above comands?

Where there is a will, there is a way.
I often edit my posts, that`s who i am
Back to top
Profile PM
sladeiw
17
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 15th Jun 2010 14:32 Edited at: 15th Jun 2010 14:36
Link
Can I ask why you use floats for all the timer values and the array etc? Surely you could keep everything integer and only use a float for the final factor value? Am I missing some reason?

Edit: Also, if you do use matrix1 utils there is a handy rotate array command to rotate the smoothing values array.
Back to top
Profile PM
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 15th Jun 2010 18:07
Link
You could use integers for Diff and Flast. The array holds numbers that are less than 0, so that needs floats.

Rotate array would probably make it quicker. As an old programmer, I was going with what I knew first. That will probably be my next optimization.

I would run some tests and see if the animation routines are linked to the framerate, or if DBPro actually handles the animation speed properly no matter the framerate. You can play around with SET OBJECT SPEED until you find the right animation speed and go from there. I don't know enough about the animation system in DBPro, so you'll have to experiment.

Back to top
Profile PM Email Website
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 15th Jun 2010 18:28
Link
If you set the sync rate to 60, and use IanM's timer functions and set a timer resolution of about 5ms, you shouldn't need any smoothing


New DBPro IDE + integrated debugger!
Back to top
Profile PM Email Website
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 15th Jun 2010 19:23
Link
Sync rate should never be set to anything but 0 in an application. Even VSYNC is sort of a hack that wastes CPU cycles. I've used sync rate 30 or 60 to hack out a quick demo because it's easy, but in a full project it should always be 0. Your program should handle the timing of everything else.

Back to top
Profile PM Email Website
Benjamin
23
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 15th Jun 2010 19:32
Link
Tsk, sampling the timer twice for interdependent calculations still, naughty naughty.
Back to top
Profile PM Email
sladeiw
17
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 15th Jun 2010 20:13 Edited at: 15th Jun 2010 20:25
Link
Just for fun I optimized it to use integers. I know your example was for clarity, plus it helps me fully comprehend code if I tweak it.

edit: Needs matrix1 utils now.

Back to top
Profile PM
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 15th Jun 2010 20:16 Edited at: 15th Jun 2010 20:18
Link
@KISTech
Yes, the DBPro implementation of sync rate is not very CPU friendly, but whatever method you use, it is better to limit the program to the monitor refresh rate as no higher FPS will make a difference, and THAT is a waste.

VSync is not a hack that wastes CPU cycles! Internally it simply synchronises the screen refresh with the monitor refresh, and gives other threads a chance to execute in any time left over. What on earth gave you that idea? The functionality is implemented directly in Direct3D, and so you can be assured that it will use the most windows friendly method possible...


New DBPro IDE + integrated debugger!
Back to top
Profile PM Email Website
Indicium
18
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 15th Jun 2010 20:46
Link
Quote: "but whatever method you use, it is better to limit the program to the monitor refresh rate as no higher FPS will make a difference, and THAT is a waste."


You assume that the only result of the program is going to be displayed on screen.

Rawwrr. Sig Fail.
Newcastle is awesome
Back to top
Profile PM
Kryogenik
16
Years of Service
User Offline
Joined: 22nd Sep 2009
Location: Heidelberg, Germany
Posted: 15th Jun 2010 20:52 Edited at: 15th Jun 2010 20:53
Link
whats wrong with sync rate? I understand that if the fps goes down and you don't use TBM, it slows down the game, but if you do, what is the difference? I use sync rate 0 anyway for extra smoothness, but is there something evil about sync rate I don't know about?

BTW, Set Object Speed only allows integers to tell it how fast to play objects, which I think is causing rounding in the speed and making them play too fast, which changes the way shooting works in my game. Is there some other command that accepts floats, or will I have to make my own system with set object frame, arrays, and a function to replace loop object? This is pretty much what luskos is saying.I guess I could make my own system, but I don't want to waste time on it if it isn't necessary. Thanks

Edit @Kistech Oh, I didn't realize you had to give the variables in the factor array values first, must've been the problem.

Codesurge is so awesome, thanks Hyrichter.
Back to top
Profile PM
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 15th Jun 2010 21:30 Edited at: 15th Jun 2010 21:31
Link
Quote: "You assume that the only result of the program is going to be displayed on screen."


No. Whatever the program does, sync (which is the only thing that sync rate affects) should only be called once per frame. Anything which needs to be done more often should be separated from the render loop.


New DBPro IDE + integrated debugger!
Back to top
Profile PM Email Website
Indicium
18
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 15th Jun 2010 21:40
Link
Maybe I misunderstand the sync rate command then.

So you're saying the program will loop the same amount of times each second regardless of sync rate x?

Rawwrr. Sig Fail.
Newcastle is awesome
Back to top
Profile PM
Madscientist
16
Years of Service
User Offline
Joined: 23rd Aug 2009
Location: Between a rock and a hard place
Posted: 15th Jun 2010 22:11
Link
Well what if you set the sync rate based on timers?

If it hasn't exploded yet, I haven't touched it.
Back to top
Profile PM
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 15th Jun 2010 22:32 Edited at: 15th Jun 2010 22:36
Link
Kryogenik, the initial values in the factors array is just so there wont be a brief period where nothing moves because all of the values are 0.

SYNC RATE : If you use SYNC RATE, your program will only execute it's main loop each frame. If there is extra time left over, it sits and waits until it's time to SYNC again. If your main loop takes longer than the time of a single frame, then the framerate drops.

VSYNC : May or may not do the same thing. I don't really know the internals of it. If it does the same thing, then it's just as bad. However, if it does allow your program to continue to loop, and only allows the SYNC command to actually execute at the appropriate time, then yes, it's much better than Sync Rate.

Diggsey, you touched on the very solution that I found to give the best performance out of DBPro. Sync Rate 0 and VSYNC off, and separate the game loop from the display loop.

Game Loop : All object movements, collision checks, image grabbing, and other non-display things are done as fast and as often as the computer can handle it.

Display Loop : All those elements that get pasted to the screen like sprites, images, and text. Then call Sync to show it all.

Back to top
Profile PM Email Website
Duke E
17
Years of Service
User Offline
Joined: 10th Mar 2009
Location:
Posted: 16th Jun 2010 00:31 Edited at: 16th Jun 2010 01:03
Link
Quote: "Even VSYNC is sort of a hack that wastes CPU cycles"


No it does not if you run in dedicated "Set Window off" mode and use Set Display mode to set the VSync.

Quote: "but whatever method you use, it is better to limit the program to the monitor refresh rate"


Also wrong, if you run VSync=ON in windowed mode it will run significantly slower than any other display mode with the same workload (Edit) when it reaches the VSync threshold (Edit).

Test this code.
It will first calculate the workload for running full out unsynced.
Then it will enter normal run mode. You should see it run at the set TargetFPS.
You can now press Space to change the "Set Display Mode" to running VSync=ON in windowed mode, see the difference?
Subsequent Space presses shows the VSync=OFF in both dedicated and non dedicated windowed mode. These display modes runs at the set TargetFPS as the first test did. Also note the VSYNC=ON in dedicated mode runs exactly as fast as it does nonsynced full out so there is no loss in running VSync=ON in window off mode.

Decrease the TargetFPS variable and the framerate loss is even more noticeable.





What causes this frame rate drop in VSync=ON window mode?
Have irritated me a while now.

Regards
Back to top
Profile PM
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 16th Jun 2010 02:05
Link
@KISTech
Yes, ideally you have the render loop wait until about 1/61th of a second since the previous sync before rendering, and have VSync enabled. You then have game loops completely separate. IanM's plugins have some commands to switch between 'subroutines' which allow a kind of fake multi-threading which is perfect for this.

The sync rate is then irrelevent as long as it's 0, 60 or more.


New DBPro IDE + integrated debugger!
Back to top
Profile PM Email Website
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 16th Jun 2010 03:16 Edited at: 16th Jun 2010 03:17
Link
Quote: "No it does not if you run in dedicated "Set Window off" mode "


Who really wants to do that? Well, ok, some do. I prefer Windowed-Fullscreen so the player can alt-tab to something else without crashing the game.

Diggsey, Yeah, something like that, but you really wouldn't need IanM's commands to do it.



It's a bit simplistic of an example, but it just runs the GameLoop as fast as it can, and fires off the DisplayLoop every 33 milliseconds. You still don't want to set Sync Rate to anything but 0 though, otherwise you are losing potential GameLoop time.

If you want to control how much time the GameLoop gets, so it doesn't dominate the CPU, then you could use a little math and figure out (each loop) what a good delay value might be and use IanM's NICE WAIT command, which will wait the specified number of milliseconds, but wont tie up the CPU while it waits. A value as little as 2 could give 10% or more of your CPU time back.

Back to top
Profile PM Email Website
Duke E
17
Years of Service
User Offline
Joined: 10th Mar 2009
Location:
Posted: 16th Jun 2010 04:05
Link
Quote: "Who really wants to do that? Well, ok, some do. I prefer Windowed-Fullscreen so the player can alt-tab to something else without crashing the game."


To prevent "Tearing".
It looks much smoother when frame redraws do not happen mid sync. It will not show up so much on some gametypes but fast action and with shaders implementing lights for explosions for example, it will show when the redraw happens half way trough an explosion flash.

I agree with the Alt-Tab hassle, double that when you use physics and also have to keep track of rigid bodys and whatnot when getting the focus back
I have opted to be able to use both synced and non-synced, it is more work.

Thereof my irritation on not being able to use VSync in windowed mode, would make it much easyer.

Regards
Back to top
Profile PM
sladeiw
17
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 16th Jun 2010 10:41
Link
I thought the problem with Vsync is if that your display loop just misses the sync, it waits until the next vsync, instantly halving the frame rate. But tearing is not nice either

On most games I would choose vsync off because it gives you best fps.
Back to top
Profile PM
KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 16th Jun 2010 18:17
Link
Yeah, none of it is really ideal.

Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-25 16:21:21
Your offset time is: 2026-07-25 16:21:21