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.

Code Snippets / [DBP] - Fast dot

Author
Message
Aurum Knight
15
Years of Service
User Offline
Joined: 15th Jul 2008
Location: the suburbs of nowhere
Posted: 17th Jun 2011 10:01
Here's some code to draw a dot very fast. It's very useful if you're drawing a relatively small number of dots and don't want to be slowed by the 'dot' command.



I tested it, and it works better without using 'lock pixels'. It's way faster than dot on its own, and still faster when DOT is using lock pixels. However, if you start using DOT with lock pixels in bulk, at a certain point it becomes faster to use DOT with lock pixels than this code.

Heres the code I used to test it. Move the mouse up and down to modify the times each method of drawing a dot is used per second.


On my machine, DOT and this code become about equal at about 4500 times (I'm too lazy to make it properly average the results though). Above that DOT with lock pixels is faster, and below that my code is. I'm interested as to other people's results.
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 18th Jun 2011 09:05 Edited at: 18th Jun 2011 17:12
Commands like Dot/Point are generalized in graphics libraries, so you can usually roll your own and get better through put by taking the situation into account. So if you don't need random pixel access, then we can get rid of the pitch Mult and prolly the x access mult also.

If all the programmer wants to to is run through a buffer row, by row. Something like this would probably work out better.

(Untested)



So the cost per pixel is less, but there's still a lot of FOR/NEXT overhead, since DBpro performs message checks in them. So unrolling the inner loop would no doubt further reduce the cost per pixel.




Here we're assuming the buffer is a even mult of 16 pixels (it might not be), if it's not you'd have to catch those extra pixels. But you get the idea.

Aurum Knight
15
Years of Service
User Offline
Joined: 15th Jul 2008
Location: the suburbs of nowhere
Posted: 20th Jun 2011 22:15
Oh I see what you're saying, less multiplying and calculations, that's an interesting thought. I wonder if you could gain even more speed by making something like batching, like on Cloggy's D3D, using an array of dwords to store the pointers, and then using a simple FOR loop and possibly unrolling it as well like your example for even more speed.

If I run into something that requires that kind of speed any time soon, I'll try it.

Login to post a reply

Server time is: 2024-04-24 17:28:13
Your offset time is: 2024-04-24 17:28:13