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 / Huge List of ways to increase your FPS

Author
Message
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 20th Dec 2009 20:26 Edited at: 20th Dec 2009 20:29
I like this thread and the techniques in the top post of the Huge List of ways to increase your FPS are applicable to many languages when creating games and apps. Would like to see Network Anti-Lag Techniques added. Golden Rule: "Only process, what you have too."

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 20th Dec 2009 21:10
@TuPP3,
This line:
if timer()>hi+secondstimerlasts

Should be changed to this:
if timer()-hi>secondstimerlasts

You should have the print statement between the if...endif commands too.

Also, the timer measures milliseconds (1000th's of a second), so your timer would be triggered every 10th of a second.

TuPP3
17
Years of Service
User Offline
Joined: 26th Jan 2007
Location: [+--]FINLAND
Posted: 20th Dec 2009 21:20 Edited at: 20th Dec 2009 21:22
Oh, I see.

I finished up the timer code and this is the final:


It will print TIMER! after 5 seconds.

Btw. there was said, "avoid the DarkBASIC particle system", does that mean the Cloth and Particles plugin which is now included iwth DarkBasic?
Outscape
15
Years of Service
User Offline
Joined: 23rd May 2008
Location:
Posted: 21st Dec 2009 00:52 Edited at: 22nd Dec 2009 00:42
yeah sorry i dont program much db now just gdk, and so i usually forget the odd db syntax stuff (even tho its very simalar)

Quote: "Btw. there was said, "avoid the DarkBASIC particle system", does that mean the Cloth and Particles plugin which is now included iwth DarkBasic?"


plugins arnt the dbpro system, plugins are external, and so they are most likley faster, if u goto the dll section there is alternatives.

cloth isnt particles, cloth is the movement of each vertex of the object with its over gravitational pull.

ill update this thread soon, or at least when theres multiple things to update.

[edit]

mybad in the logic when i coded
i must of typed it wrong
i was ment to type



ill change the code with this

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Dec 2009 12:50
Same mistake in both pieces of code - neither deals with overflow of the timer. It can happen more often nowadays as people tend to put their computers into sleep/hibernate rather than powering off.

This line:
if (time > movetimer + 50)

should become:
if (time - movetimer > 50)

This line:
if timer() > hi + secondstimerlasts

should become:
if timer() - hi > secondstimerlasts

Outscape
15
Years of Service
User Offline
Joined: 23rd May 2008
Location:
Posted: 22nd Dec 2009 00:07
Quote: "Same mistake in both pieces of code - neither deals with overflow of the timer. It can happen more often nowadays as people tend to put their computers into sleep/hibernate rather than powering off."


i forgot the length of a variable, but i fail to see the improvement (please correct me if im wrong)

if ur timer is 10 characters long, hi will still be 10 characters long in this:
if timer() > hi + secondstimerlasts
and also
if timer() - hi > secondstimerlasts
that?


Or is it simply the adding of hi and secondstimerlasts might cause an overflow?

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Dec 2009 00:33 Edited at: 22nd Dec 2009 00:34
Quote: "Or is it simply the adding of hi and secondstimerlasts might cause an overflow?"

Yes.

After just over 47 days, the timer wraps over from 4.3 billion back to 0, or if you are storing values in an integer, it will wrap from 2.1 billion to -2.1 billion after just over 23.5 days.

Big numbers and a long duration, but as I said, because a lot more people sleep their computers, it becomes more likely that you'll hit these numbers. Usually it won't cause programs too much of a problem, but as it's so easy to fix (subtract from the left instead if add to the right), why not do it right in the first place.

Outscape
15
Years of Service
User Offline
Joined: 23rd May 2008
Location:
Posted: 22nd Dec 2009 00:39 Edited at: 22nd Dec 2009 00:40
i see, tyvm.
Ill modify my post and the main post in a min or so with that then =)

Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 24th Dec 2009 13:37
Quote: "how I seamlesly shake it without sin/cos/tan? "

Pre-calculate the swaying, store it in an array, then iterate through it to get the sway amount.

My signature is NOT a moderator plaything! Stop changing it!
Cash Curtis II
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 24th Dec 2009 20:34 Edited at: 24th Dec 2009 20:46
This thread is no good. It touches on some helpeful ideas but many more unhelpful ones.

Quote: "//how long does the timer last?
secondstimerlasts = 100
//set the timer variable
hi = timer()
//loop
do

//if timer has gone past another 100 miliseconds
if timer() - hi > secondstimerlasts

//redefine hi
hi = timer()
endif
sync
loop"

This code is junk. Why is it subtracting 'hi' from 'timer()' every loop when it could just be doing a comparison? Why is 'timer()' being called more than once? This will only test for a duration of 100 ms, btw, though that might be desired. In any event this is a poor demonstration of timers and coding technique.

The whole discussion about blank lines was painful and ridiculous.

Quote: "You should always run with sync rate set to 0 and control things with timer based movement. Setting the framerate cap lower actually adds a delay into your code with is counter-productive to increasing framerates."

You should cap your framerate. Right now 17ms might elapse between each loop but as computers become faster that might approach 0, which will make the game unplayable. I keep a project uncapped during development using timers, then cap it for release. On computers that run below the capped framerate there is absolutely no difference, except the computer is doing less unnecessary work. Over 60 fps doesn't make any difference.

There are lots of ways to legitimately increase a game's framerate, but I won't post them on this thread. Some things were valid but I cannot be bothered to differentiate and resort the suggestions.


Download the game!

Attachments

Login to view attachments
Outscape
15
Years of Service
User Offline
Joined: 23rd May 2008
Location:
Posted: 24th Dec 2009 20:58 Edited at: 24th Dec 2009 21:01
Quote: "This code is junk. Why is it subtracting 'hi' from 'timer()' every loop when it could just be doing a comparison? Why is 'timer()' being called more than once? This will only test for a duration of 100 ms, btw, though that might be desired. In any event this is a poor demonstration of timers and coding technique."


Its an example to those who don't understand how timers work, in how you make a timer.

The way the timer was programmed was posted by IanM, i don't usually subtract it in the if statement.

I could put timer once, at the start of every loop, and reuse the variable, but that wasn't the point of the example.

Like i said it was to show people who don't understand timers, to know how they work, and i'm not going to over complicate the system because if you know how they work then you code need to read the code snippet do you?

Quote: "The whole discussion about blank lines was painful and ridiculous."


People are free to post what they want, are they not?
I don't see how that has anything relevant to the main post.

Quote: "There are lots of ways to legitimately increase a game's framerate, but I won't post them on this thread. Some things were valid but I cannot be bothered to differentiate and resort the suggestions."


Whats stopping you from sharing with the community?


I don't see why you are so aggressive towards a post solely made to help and benefit other people.

You are free to help improve this thread, I'm not going to try and stop you, i made this thread for the community to work together to improve FPS in the game they or i make, not to try and show anything off.

Cash Curtis II
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 24th Dec 2009 21:24
I wasn't aggressive, sorry if I offended you. More thought should go into a post like this, though.


Download the game!
Outscape
15
Years of Service
User Offline
Joined: 23rd May 2008
Location:
Posted: 24th Dec 2009 22:55
Quote: "I wasn't aggressive, sorry if I offended you. More thought should go into a post like this, though."


No offense taken.
Instead of saying what is wrong, maybe tell us on how i can improve it?

TuPP3
17
Years of Service
User Offline
Joined: 26th Jan 2007
Location: [+--]FINLAND
Posted: 25th Dec 2009 01:11 Edited at: 25th Dec 2009 01:12
I'd like to hear too what would be best optimized timer system, or should I just go back to inc:ing different variables which was pretty straight forward, although done every loop it might eat some speed.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 25th Dec 2009 01:23
There's no need to improve the code.

First, if you switch to doing just a comparison, you are back to the same potential overflow problem that the code had before, and secondly, I doubt anyone could measure any difference in speed between doing a straight comparison and doing the subtraction - I know that I couldn't detect it over 1,000,000 iterations with the following code:


On repeated runs, you'll usually a couple of ms difference between the two numbers displayed (due to windows interfering) and the difference can be either way.

Also, please note that I was not endorsing the timer code in any way. I was merely making it operate correctly.

In fact there are many 'optimisations' that have been added to the first post since this thread started that I don't agree with (Timers, Large Floats, Sync Rate, Full Screen), and some I only maybe-agree with depending on implementation/requirements (Global Variables, Ray-casting > bullets, Complex Maths Hurts FPS). There are several others that I have no opinion on.

Now if you were to grab the timer value once per frame and reuse the value instead, then that may be worth doing if you are checking the timer a lot - not only are function calls more expensive than a variable fetch, but the program accuracy will be increased (timer may give you different values during the same frame, a variable won't). This one comes under the title of 'Predefine / Precalculate reused values'.

Outscape
15
Years of Service
User Offline
Joined: 23rd May 2008
Location:
Posted: 25th Dec 2009 02:05 Edited at: 25th Dec 2009 02:49
tomorrow, ill whip up a few tests and show everyone why
(Timers, Large Floats, Full Screen, Global Variables, Complex Maths Hurts FPS)

may effect your game.

normal fps: - 523




Large Floats - 495





complex maths - 508



dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 25th Dec 2009 05:21 Edited at: 25th Dec 2009 05:22
I agree with IanM/Cash Curtis II, many of your 'optimizations' are incredibly half-baked. The example you just posted doesn't even come close to compiling so I'm not even sure if you ran it(the first pic even prints out a completely different string to what the code contains!). There should be no reason why declaring a bunch of global variables would result in lower FPS, even if you could demonstrate this(which fixing that code most certainly does NOT), it wouldn't really justify not using them. It's not like global variables are just a different way of writing variables in one of the other scopes, they are fundamentally different; advising people not to use them is thus an issue pertaining to code design and structure, not optimization.

You should also take care when writing some of those points and make sure you know what you're talking about, for example:

"Shaders effect the pixels printed on the screen, eg if a pixel is black, the shader may change this pixel to a Grey, and maybe implement a pixel offset.
All this calculation (having to be done every time the object/camera changes or you might get bad effects where the pixels go out of place) costs a lot of FPS, so use shaders at your own risk."
- None of that makes any sense.

"This one I'm kinda surprised about, every time you call Sin/Cos/Tan and other complex math calculations, you damage the fps by a fair amount, limit the amount of times you use them, or try to prevent using them at all." - Not really, they have more overhead than other functions, but they don't inherently 'damage' the FPS.

The wording of a few others makes me cringe a bit, but they aren't that bad I guess. It would have made more sense if you listed more common design patterns that have pointless overhead, like looping from some value to another which is retrieved from an expensive function whose return value doesn't change during the loop. Or using routines with n^2 complexity when it's not required(like finding the nearest enemy). Loading frequently used media at runtime when it can be precached etc etc.

TuPP3
17
Years of Service
User Offline
Joined: 26th Jan 2007
Location: [+--]FINLAND
Posted: 25th Dec 2009 10:11 Edited at: 25th Dec 2009 10:18
I tested those codes, large floats didn't work right there, but sin, cos, tan reduced my FPS from 4190 to 3865, which seems very little to me when we are at high frames. I think this wouldn't yet even lower from 60->50.9 or am I correct?

But I don't really see why you "professionals", are against this thread, but won't seem to give straight improvement ideas, but already ready to take this thread out.

There is many good basic tips in that list, like LOD for 3D objects. Althought I had already figured most of them out while playing commercial games and investigating their optimization, but those might help newcomers.

If there is something wrong, serious or small thing, might we aswell share it with TGC community? Atleast I'm listening every tip from better coders.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 25th Dec 2009 11:48
Quote: "but sin, cos, tan reduced my FPS "

I am confused by the 'proofs' shown - they prove nothing except that doing something is slower than doing nothing, except that's another problem. You measure performance in time (ie, seconds or milliseconds), not frames per second.

As you've noted, something that gives you a very large apparent effect at very high frame rates will be undetectable at low frame rates.

Quote: "But I don't really see why you "professionals", are against this thread"

I won't speak for anyone else, but I am not against this thread. I am against some of the so-called performance improvements that have been stated.

I said:
Quote: "Generally, plug-ins will do the job faster than you can do it yourself (always benchmark though - prove that the plug-in is faster, don't assume)."


There. I contributed.

Here's another one - searching arrays.

Most people will code a linear search (ie start at the beginning and work to the end or until the match is found) - on average you will look at half of the array items each search if the item is in the list, and you will visit every item if the search items does not exist.

If your array is sorted though, then you can code a binary search. Start at the middle - if the one you are looking for is less than the one you are looking at then you've eliminated the top half of the array, otherwise you've eliminated the bottom half. Repeat for the remaining half until you have a range in the array that is one item in size. That will either match your search or not. This will have resulted in you visiting far less items.

Sorting is slow though, so there's a trade-off. If you amend your array (insert/delete or change the search value) then it may be best to keep the linear search. Or if you do lots of searching and few amendments, sort and binary search.

Veron
17
Years of Service
User Offline
Joined: 22nd Nov 2006
Location:
Posted: 25th Dec 2009 11:57
Agreed with basically everything IanM, Cash, and DC have said.

Quote: ""But I don't really see why you "professionals", are against this thread""


Because the so called "professionals" actually know what they're talking about when it comes to these methods?

Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 25th Dec 2009 12:45 Edited at: 11th Aug 2010 23:45
Well, these types of threads do pop up frequently, so a lot of the same ground gets covered, over and over again.

One that comes to mind would be this one -> Simple Ways to Optimize Code


There probably should be a sticky with of the best threads containing valid tips.

Daniel wright 2311
User Banned
Posted: 25th Dec 2009 23:45
you said this

""But I don't really see why you "professionals", are against this thread""

I say this

who do you consider a pro? I really dont see where you got to choose who is a pro and who is not. this thread is to help people just learning how to code with ways to speed up there games. Its nice to know there is helpfull people here to show others ways of doing it.And why would you care anyhow? Its not hurting you in any way.

Login to post a reply

Server time is: 2024-05-04 18:56:27
Your offset time is: 2024-05-04 18:56:27