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 Discussion / strange optimisation

Author
Message
Silverman
13
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 5th Sep 2011 15:43 Edited at: 5th Sep 2011 17:26
hi,

I make a program to spy slowdowns of my source code when I found that
(position object + object collision) in the same frame, ---> very slow. But (position object) in an odd frame, and (object collision) in a even frame, ---> fast!

Change values at line 16, and put cursor mouse on coloured bar to see elapsed time.


DirectX 9.0c (February 2010)/ DBClassic v1.13
Fluffy Rabbit
User Banned
Posted: 6th Sep 2011 02:58
You will find the same speed boost if your objects are positioned after your collisions are checked for.
Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 9th Sep 2011 00:28
@Fluffy Rabbit
Quote: "You will find the same speed boost if your objects are positioned after your collisions are checked for."

One problem I can see with this is that your object would already be through the wall before you had a chance to test if it will go through the wall.

@Silverman
Interesting. Would you agree that essentially you're just breaking up the tasks to happen every other loop? Wouldn't that seem like a performance booster for just about anything. In your example though, collision testing in DBC is process heavy so it really makes a difference here.

One other optimization we can add to this mix is to dump all other DBC collision except for MAKE OBJECT COLLISION BOX flagged without rotating collision box. If you have generally even sized objects, you can wrap them in a collision box and the performance will improve greatly over the other collision (except static collision which is as fast if not faster).

Here's your code now using MAKE OBJECT COLLISION BOX. You'll noitce that the speed difference between OPTIMIZE=0 and OPTIMIZE=1 is very small but the program runs faster:



Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 13th Sep 2011 11:33 Edited at: 13th Sep 2011 11:33
@Latch-

I am sorry for that. I was only basing my post on asumption. You bring up a very good point, though. DarkBASIC's collision routines are very slow. Non-rotated collision boxes are a much more efficient algorithm, but even that seems fairly slow. I think it has something to do with DarkBASIC in general using higher-level code, although that baffles me as I heard that DarkBASIC was written in C.

Whatever the reason, Sparky's DLL or even primitive hand-made collision algorithms seem to run slightly faster, but the real optimization is to keep the number of objects that one is checking collisions for down. The bottom line is that the more the computer has to do, the longer it takes. So, if collisions were only checked for a large section of wall as opposed to every brick, the code would run considerably faster. Again, this baffles me considering all of the pixels that the game has to render as opposed to the relatively small number of objects.

Perspective-scaled texture mapping is faster than a few dozen collision boxes? I think not. At the same time, a texture mapping algorithm seems to run faster in pure software than on an integrated graphics card, so it's not a processor issue at all.

I think it's an issue of optimization. For whatever reason, Microsoft's code (or the code of whoever writes the rendering engines) seems to be faster than Lee Bamber's code, or rather, rendering code is faster than standard collision and logic routines.

Case and point: I wrote a voxel rendering algorithm in FreeBASIC and can get it up to over 1000 voxels at well over 100 FPS, but as soon as I want to do something as simple as play a sound or rotate a sprite, my framerate can drop to less than 30. Maybe it is because sprite rotation and audio encoding processing take as much CPU time as rendering a whole scene, but somehow I think it goes deeper than that. For whatever reason, the math functions that are used in everyday code (addition, subtraction, multiplication and division) seem to be slower than whatever code is used in rendering.

I know I brought this thread way off track, but I think it's an interesting concept. How can something so visual be easier for the computer than a little bit of math?
Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Sep 2011 06:34 Edited at: 14th Sep 2011 06:40
Quote: "I think it has something to do with DarkBASIC in general using higher-level code, although that baffles me as I heard that DarkBASIC was written in C."

I think DBC is using retained mode which is actually a higher level Direct x. Retained mode was designed to be an easy way to execute several complex direct x type codes with a (few) simple command(s) - sorta in the same spirit as BASIC. So if you create a high level language out of an already fairly high level set of coding routines - I guess you get a bit of a double whammy when it comes to speed.

Quote: "I know I brought this thread way off track, but I think it's an interesting concept. How can something so visual be easier for the computer than a little bit of math? "

I also think it's very interesting. I don't know for sure that the visual aspect is easier for the computer to handle but perhaps, depending on the graphics processor, the dedicated hardware for specific tasks - texturing, shadows, lights, etc. may be faster than the CPU sharing all of the other operations of the machine including math. I did some timing tests between math in DBC and math in a DLL written in C and there was very little difference in the speed of carrying out those calls in DBC. A single call to a math function in a DLL took about the same amount of time as a single call to the same type of math function in DBC. It could be because it takes time for DBC to break down the call to a DLL into byte code that DBC can execute - so both commands end up taking about the same amount of time.

However, if I run a loop of say a+b in DBC and a+b in a C dll (called from DBC) I can run millions of iterations in the DLL and the time is negligible compared to how long it would take DBC to run the same number of iterations.

So in theory, if you can loop your code or your intensive processing over huge arrays or even pixels in a DLL or machine code, you can get incredible seeming performance out of BASIC. What that suggests is, all the rending and heavy pixel and drawing stuff is being handled behind the scenes where all of those calculations are taking place in machine code, but when you start interacting with that information, you are having to go through the BASIC interface which has to be interpreted. The screen and object positions and so forth are being calculated regardless. The main goal of Direct X is to render something so it's really focused on the video aspect (hardware). So once other commands are being sent through the BASIC interpretter, those don't become direct x calls A) if they aren't related to display or B) until they have been properly interpreted. I'm just guessing.

I'm not sure if FreeBASIC is compiled or interpreted but I suspect it's interpreted so when the math calls, or calls to sound and other things are executed, it has to handle those things "on the spot" so to speak.

Quote: "Whatever the reason, Sparky's DLL or even primitive hand-made collision algorithms seem to run slightly faster, "

Yeah, it's actually a bit surprising. For example, sphere collision should be one of the fastest types of collision check because it's really just a distance check between the center of two objects and adding the radii of the two collision spheres that surround them and seeing if that distance is within that sum. Actually I put together an example of this.

I set a bunch of spheres to sphere collision and test the built in collision for that. Then I run a test where I turn off the internal collision and calculate the sphere collision as I previously described. Following, is the example.

Use the arrow keys to move around the red sphere. Press SPACE to toggle between the built in sphere collision and my custom collision. Just based on FPS, on my machine the custom collision runs at about 30 to 60 fps higher:



Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 14th Sep 2011 11:15 Edited at: 14th Sep 2011 11:17
@Latch-

Actually, the slowness of DarkBASIC's collision routines was mainly what I was talking about. Where is the abstraction? All of the collisions are checked on the C level, so where is the lag? Is Lee Bamber the worst programmer on earth, or is there a demon living inside DarkBASIC that likes to eat processor time when it detects collision checking?

On your other points:

I believe that DarkBASIC 1.2 no longer requires Direct3D retained mode- correct me if I'm wrong. However, it would be the interpreter that slows it down. You already know this.

As far as your math stuff goes, you've lost me. I don't understand math. The reason why loops take so long to render in DB is because of the 1 MS delay imposed by DarkBASIC, most likely as a result of 1 MS being the shortest amount of time that a system sleep call allows.

FreeBASIC is compiled, but I like to copy and paste inefficient code off of the internet.

By the way, thanks for the collision routines.

EDIT: Not to imply that your code is inefficient.
Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Sep 2011 20:18
Quote: "I believe that DarkBASIC 1.2 no longer requires Direct3D retained mode- correct me if I'm wrong."

My suspicion is that it still does - I think d3drm.dll is still required (that's the retained mode dll)

Quote: "Where is the abstraction? All of the collisions are checked on the C level, so where is the lag?"

I dunno. It should be fast unless for some reason it's always checking to see if all possible 65536 objects are colliding.

Quote: "...is there a demon living inside DarkBASIC that likes to eat processor time when it detects collision checking"

Maybe! It's probably just non optimized code or something that's repeating that shouldn't be. That's why DBPro was created to correct some of the problems with DBC and speed it up by compiling it vs interpreting it. But, like you said, use custom code or a 3rd party dll to speed things up in DBC.

Oh, and here's another trick I've used from time to time:

Create 2 collision objects that are hidden. All other objects in the scene have collision turned off. Position 1 collision object where ever the player object is moving. Place the second object on the other objects in a loop and test between the hidden player object and the looped object. If there is collision, exit the loop to save a bit of time. Overall it's pretty quick.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 17th Sep 2011 02:49
@Latch-

That's a great idea. By the way, I have confirmed that DB 1.2 does not require d3drm. Also, if Bamber wanted to optimise DB, why does he charge for this "upgrade"?

Login to post a reply

Server time is: 2020-08-15 11:43:42
Your offset time is: 2020-08-15 11:43:42