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 / Faster Line Algorithm... Benchmark it with me

Author
Message
Jess T
Retired Moderator
21
Years of Service
User Offline
Joined: 20th Sep 2003
Location: Over There... Kablam!
Posted: 27th Feb 2006 07:30 Edited at: 27th Feb 2006 13:49
Hey guys,

I just now needed a line algorithm ( not actually drawing lines, so I couldn't settle for the Line() command ), and so I googled, and got two major versions, both of which are variations on Breshnam's Algorithm...

Now, it seems as though the first should be faster ( less to do in the 'For' part ), but it turns out that both run at the same speed ( apparently ).

Just so I can be certain that my computer isn't being difficult, can you test it for me?



As you can see, there's two versions in there, each one is run 5000 times for each possible orientation ( so that all branching coditions are tested ) giving a grand total of 80000 lines drawn

I get it reading about 1460 ( or something about that ) for both, each time I run it... Strange, no?

Anyhoo, If you could give 'er a whirl, I'd muchly appreciate it, thanks

Jess.

[EDIT] Just realized I left a 'Cls' in the second one... Am re-testing now [/EDIT]

[EDIT2]
Ok, after re-testing, I still get exactly the same... I'm starting to think that this function's so blisteringly fast that I'll have to use the High-Res Windows timer within the function itself, return the time from it and add it up that way ( bypasses all the 'For' and 'Go find that function' calls )...
[/EDIT2]

[EDIT3]
Damn typo... I put in an extra number for the times I was getting... - Fixed now ( should be 1460, and I had something like 14250 )
[/EDIT]

Team EOD :: All-Round Nice Guy
Want Better dbHelp Files?
Essence
22
Years of Service
User Offline
Joined: 12th Oct 2002
Location: The Netherlands
Posted: 27th Feb 2006 07:44
Scilynt
22
Years of Service
User Offline
Joined: 13th Nov 2002
Location: .-#-.
Posted: 27th Feb 2006 08:52
Typo in your code, you're displaying t1 twice.

Fixed, I get 1198 for the first, and 1073 for the second.
Jess T
Retired Moderator
21
Years of Service
User Offline
Joined: 20th Sep 2003
Location: Over There... Kablam!
Posted: 27th Feb 2006 10:08 Edited at: 27th Feb 2006 10:09
Damn it!

I could've sworn I checked all that

Thanks anyway, Dan... Now I can compare them properly

[EDIT]
So, now I get proper readings... 1429, and 1335
[/EDIT]

Team EOD :: All-Round Nice Guy
Want Better dbHelp Files?
Zone Chicken
21
Years of Service
User Offline
Joined: 25th Jan 2004
Location: `~-..-~`~-..-~`
Posted: 27th Feb 2006 12:43 Edited at: 27th Feb 2006 12:47
2916 1st
973 2nd

Your signature has been erased by a mod -- please resize to under 600x120...
x1b
20
Years of Service
User Offline
Joined: 19th Sep 2004
Location:
Posted: 27th Feb 2006 12:55
1st: 1335
2nd: 1335


Sven B
20
Years of Service
User Offline
Joined: 5th Jan 2005
Location: Belgium
Posted: 27th Feb 2006 12:57
1066 both

It's the programmer's life:
Have a problem, solve the problem, and have a new problem to solve.
Barnski
19
Years of Service
User Offline
Joined: 26th Jan 2006
Location: Switzerland, Zurich
Posted: 27th Feb 2006 13:09 Edited at: 27th Feb 2006 13:10
Nice fast algorithm the second one!!

mine is ten times slower! May I just copy your code JessTicular? I could need it for my line of sight algorithm...

times:
1) 1921 ms
2) 1735 ms

EDIT: fix the code by changing the output variable from t1 to t2!!
now it just prints out the same time value twice! thats why you guys get the same results.

-- I just started with DarkSDK, by translating DBP Projects. --
Jess T
Retired Moderator
21
Years of Service
User Offline
Joined: 20th Sep 2003
Location: Over There... Kablam!
Posted: 27th Feb 2006 13:50
Barnski,

Sure thing, go for it, mate!

I can't remember where I found it, but a quick google for something along the lines of 'Breshnam Line Algorithm' will bring up hundreds of results

Team EOD :: All-Round Nice Guy
Want Better dbHelp Files?
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 27th Feb 2006 13:59
1003 and 1000

Halowed are the ori.
Nicholas Thompson
20
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Bognor Regis, UK
Posted: 27th Feb 2006 14:23 Edited at: 27th Feb 2006 14:24
I get:
1) 1107
2) 988

spec: 4400+ Athlon X2, 7800GTX 256Mb, 1Gb DDR400 RAM.

I wrote a line algorithm recently, midpoint method... Lemme go look for it...

EDIT:


That works on the ide of using an empty memblock, writing in DWORDS for the line points and then making it into an image. This could easily be modofied to add in antialiasing too (I have notes from uni on how to do that somewhere).

Barnski
19
Years of Service
User Offline
Joined: 26th Jan 2006
Location: Switzerland, Zurich
Posted: 27th Feb 2006 15:24
Ok thanx,

mine was also a translation of Bresenham's algorithm, but compared to these variations it was 10x slower... possibly I used the original one.

greets,
Barnski

-- I just started with DarkSDK, by translating DBP Projects. --
Barnski
19
Years of Service
User Offline
Joined: 26th Jan 2006
Location: Switzerland, Zurich
Posted: 27th Feb 2006 17:00
I have just translated the Bresenham's algo for the fast integer circle function, using your _dot function to code looks like: (very simple&short)



It just calculates one octal slice of the circle line, and uses the result for all the other slices of the circle!

I can use this in conjunction with the line-algorithm to make my Line Of Sight, or, better called, Range Of Sight. Maybe it helps some of you too!

greets,
Barnski

-- I just started with DarkSDK, by translating DBP Projects. --
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 27th Feb 2006 18:57
1st: 1807
2nd: 1674


IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 27th Feb 2006 21:30 Edited at: 27th Feb 2006 21:32
Get rid of the _dot function and move the code inline. Just caching the memblock size and pitch of the buffer will get you a massive increase in speed. All of that memblock access is killing things.

You might get it even faster if you calculate the address and update that instead of the coordinates ... that one will be down to memory access speed



For free Plug-ins and source code http://www.matrix1.demon.co.uk
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 27th Feb 2006 21:38
Yep, it can go faster, just by updating the address rather than the coords ... change the last bit to this:



For free Plug-ins and source code http://www.matrix1.demon.co.uk
Gamefreak
21
Years of Service
User Offline
Joined: 20th Jun 2004
Location: Cyberspace
Posted: 27th Feb 2006 21:51
1st: 1756
2nd: 1678
Mika
21
Years of Service
User Offline
Joined: 30th Jun 2004
Location: South of France
Posted: 27th Feb 2006 22:12
Hi,

1st function : 2739 ms
2nd function : 2313 ms
3rd function : 1256 ms

Michel

ACER TM800 - Centrino 1,3 GHz - 768 Mo RAM
ATI Mobility Radeon 9000 - 64 Mo
NeX the Fairly Fast Ferret
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 27th Feb 2006 22:43
First 1250
Second 32!?

Wow, great coding!


At least farting ferrets are better than stinky stoats.
CodemanV
19
Years of Service
User Offline
Joined: 25th Aug 2005
Location: South Wales Valleys, UK
Posted: 27th Feb 2006 22:55 Edited at: 28th Feb 2006 06:59
Hello I've also been potching with these memblock image thingies.

If you want to slightly speed the algorithms up, try using bitwise shifts for multiplying or dividing a number by 2(<< >> %1) and 4 (<< >> %10)

Also, take the XY limit checks out and just make sure you pass valid image memblock values before calling the drawing functions. If the XY and Radius values passed are valid then the algorithms will generate valid coordinate values.



You should see a slight increase in performance.

:: Edit :: - My apologies, the Code Snippet had a typo where a %10 was %01.
5000 lines took 88ms
5000 circles took 125ms

10000 lines took 179ms
10000 circles took 247ms

:: 2nd Edit :: - More apologies - the code got shuffled or something!?!? Anyway, as of 05:50am it works OK.
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 28th Feb 2006 07:09
A comparison with IanM's code.

1st: 1805
2nd: 1676
3rd: 770

A 118% speed increase over the 2nd function.


Login to post a reply

Server time is: 2025-08-08 16:38:10
Your offset time is: 2025-08-08 16:38:10