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 / DBP-Engine Performance Improvement

Author
Message
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 9th Sep 2006 23:42 Edited at: 22nd Sep 2006 19:15
Hi community.

Actually, I am programming a kind of engine for my planned games. So I am collecting all hints and ideas of improving the performance of this engine.

I already head some ideas, how to increase the fps, and want to list them here, and hope, that everyone who knows something about performance improvement, is going to post it here. I guess, many people, especially programmers without much experience, would apreciate it and it would help me and other people, improving their games.

Also I want to say, that I used the Search-function, but couldn't find anything about this theme, just many questions about the performance decreasement of different commands etc.

If anything I'm going to write here is wrong, please tell me and I am going to edit it.
Thanks.
(I didn’t test everything I write here, so some things are just assumptions)

--------



***Basic***

Don't use to many #constants representing DBP-Functions (e.g. '#constant scrw = screen width()', rather save the screen width() into a global) or DBP-functions like Object position X() or screen width(), better save object positions in an array and update the array after moving the object, and save not-changing values like the screen-width in a global-variable.

If it's possible to split very time-intensive calculations, do that. E.g. if you want to hide objects outside the screen, you could each first round check the first quarter, then the second and so on. With such methods, you can also write functions for loading files like images or models in background, so that the game doesn't pause, but run slowlier a short time.

Use the Sync-Command. The Sync-rate gives you control over the screen-refresh-rate, so that your program runs with the same speed on every computer. Also the programm just syncs one time each loop, and not more often.

Better use the Text-command then print. It’s not as easy to use, but mostly it’s faster.
Edit: After some discussion with friends and some tests we decided, that both commands have nearly the same speed, so it doesn't matter, which of them you use.

Always just do, what’s necessary. Don’t check if the options-button in the menue is clicked, when the game is running.

Save time-intensive functions like sin and cos in an array at the begin of your program, and use this array instead of calling the functions later in your program.

Don’t use floats, if you can use integers instead, and if you declare an array, which elements always should be 1 or 0, let it be a boolean. That saves memory and performance. Edit: It seems as if the variable-types don't really influent the performance, just the RAM.

Before compiling the finished version, remove all debugging-operations, which are not neccessary. That may increase the fps for some percent.

Reading is always faster than writing, that's true for files, memblocks, arrays and maybe more. So before you change an array element, it's sometimes better to check first, if the element is different from the value you want it to be.

If you use for-next-loops with a target-value, which doesn't change, don't let the target be a function, but a variable. If it is a (User-defined or DBP) Function, the program checks it in each round.

Don't use text-layout-commands like set text size or set text font in your loops. They slow down the speed very much, even if you use them only one time to print one letter.

Use the sync-command just as often as neccessary. You don't have to update the screen oftener then about 30 times a second. If you game rund faster then with 30 fps, it will run even faster if you just update the screen 30 times a second.



***Landscape***

The best method of using big landscapes for games, is an Advanced Terrain, made from a heightmap. They look relistic because of the base- and detail-texture and the good self-shadowing, and it’s hard to see single polygons.
Edit: I call Advanced Terrain the best decision, because they are fast and realistic looking, not because the are the easiest to use.

If you use realtime vertex-manipulation for a terrain-editor, or even if you just use them in games, you should split them in different terrains (e.g. 4*4) and just edit/show those, which are in screen.

Use DBP-Fog, it’s kind of realistic and the engine doesn’t have to show all polygons, if you set the max camera range to the fog-distance-value.

If you know the vertex-commands, and how to use them, decrease the polygon-count of the terrain. If some polygons next to each other have nearly the same gradient, make one polygon out of them.

Don’t use too big heightmaps. The best size is 512*512. It’s better to stretch the terrain in X- and Z-Direction, then to use a bigger heightmap.

Use more then one terrains and use LOD for the Polygons and the texture. You could split a 2048^2-heightmap into 8*8 parts and the parts near by the camera should have most details, and the parts far away less polygons and a low-res-texture. It might be hard or much to code, but I guess it speeds up the game a lot, and you can use very big landscapes.



***Objects***

Generally, just use low-poly-objects in your games, better a high-resolution texture and a low-poly object, then the other way round.

Use Level-of-detail by loading two meshes (and two textures) for each object, and replacing the high-poly-object with the low-poly one, when the camera is far away enough.

Hide all objects with many polygons, which are not in screen.



***Shaders***

Use just as many shaders as necessary, because most of them are very bad for the performance, even if they may increase the quality of your game.

Stop shaders, if they are too far away. Why should you bump-map a wall, if the player stands 50 meters away?



***Physics***

Don’t check object collisions, if the objects are to far away from each other to collide. Make an array and save the objects size after loading, and before checking a collision later, check if the object distance is small enough, that a collision would be possible.

You should only check collisions for those objects, which have to collide, like buildings or characters, but not little things like grass.

If you check the object distance, don't use the sqrt-function, but square the values, or use vector commands.



***2D (Images, Sprites etc.)***

If your 2D-game is tile-based, just paste/show the sprites/images inside the screen.

If a small sprite is under a big one, you don't have to paste/show it. (e.g. a grass-tile under a building)

Just check sprite collisions, if it's possible, that they collide (by comparing distance with sprite-sizes).

If you draw many dots at one time, or use the point-command, write before and after the loop a lock- and unlock pixels.


--------

***Codes***


**Basic**

- DBP-Functions or variables


- Splitting of time-intensive calculations


- Using Sync and Sync On


-Functions or Arrays?


-Floats or Booleans?


-Debugging-operations


-Reading and writing


-For-next target as variable


-Text-Layout commands


-Sync-Limitation



**Landscape-Codes**

-DBP-Fog and Camera-Range


--------

That’s all for now. I hope, that you’ll post more tips or comment mine. Maybe some of them are wrong, or aren’t true in all cases (that’s no question… of course there are always exceptions).
I think, I am going to update the list after reading your posts, so that no one has to read the whole thread, to get to know these things.

Thanks for (hopefully) answering.


Edit: Of course, not all of the tips are my ideas. Some are from other forums, and some may be edited after being in posts from this thread.

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1
The admiral
21
Years of Service
User Offline
Joined: 29th Aug 2002
Location:
Posted: 10th Sep 2006 00:25
With the text thing there is a dll around called advanced text or something it is much faster than dbpros own text and it offers more features. Also some shaders like normal maps etc can make things more detailed and then you can make them lower poly objects so you still save processing power.

The admiral
coolgames
18
Years of Service
User Offline
Joined: 26th Sep 2005
Location: Oregon, USA
Posted: 10th Sep 2006 00:56
When checking distances, don't use the square root function. Just take the desired distance and square it. That will give you much faster results. So if you're trying to see if the distance is less then ten, do the distance formula without the square root and see if it is less then 100(10 squared).

Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 10th Sep 2006 01:03
As coolgames said, but also, if you do have to find out the square root, using a vector and the vector distance function is much faster.


Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 10th Sep 2006 02:05
Thanks for the ideas, i added it to the list.
Do you think it would be usefull to add codes which proove the statements and show the difference of the different methods?
The admiral
21
Years of Service
User Offline
Joined: 29th Aug 2002
Location:
Posted: 10th Sep 2006 02:47
Whats the fastest distance function?? Does anyone have that vector distance function??

The admiral
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 10th Sep 2006 03:13 Edited at: 10th Sep 2006 03:18
I've never done something with vectors, so I don't know, if I did it right, but the function seems to work.

Change the variable-values how you want, I think it does it's job.



Edit: I updatet the code... seems as if the sqrt-function is about 4-5 times faster.
Maybe someone could write a faster vector-function, knowing how to do it?
Peter H
20
Years of Service
User Offline
Joined: 20th Feb 2004
Location: Witness Protection Program
Posted: 10th Sep 2006 03:13
this thread is for DBC but lots of it applies to DBPro http://forum.thegamecreators.com/?m=forum_view&t=32948&b=10

"We make the worst games in the universe..."
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 10th Sep 2006 03:38 Edited at: 10th Sep 2006 13:14
Thanks a lot... I've just looked for threads with the keywords 'Performance', 'Engine' and 'Improvement', but not 'Speed'.

Maybe I'm going to add something from this thread to the list, what is also good for dbp.

Edit: Added the first codes for the ***Basics***, to proove the tips.
The admiral
21
Years of Service
User Offline
Joined: 29th Aug 2002
Location:
Posted: 10th Sep 2006 04:53
Yeah i was thinking that someone should make a thread documenting all the stuff for dbpro as well.

The admiral
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 10th Sep 2006 13:44
Also, have all images ready, eg. If you have an animated sprite image, it's better to get the images at the start, rather than getting the image each time you need it. That's kind of obvious though

dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 10th Sep 2006 14:42
Some of these arent really very well thought out, for instance.

Quote: "Don't use to many #constants or DBP-functions like Object position X() or screen width(), better save object positions in an array and update the array after moving the object, and save not-changing values like the screen-width in a global-variable."


I just did a little benchmark test with contstants vs globals, and after 100mil loops, of just making a temp variable = to each test value, constants were 50ms faster overall, which isn't really much of a difference, you are correct about using object position x(), vs reading from an array(about 2x difference), and non changing values should allways be in constants.



Quote: "Use the Sync-Command. That gives you control over the screen-refresh-rate, so that your program runs with the same speed on every computer. Also the programm just syncs one time each loop, and not more often."


Unless your game was a series of print statements you would have to have used the sync command, and no the sync command gives you no control over the refresh rate, things like the vsync/syncrate or manuaally timing loops will.


Quote: "Better use the Text-command then print. It’s not as easy to use, but mostly it’s faster."


These 2 commands are used very differently, print would be used as a general diagnostic printout, for instance if i were to end my application and wanted to display a series of variables, then i would use the print command, however text is alot more usefull as you get direct control over where it goes, without using set cursor, and not to mention you can change the text size and font and what not, however the dbp built in 2d/text commands are diabilically slow, so use cloggys awsome plugin which makes them as fast as they should have been from the beggining.


Quote: "Always just do, what’s necessary. Don’t check if the options-button in the menue is clicked, when the game is running. "


While that is obviously correct, a better solution would be to explain how using either multiple loops or seperating game states using case statements would avoid this problem.

Quote: "Save time-intensive functions like sin and cos in an array at the begin of your program, and use this array instead of calling the functions later in your program."


How do you hope to save sin/cos in an array?

Quote: "Don’t use floats, if you can use integers instead, and if you declare an array, which elements always should be 1 or 0, let it be a boolean. That saves memory and performance."


There is nothing wrong with floats, however limiting yourself to only the datatypes which the variable will need is a good idea, also declaring all variables at before a loop is advisable, and also using udt`s for arrays can save alot of hastle and memory.

Quote: "The best method of using landscapes for games, is an Advanced Terrain, made from a heightmap. They look relistic because of the base- and detail-texture and the good self-shadowing, and it’s hard to see single polygons."


It depends how you define best, easiest and fastest possiblt, due to its already made frustrum culling which can speed games up alot, however they are unoptimized last time i checked, as they are just big grids of polys.

Quote: "Don’t check object collisions, if the objects are to far away from each other to collide. Make an array and save the objects size after loading, and before checking a collision later, check if the object distance is small enough, that a collision would be possible."


That would be very slow if you have hundreds of objects, and you simple check collisions between them, as with 100 objects you are checking 10k collisions per loop, which isnt very efficient, the best method would be to make an octree for all your objects, however dbp kinda sucks at making them, so using something like sparkys collision dll would be a better option as it already makes them.

Quote: "Use DBP-Fog, it’s kind of realistic and the engine doesn’t have to show all polygons."


Dbp`s fog is just vertex colouring, it isnt realistic as it doesnt go by distance to the camera exactly, closer to a square, and it doesnt hide any objects that are in the thick of the fog, those just become hard to see, however if you do use the fog commands it would be best to set the cameras range at the same range as the fog.

Hallowed are the ori.
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 10th Sep 2006 15:19
Quote: "I just did a little benchmark test with contstants vs globals, and after 100mil loops, of just making a temp variable = to each test value, constants were 50ms faster overall, which isn't really much of a difference, you are correct about using object position x(), vs reading from an array(about 2x difference), and non changing values should allways be in constants."


What I meant was rather saving things like 'screen width()' in a global, then a #constant. If the values are absolute and always the same (e.g. '#constant MyValue = 50') there's of course nothing wrong with them. Sorry if it wasn't easy to understand what I mean, I'm going to edit it.


Quote: "Unless your game was a series of print statements you would have to have used the sync command, and no the sync command gives you no control over the refresh rate, things like the vsync/syncrate or manuaally timing loops will."


Yes... my mistake, going to edit again.


Quote: "While that is obviously correct, a better solution would be to explain how using either multiple loops or seperating game states using case statements would avoid this problem."


You mean, someone should write a tutorial for code-structure? If so, maybe I could do that next week and add to this thread... or another.


Quote: "How do you hope to save sin/cos in an array?"


Sorry... I don't really get what you mean, but I've written an example code in one of the code-boxes at the bottom of my first post. However, before a loop saving them into an array and later just checking the array-values is much faster then always using sin, cos and tan-functions of dbp.


Quote: "There is nothing wrong with floats, however limiting yourself to only the datatypes which the variable will need is a good idea, also declaring all variables at before a loop is advisable, and also using udt`s for arrays can save alot of hastle and memory."


Yes, I tested it and saw, that all variable-types have the same (nearly?) speed. But it's true, that floats or integers need more RAM than booleans, you can test it.
And of course, using UDT is a good thing, maybe this should be 'added' to the not existing code-structure-tutorial.


Quote: "It depends how you define best, easiest and fastest possiblt, due to its already made frustrum culling which can speed games up alot, however they are unoptimized last time i checked, as they are just big grids of polys."


I meant it's speed and look. I think it's more realistic and much faster then matrices, and has more options than normal terrain. Because you can't simply edit every vertex it's not as simple as a matrix, but for big landscapes, i guess, matrices are way too slow to use them.


Quote: "That would be very slow if you have hundreds of objects, and you simple check collisions between them, as with 100 objects you are checking 10k collisions per loop, which isnt very efficient, the best method would be to make an octree for all your objects, however dbp kinda sucks at making them, so using something like sparkys collision dll would be a better option as it already makes them."


I said... you don't have to check the collision, if the objects are too far away. Example:



That saves a lot of performance, if the objects are complex.
One question: What is an octree? I guess, it could be the short version of object collision tree... would you (or someone else) explain, what it is? (I've never heard it, I think)
And yes... of course there are different DLLs like Sparkys, being better then DBP-Collision. Maybe I should add that, too, to the first post.


Quote: "Dbp`s fog is just vertex colouring, it isnt realistic as it doesnt go by distance to the camera exactly, closer to a square, and it doesnt hide any objects that are in the thick of the fog, those just become hard to see, however if you do use the fog commands it would be best to set the cameras range at the same range as the fog."


OK, right, going to edit again.

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1
Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 10th Sep 2006 16:37 Edited at: 10th Sep 2006 16:38
@Mr Kohlenstoff

Use vectors to do distance calculations like this:

SQRT way:


Vector way:


Make vector3 number 1 at the start of the program and always use it for distance calculations, to avoid remaking it each time.
i.e. result = make vector3(1)

The vector distance method, for some reason (I dont know why!) is about 1.5 -> 2 times faster than SQRT.


RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 10th Sep 2006 17:34
Dont continuously call object property commands, or for that matter, any commands that retrieve data, that hasn't changed since the last time you called for it. Instead, store it in a variable at necassary points, eg;

Dont:



Do:

X# = OBJECT POSITION X(20)
Y# = OBJECT POSITION Y(20)
Z# = OBJECT POSITION Z(20)

FOR X = 1 TO 10

POSITION OBJECT X,X#,Y#,Z#

NEXT X

[/code]



Always, ALWAYS cancel as many things out as you can. Also, cancel out in a logical order. For example, for collision checking, if you know for a fact that the only way a collision is going to occur in your game with your character is if the character is moving, then that can be a check right there. However, it makes more sense to first check if the user is moving and then check if a collision occurs, since collision checks would drain the FPS more, than to check for a collision first, and then check if the user is moving.



Re-use as many loops as you can. Even if you need 1 loop that repeats 5 times, and 1 that repeats 10, you can use 1 loop for the process. Like so;



That'll print "X is less than/equal to 5 still" 5 times, and make 10 cubes, in 1 loop.

Your signature has been erased by a mod because it's larger than 600x120...
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 10th Sep 2006 17:46
Quote: "But it's true, that floats or integers need more RAM than booleans, you can test it."


Well, assuming they all had the same use then you would be correct, but since floats store decimals there uses are alot different from integers.

And i'm still not sure what your argument is about sin/cos, i use it alot to either displace objects movements for things like fps gun bobing, or to project objects at verious angles, i fail to see how saving the result of a sin/cos/tan operation would be beneficial unless you intend to do the same operation to many objects.

And an octree is a way of storing data, very usefull for collision checks and such, say you had your scene which was 100x100x100 units, and i had placed 1000 objects randomly inside, i would then cut the area into 8 hence oct, peices, and sort my objects into those, and should any of those areas contain more than 1-2 or whatever number I limit to each cell, then i would create yet another 8 cells inside of the parent, eventually cutting down every objects into an array, so if i wanted to check if any objects where close to position 50,50,50, i would simple look at the array and first check the top teir of my array, and see how many objects occupy that slot, if its more than 2 then i would open up the child cell and check how many are in that, eventually leaving me with 1-2 possible objects within my designated distance, so instead of having to check 1000 distances, i merely had to go through a few array slots and check 2 ranges.

Hallowed are the ori.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 10th Sep 2006 18:06
Quote: "Yes, I tested it and saw, that all variable-types have the same (nearly?) speed. But it's true, that floats or integers need more RAM than booleans, you can test it."

Integers are handled faster than small datatypes, due to the way processors work.

Tempest - P2P UDP Multiplayer Plugin (DBP/DBCe)
Download the free version
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 10th Sep 2006 18:42 Edited at: 10th Sep 2006 18:43
Quote: "And i'm still not sure what your argument is about sin/cos, i use it alot to either displace objects movements for things like fps gun bobing, or to project objects at verious angles, i fail to see how saving the result of a sin/cos/tan operation would be beneficial unless you intend to do the same operation to many objects."


It's just, that using an filled array with sin, cos and tan is faster to use than the dbp-functions sin, cos and tan. Just look at this example:



Compile it, and if you press the controlkey, it's much slowlier than reading the array. At least on my computer, but I think this is true on every one.


Quote: "Integers are handled faster than small datatypes, due to the way processors work."


Interesting... so integers are also faster to use than words, bytes and booleans?


Quote: "Dont continuously call object property commands, or for that matter, any commands that retrieve data, that hasn't changed since the last time you called for it. Instead, store it in a variable at necassary points, eg;"


That's right, and I already wrote it. I meant that with "Don't use #constants, representing dbp-functions'. Because most of the functions (like sin etc., object position x(), screen width()...) need more time than just reading a variable.

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 10th Sep 2006 19:28 Edited at: 10th Sep 2006 19:40
Quote: "Interesting... so integers are also faster to use than words, bytes and booleans?"

If the processor is 32bit, it'll handle 32bit datatypes the fastest. Of course, the difference may be so small you won't notice it.. Altough this is the kind of optimization you would make in C/C++, not DBP.

And by the way, booleans take up the same space as bytes.

Tempest - P2P UDP Multiplayer Plugin (DBP/DBCe)
Download the free version
RiiDii
19
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 10th Sep 2006 19:45
#constant doesn't run any faster or slower than any comperable command or variable. All it #constant does is tell the compiler to a find/replace routine during compile (which probably does make for a slower compile). After that, the code is what it would look like as if you didn't use #constant.

For example;

# Constant SW Screen Width()
x= SW / 2


is the same as

x= Screen Width()/2

during run-time because the compiler has replaced occurences of "SW" with Screen Width(). You can verify this by running a test code in step-through debug mode.

Soem really greatd suggestions there. I once had these functions in my programs, and I stopped using it because I figured it didn't make much of a difference. Now I see that it does.



These functions were used in sections of code where Object positions were used in several calculations to follow.


Open MMORPG: It's your game!
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 10th Sep 2006 19:59
I never said anything about constants

Im saying that if you're moving your character in your game loop, and then afterwards you decide to position the camera at the characters positions, position the user's gun at the characters position, and use a raycast starting at the characters position (this is just an example), instead of calling OBJECT POSITION XYZ() 3 times per loop, it can be shorted to 1 call by placing the value into a variable and just looking for the variable instead. This is faster, but ofcourse only works in examples where the variable wont be changing, or wont require updating for the next routine to work.

Your signature has been erased by a mod because it's larger than 600x120...
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 10th Sep 2006 20:26
@Riidii: If you mean me, I didn't say, that #constants have a different speed than commands (I also know, that they are just going to be replaced..). I just meant, that using #constants, is as bad for the performance, as using the DBP-Functions itself. So - as you already mentioned - sw would be the same as screen width(), if sw if declared as a #constant, representing the screen width() before.
What I wanted to say to #constants was, that it's better to use globals then #constants or DBP-Functions.
For my engine (nothing else then a collection of functions with an editor) I am saving the Object position for example in an array, and everytime I want to move my object, I use an Object_Moving-function, which automatically positions the object and updates the array. So I am always able, just to check the array-values.

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1
RiiDii
19
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 10th Sep 2006 22:45 Edited at: 10th Sep 2006 22:46
Fair enough. Perhaps your statement needed clarification . Thank you for clarifying it.

Sorry Ruccus, I was replying to the first post since this was my first read through.

I agree with most everything else stated - this is some great work as it not only states how to reduce resource use, but Mr. K. has also provided some great demonstrations to support his claims.

Oh wow. Look at all those spelling errors in my first post. I was half asleep I guess.


Open MMORPG: It's your game!
jinzai
17
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 10th Sep 2006 23:25 Edited at: 10th Sep 2006 23:33
Very good stuff, Mr. Kohlenstoff. I really like your clean straightforwrd coding style, too.

Constants are evaluated at compile time, so that one is a straight assignment versus a lookup of a variable. That was clear at the beginning, but now...not so much. They work like MACROS, so it is replaced during the compile. There would be zero difference from calling a DBPro function in the usual fashion.

Anyway, thanks for the tips. I agree...what you are creating is a state machine. The fastest, cleanest code would deal with objects in a straightforward fashion. Of course, all of the various math trick apply. There are alot of integer math tricks that can be used in certain (narrow) situations. Avoiding division of any kind is good way to pick up a few cycles, for example.

I think that as was pointed out earlier, profiling in some fashion can reveal bottlenecks...but, performing an essentially useless loop millions of times is not necessarily going to reveal any truths about what works in someone else's code. Mostly, it is how you approach the problem that counts in the end. (Canned code and data, avoiding too much expensive math, preferring faster routines over more complete and slower ones, all of it.) I think that your coding style looks too simple to others. (It is a little deceptive, I think.) That is not really your problem.
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 11th Sep 2006 04:06 Edited at: 11th Sep 2006 14:24
Quote: "There would be zero difference from calling a DBPro function in the usual fashion."


As I've been saying, this is true only if you'll be calling the constant once. Otherwise, its better to use a variable than a function, if the variable isnt changing.

Your signature has been erased by a mod because it's larger than 600x120...
jinzai
17
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 11th Sep 2006 05:45
I do not agree. The constant is evaluated at compile time, it is not a variable...it is a constant. That is my understanding of constants in DBPro...do I have an incorrect understanding?
Bmad6
18
Years of Service
User Offline
Joined: 25th Aug 2005
Location: Virginia, United States
Posted: 11th Sep 2006 07:20
Yes, if I understand you correctly.

constants aren't really "evaluated" at compile time - it's more like "inserted"

so, if you write "#CONSTANT x=screen width()" in your code, then you use "y=x" 100 times, all dbpro does at compile time is change it to "y=screen width()", so you get the same speed hit as if you had just written "y=screen width()" 100 times

Harvard's Law, as Applied to Computers:
Under the most rigorously controlled conditions of pressure, temperature, volume, humidity and other variables, the computer will do as it d*mn well pleases.
Cash Curtis II
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 11th Sep 2006 07:20
jinzai, all they're saying is that accessing a Constant is slower than accessing a primitive variable. That will always be true, because the Constant is really just a function. Every time you call it, the function has to be evaluated. If the function will always return the same value and will be called over and over, the value should just be accessed by a variable.

Also, a boolean and byte take up the same space in DBP.


Come see the WIP!
jinzai
17
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 11th Sep 2006 07:41
Wow, but he even clarified it twice...he was referring to using constants versus global variables, not function calls. I said that there would be no difference using a constant to call a function versus typing the function name directly, what am I taking stupid pills, here?
Cash Curtis II
19
Years of Service
User Offline
Joined: 8th Apr 2005
Location: Corpus Christi Texas
Posted: 11th Sep 2006 08:09
You're right, there is no difference doing that. That's not what he's saying though.

He's talking about substituting a function call with a Constant. The compiler evaluates every constant as the function. If you can replace functions with variables, it will run faster.


Come see the WIP!
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 11th Sep 2006 10:01
Quote: "How do you hope to save sin/cos in an array?"


Unless you need absolute accuracy, storing sin/cos in an array per degree is the best way, and an accepted method. In 99% of cases, you are turning towards an angle, and by the time you get there the angle has changed again. Even when it's not a gradual movement, accuracy of less than 1 degree isn't required.



RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 11th Sep 2006 14:24
Cash Curtis has got what I meant . I think I used the word constant 1 too many times in my previous post by accident, edditing now.

Your signature has been erased by a mod because it's larger than 600x120...
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 11th Sep 2006 15:49
Texture resolution is a major factor, as major as polygon counts - as it's all about your fill rate - so using sensible texture resolutions is vital. As a rule, I find 512x512 is plenty for walls, floors, stuff like that - but for meshes consider how big the texture is gonna be on screen, using a texture that's too high a resolution can cause jagged interference that actually looks far worse than using a smaller resolution.

DDS format images can be incredibly small, like upto 1/10th the original file size - they also support alpha, and pre-calculated mipmaps. The best thing about DDS textures though is that they load right into memory as is - so they load very very quickly, take less texture memory, and can speed up object loading too as there's no need to work out those mipmaps.
The plugin from nVidia for Photoshop is great, go get it now. DDS is not a good image format for loading and editing, so try and save DDS for the final version and use your art packages native format as the master format (PSD recommended as Deep Exploration supports it, great for previewing your texture work).

''Stick that in your text and scroll it!.''
Zizaco
18
Years of Service
User Offline
Joined: 17th Apr 2006
Location: Brazil
Posted: 11th Sep 2006 15:53
Quote: "Use Level-of-detail by loading two meshes (and two textures) for each object, and replacing the high-poly-object with the low-poly one, when the camera is far away enough."


Yes!
If would be faster and easyer if this works http://forum.thegamecreators.com/?m=forum_view&t=88377&b=1
The new lod command of the U6.2

Sorry for my bad inglish!
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 11th Sep 2006 16:32 Edited at: 11th Sep 2006 20:35
**UPDATE**

Added a new point to the basics:

If you use for-next-loops with a target-value, which doesn't change, don't let the target be a function, but a variable. If it is a (User-defined or DBP) Function, the program checks it in each round.

There's also an example-code. In practice, if you e.g want to draw dots on each display-pixel, don't use this code:



But this:



If you use the first code, the program always checks, if the x- or y-value is higher then 'screen width/height()', what is a DBP-function being more time-intensive then checking a variable.

Edit: The example of this post isn't as good to see the effect as the example of post 1, because here the functions just have to be checked around 640*480 times, and in the code of post 1 much more often, to show the advantage of using variables instead. If you use this in many loops of big projects, it may save you some frames, but if it are just some small loops, you won't see any change, of course.
But that's the case of many tips, they bring you maybe 1-2 fps, but if you check your code for all the aspects, the effect might be good.


Don't use Text-Layout-Commands like 'set text size' or 'set text font'. They are very bad for the performance, even if you use them just one time to print one letter.

Also with example-code in the first post.

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1
RiiDii
19
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 11th Sep 2006 21:05 Edited at: 11th Sep 2006 21:09
For the For-Next loops with the target as a function, I don't get that much of a difference (and sometimes the function is a bit faster). I also found that the Rnd() function was adding variation to the results (which means the Rnd() was slowing things down a bit as well), so I removed it to issolate what is being tested; the target function/variable.




Quote: "The compiler evaluates every constant as the function."

Here's how the compiler works with constants. The compiler simply does a find/replace during compile time. You can see this by running a test code in step throug debug mode.

If you have a #Constant = a value, then that value is replaced everywhere the #Constant is in the code - during compile. During execution, the executable only sees the value.
If you have a #Constant = a variable, then that variable is replaced everywhere the #Constant is in the code, and is therefore not "constant", but is a variable.
If you have a #Constant = a function, then that function is replaced everywhere the #Cosntant is, and also is not a constant, but is a function. I have used this many times to make my own "commands" in DBPro.

So;




Open MMORPG: It's your game!

Attachments

Login to view attachments
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 11th Sep 2006 21:18
Quote: "For the For-Next loops with the target as a function, I don't get that much of a difference (and sometimes the function is a bit faster)."

It only makes a difference if the function takes any time at all to process.

Tempest - P2P UDP Multiplayer Plugin (DBP/DBCe)
Download the free version
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 11th Sep 2006 22:35
When I compile this code:



I get 14 fps in the fast-mode (target=variable) and 7 fps in the slow-mode (target=screen width()). I guess, that shoes the advantage of using variables instead... If it's different on your computer, that's strange. I think, checking a variable should always be faster then checking the value of a function...

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 14th Sep 2006 17:37
Edited a new Example-Code to the first post.

You must have some more ideas of speed-improvement...
If not, I'd appreciate some more comments, test-results, example-codes or anything else..
Thanks

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1
RiiDii
19
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 14th Sep 2006 20:27
Here's an interesting test, and it solves more than performance problems. In some cases, attaching limbs can be much more efficient than individual objects. While attaching the limb can be slow, once it is attached performance can be improved. There are other limitations to take into consideration, such as what can be accomplished with a limb verses an object. This demo shows that not only are 1000 limbs much faster than 1000 objects, but that handling orbit information internally is easier and faster as well (note; I didn't even bother to try and handle the orbit information for the 1000 objects).




Open MMORPG: It's your game!
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 18th Sep 2006 17:23
And a next

**Update**

Use the sync-command just as often as neccessary. You don't have to update the screen oftener then 30 times a second, so if you program runs at more then 30 fps, it runs even faster with this technique.

Example-Code:


If you want, you can use the screen-fps-function of this code for your projects. It gives you the power to decide, how big the Time-Delay for fps-value-updating is, so if you want the exact average-value of 10 seconds for the fps-rate, set the FPS_ChangeDelay-Value to 10,000. If you want it to be updated 10 times a seconds, set it to 100.
So you have more power then if you use the normal 'screen fps()'-command, and it also counts the fps, if you don't sync your program in loops, which isn't the case if you use screen fps().

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 18th Sep 2006 17:54
That's a pretty poor suggestion, sure it would speed the game up I guess, but whats the point? most games dont do much calculations and stuff, and most of the loop time is spent rendering, and a better suggestion would be to use vsync, as that potentially stops the app using 100% cpu, and also stopping texture tearing.

Hallowed are the ori.
RiiDii
19
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 18th Sep 2006 21:34
I used a similar technique for a pinball game. The problem was that as the framerate increased, the timer-based movement increased as well. With the pinball moving faster, collision checks were less accurate. While the pinball movement/collision by itself was not a problem (easily fixed with ray-casting). The problem was that raycasting only works well against static object. A second moving object, like the flippers, are not in the place the ball will be when the check is made, so the raycast returns false.

The solution was to make three moves per frame, forcing each move to be smaller - more granular. Of course, adding on your technique of cycling until the frame is ready to update would have been better.


Open MMORPG: It's your game!
Mr Kohlenstoff
17
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Germany
Posted: 22nd Sep 2006 19:18 Edited at: 22nd Sep 2006 19:19
**Update**

- I changed the symbol of the last hint (using sync just 30 times a second). If you do it like this... you would "lie" to the user, because the fps wouldn't show the screen updates then... sorry for the mistake.

- Added a new point to "landscapes":

Use more then one terrains and use LOD for the Polygons and the texture. You could split a 2048^2-heightmap into 8*8 parts and the parts near by the camera should have most details, and the parts far away less polygons and a low-res-texture. It might be hard or much to code, but I guess it speeds up the game a lot, and you can use very big landscapes.


I didn't test it, but it should do it's job, and I'm trying to code some functions for it for my engine for some hours, but it's really complicatet.

Visit the DBPro - Speed up your game-Thread. http://forum.thegamecreators.com/?m=forum_view&t=88661&b=1

Login to post a reply

Server time is: 2024-05-12 15:24:05
Your offset time is: 2024-05-12 15:24:05