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.

Newcomers DBPro Corner / speeding up your game

Author
Message
wind27382
18
Years of Service
User Offline
Joined: 10th Feb 2006
Location:
Posted: 23rd Dec 2007 00:35
I searched and I found lots of information on this forum, but i was still wondering if anyone had any advice to speed up your code. such as ways to condense your code so that it would load quicker. or finding ways to use less polygons. that sort of thing.

wind
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 23rd Dec 2007 00:48
Quote: "speed up your code"
DarkGDK C++

Quote: "condense your code"
In DBPro? You need to have a good working knowledge of each command and a feeling for what works faster - and more or less through trial and error and hints and tips you may find here - learn to just write code that performs better through optimization. No silver bullet for this I'm afraid.

Quote: "...so that it would load quicker..."
same principle as optimization blurb I just wrote - however - applying the same strategies to file media. also...

-use only textures big enough to get job done

-try to recycle textures

-less media overall means faster load time obvioously - but worth considering

-Cloning and Instancing 3d Objects is faster than loading the same object over and over and over

-Some tests we have done have found DBO "Files" load faster than "X" DirectX native files for the same models. To make a DBO - you would have to make a program load the model and then save it from within DarkGDK. DBO is a DarkGDK/DarkBasic Native file format.
(Some may contest - but write your own benchmaks and see)

-Many claim that DDS texture file format loads faster that using PNG and BMP - But PNG at least has less byte to read than a typical BMP with the same resolution - so... Experience will teach ya.


Quote: "...finding ways to use less polygons..."

-There are tools you can buy to reduce poly counts in models - one named Action3D is sold right here on this web site

-Learn About Frustrum Culling, Objects, Limbs, and search for "Lost In Thoughts" Frustrum Culling for Limb Port to DarkBasic (not DarkGDK yet)... It can give accurate results if a object's limb is on or off the screen and shut it off or show it - this effects poly and therefore speed.

-DarkGDK and DarkBasic are better at having an object with many limbs versus havign a ton of individual objects. (think Individual Object versus a "GRoup tied to gether"

Well - I'm sure others will add stuff - but - the being the holidays and all - I get the feeling people are busy - its been quiet.

Enjoy your holiday!

wind27382
18
Years of Service
User Offline
Joined: 10th Feb 2006
Location:
Posted: 23rd Dec 2007 01:09
thanks for taking the time, yeas i fiquired it would be trial and error. but i was just hoping someone would give me a miricle formula for writing the perfect code. thats as fast to write as it is to load

wind
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 23rd Dec 2007 01:13
haha - I hear ya. If you find that answer - you should copyright it and sell it

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 23rd Dec 2007 14:44
@Windows Killer - Dude that would be awesome - maybe others will post their speed up findings as well...

wind27382
18
Years of Service
User Offline
Joined: 10th Feb 2006
Location:
Posted: 23rd Dec 2007 15:26
thats kind of what i was hoping for window killer for everyone to post their findings so everyone including myself could use this to learn before coding our next game. or me using this to speed up an already made game,

wind
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 23rd Dec 2007 17:31
Excellent Work Windows Killer!

I have one. Some MIGHT call this a BTREE. I don't know or care it it is or not - I care that this can speed up code in one particular case - BY ALOT. You Only implement this sort of CODE-MUDDY'ing junk AFTER you have all your bugs ironed out... as it will turn a nice CASE statement into a Spagetti Code Nightmare - but again - it will execute really fast.

first: the Scenario where it applies!

you have a Switch case that is based on interrogating the value of an integer - that is kinda long.

Example:


Note - the example has only 8 - I might not bother - but if it was 20 or more - I wouldn't hesitate!

Note Also - Like Windows Killer said - for a switch that looks like this - the most common on top would speed things up a bit HOWEVER in a totally random scenario - we can at least keep things a little more balanced - so they ALMOST happen as fast as if they were all top ones. Well.. Let's just say more accurately - that we can trim the number of comparisons down a bit - and at least make it more "even Steven" in processing time for each one.

I'm just going to show the Technique - you can make as deep a "tree" as necessary. This SAME technique - of HALVING - can be used to Search for items in an sorted numeric array faster as well - but I'm not feeling up to that today. Maybe you'll see why this works and figure out other applications for this yourself.

Ok - Remember - To get to the LAST item in the List - we need to MAKE EIGHT Tests in our SELECT statement.

Spagetti Speed Example (remember - 8 items, not a big deal - and not really worth it - but if you have 20+ tests - you can HALVE
the number of average tests across the whole list to be much smaller.



remember - on a per case basic - doesn't seem like a big deal.
throw 100 Witches at the first code snippet and the "Fix" and you tell me.

Make a big array of random "Types of baddies" and compare the switch versus this seemingly small (ugly) change in the logic.

You'll see.

RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 24th Dec 2007 03:53 Edited at: 24th Dec 2007 03:55
There was a huge post made by... I think Jess T a few years back that had tonnes of tips for speeding up your game, both code-wise and media-wise.

<edit>

Hah, I was right, it was Jess T. Here's the link;

http://forum.thegamecreators.com/?m=forum_view&t=32948&b=10

Insert Name Here
17
Years of Service
User Offline
Joined: 20th Mar 2007
Location: Worcester, England
Posted: 25th Dec 2007 13:33
Didn't tinkergirl do a nice one as well?


Sudoku arts, the rabi and Nancy DrewG
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 22nd Jan 2008 12:56
wind27382,

I have been pondering over ideas to speed up my game engine during loadtime and runtime. Most of my ideas hover around the premise of reducing the number low level instructions (calculations) needed to be peformed throughout the program.

jason p sage has mentioned some very good methods to squeeze more speed out of your code. I would like to add my 2 cents to the list.

* Use integers over floats/strings for IF/SELECT conditional checks.
* Scope down Conditional checks. If you need to check four conditions, find a way to only check one Or check condition on every 3rd iteration instead of every iteration.
* Distance Checks: Use a heuristic vs Pythagoras Theorem.
* Use precalculated Lookup tables in place of extensive calculations.
* Use Sort Algos in place of iterating thru multiple lists.
* Use 'Tight Loops' - iterate through only what you need.
* Geometry: VIS - If you cannot see it - hide it.
* Geometry: Level of Detail - Scale up/down polies based on distance from camera. Far = Lower, Near = Higher. Can be precalculated within geometry or upon load. Applicable to Collision geometry as well.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 22nd Jan 2008 13:23 Edited at: 22nd Jan 2008 13:23
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 22nd Jan 2008 13:23
Another I was reminded of recently was to switch a number to the opposite sign... Avoid MyNewNum = Num * -1 and use MyNewNum = 0 - Num instead.

Floats are different so I'm not sure about the best way - but for int's - GENERALLY multiplication and Division take longer than addition and subtraction.


I say generally because assembly programmers should be aware of 2's compliment multiplation and division and these are not GENERALLY something you can do in DB, nor is applicable for games usually... but are just as fast as addition and subtraction - via something called bit shifting...


SimSmall
20
Years of Service
User Offline
Joined: 7th Aug 2004
Location: United Kingdom
Posted: 22nd Jan 2008 18:36 Edited at: 22nd Jan 2008 18:37
Also, may have been mentioned, I've not really been reading, is what a language like C++ calls 'short-circuiting' expressions:



when short-circuited, would look like:



If 'a' is below 0, there is no point checking if 'a' is below 99... You already know that the second half of the statement is true, but 0 and 1 gives 0. This only works with 'and' logic, since it's the only logical expression which requires both propositions to be true in order to evaluate to true. DBP does not short circuit expressions by default, and you can write a small example with possibly one million iterations to see it for yourself.

One logical expression like this in your loop, and you almost certainly won't see a difference, but if you have many such expressions, you may notice a speed increase.
wind27382
18
Years of Service
User Offline
Joined: 10th Feb 2006
Location:
Posted: 22nd Jan 2008 23:13
wow thanks for the tips. I was thinking that this thread had died out, but it's nice to see that their are still some really great tips in it.

wind
Cash Curtis II
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 23rd Jan 2008 12:23 Edited at: 23rd Jan 2008 12:26
@SimSmall -
I'd like to add something about short circuting. I believe it was IanM that showed this to me a long time ago...

Quote: "if a > 0 then if a < 99
`Do something
endif"


will short circuit the condition checks. If a is not greater than 0 then it won't do any other checks after the 'then'. You can string up as many as you like on one line and it remains nice and readable.

DBP's ABS function is slow. The code below demonstrates that - if test1 comes out faster than test2 or 3 then that means you have IanM's Matrix1 DLLs installed, and he's provided a replacement abs function that uses integers instead of floats. If you're using DBP's native version it will blow your mind how comparatively slow it is.

Something I think is somewhat interesting - with integers 0-number is marginally faster than -number, around 10 ms for 10,000,000 checks, but with floats 0.0-number# is noticeably faster than -number#. This is shown below as well.



Another thing that tends to plague code is slow distance checks. Distance checks need to be performed every loop and can bog a program down if too many are being done incorrectly.

One thing you should realize - use a 2D distance check whenever you can. For example, if you have two characters walking on an advanced terrain and you want to check the distance between them, a 2D check will almost certainly do the job and is faster than a 3D check.

Styx has a really fast distance function. If you don't have Styx then you should use vectors.



Now, here's the thing you should realize - most distance checks are comparisons. For instance, if distance#<100.0 then 'whatever. You can cut out the middle step and just check the squared distance. These are the fastest, even faster than the Styx distance checks (not by much though)


This will return a 1 if the objects are within the distanceCheck# range and 0 if they are not.

returnValue=(((x#*x#)+(z#*z#))<=(distanceCheck#*distanceCheck#)) is noticeably faster than
if (((x#*x#)+(z#*z#))<=(distanceCheck#*distanceCheck#)) then returnValue=1

And one final though about this - x#^2 is way slower than x#*x#. I haven't tested it with integers, but it's probably the same.


Come see the WIP!
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 23rd Jan 2008 13:00
The case thing I showed above is likely faster than a string of short circuits unless they are strung up and nested - which becomes a binary tree anyway.

Otherwise - the conditions at the bottom of a "nice readable" list of this short circuit idea ... will execute only after all the other checks are done.

The concept is sound however - that it what I described above. There are other varieties of this kind of logic - OctTree, Quadtree, etc. For the if/else optimization - the binary tree I explained above is about the fastest. The larger it is the more faster it is in relation to a non "optimized" string of ifs.

Cash Curtis II
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 23rd Jan 2008 15:03
It just depends on what you're doing. If you are testing conditions then a Case block will be faster. However, if you are testing literal conditions or the results of functions then the short circuited method would be preferable. For example...



wouldn't be suitable for a Case...Select block. The above example would be much faster than, say...



Because the potentially slow distance and collision functions are tested every time whether or not the other 'character' is 'alive'.

Something I forgot to mention above - loading images can be slow. Sometimes you'll load a .x or .dbo model and you'll notice that it's kind of slow. You'd assume that it's the model, but it's not - it's the texture. This is most evident when it's a large image, like 1024x1024. You can do two things to fix this - lower the texture resolution (1024 is rarely needed) and convert the texture into DDS format. I just did a test with two images, a 512x512 png and DDS file with no alpha. I loaded each 10 times.

The PNG took 2715ms and the DDS took 15ms, 10 times each, regardless of which I loaded first. If you have 300 textures, like Geisha House does, this amounts to 81.45 seconds. If they'd all been DDS it would take .45 seconds. Quite a difference.


Come see the WIP!
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 24th Jan 2008 00:30
I agree with your explaination "If this then if this..." would be fast especially when the more likely results are the ones your testing for.

However, I do need to point out that NOT all languages work this way. One of those "Details" I like about FReePascal is that in a multi-condition IF:

if c=1 and b=2 then

Basically it stops testing the when it hits the first "failure", where most languages process all the conditions for order of operations first - then check the final result.

In short all I'm saying is that this technique's usefulness is FASTER - ALWAYS - however, the reader should note that some languages process conditional logic in this manner without needing to write the if(c=1) then if (b=2) then type of syntax.

Good One CattleRustler - I see what you mean by short circuit more clearly now

Login to post a reply

Server time is: 2024-09-27 10:29:14
Your offset time is: 2024-09-27 10:29:14