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 / [DBC] POINT command substitute using GDI

Author
Message
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 20th Apr 2008 21:39 Edited at: 22nd May 2008 20:14
In response to a question about an alternative to the POINT command (retrieving a pixel color at coordinates x,y) I suggested using the win32 api and a GDI command. I hadn't actually done it myself so I thought I would.

The following snippet creates a function called gdi_point(). If you go through the example you can see what dll's need to be loaded and any setup required.

For this to work, the app has to be in WINDOW mode, and I haven't compensated for 16 bit - so it only deals with 32 bit color.

There is a test between the gdi_point function and the POINT command from DBC. The test times how long it takes to get through a 200x200 pixel field and it positions the mouse as it checks each pixel. Visually, just looking at the mouse, you can see the gdi way is ridiculously faster. In fact, I haven't had the patience to wait for the point command to finish.



Enjoy your day.
Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 20th Apr 2008 22:07
Works in dbp!

I did this test for whole screen!
And results:
GDI 16926
Point 22085

Your signature has been erased by a mod because it was too big
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 20th Apr 2008 22:40 Edited at: 22nd May 2008 20:18
@Roxas

Thanks for testing it. I'm glad it works in DBPro. From your results, there is not as big an improvement as it is in DBC, but still an improvement none the less!

Wow, DBPro must natively be so much faster than DBC. I redid the test using just a 20x20 area and GDI did it in 6ms and POINT took 7090! Like I said, I couldn't wait for POINT to finish 200x200. Just extrapolating forward, that would be over an hour with this test using POINT in DBC.

[EDIT]
I just realized that I have the sync rate set to 60 in the example. Setting it to 0 improves the perforamnce of the POINT command, but not by much. The GDI function is still faster.

And I almost forgot to show that the GDI command returns the same value as POINT. Just point the mouse at different colored objects on the screen to show the color values.

(NOTE: I think part of the reason POINT in DBC is so slow is because it automatically calls SYNC when it is used. So if you have it in a loop, it calls SYNC everytime it is encountered. Try commenting out cpoint=point(mousex(),mousey()) in the example. )



Enjoy your day.
Mistrel
Retired Moderator
19
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 21st Apr 2008 08:03
GDI: 1235
Point: 5388

This is on DBP.

http://3dfolio.com
TEH_CODERER
21
Years of Service
User Offline
Joined: 12th Nov 2003
Location: Right behind you!
Posted: 21st Apr 2008 11:36
Yep, seems to be about 4 times faster here as well. Thanks for the code, great work!

Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 22nd May 2008 20:13
I found a slight error in the function. Instead of using the variable mem to identify the memblock, I had left it hard coded as 1. I'll update the function in the previous posts.

Enjoy your day.
Not_Maindric
17
Years of Service
User Offline
Joined: 10th Jul 2007
Location: Omaha, NE
Posted: 24th May 2008 07:27
... wow.....


571 GDI
658630 Point.....

Major increase.

Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 25th May 2008 23:21
Just discovered another bug or two. In DBC, if the display area isn't set as large as the desktop area and the window is maximized, the function returns unpredictable results. Probably has to do with how dbc is offsetting the client area. I'll look into it but maybe someone knows how to solve this right off the cuff. Any suggestions?

Enjoy your day.
AndrewT
17
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 28th May 2008 01:55
GDI: 587
POINT: 560

That's with DBP.

90% of statistics are completely inaccurate.
Atreides
21
Years of Service
User Offline
Joined: 11th Oct 2003
Location: Switzerland (but NOT on a mountain !)
Posted: 29th May 2008 23:02
I use DBP.
I ran the code.

I get 829[ms] with GDI.
I get 1421[ms] with Point.

But since I want optimized code, I added "lock pixels" and "unlock pixels" for both tests.

I get 880[ms] with GDI.
I get 298[ms] with Point.

Result : point is faster when it is optimized.

The sleeper must awaken !
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 30th May 2008 02:44
DBC doesn't have those options, unfortunately.
What is locking pixels anyway?

Enjoy your day.
Atreides
21
Years of Service
User Offline
Joined: 11th Oct 2003
Location: Switzerland (but NOT on a mountain !)
Posted: 30th May 2008 23:21
Locking pixels err... it improves the speed of reading/writing on the screen.



Hmm... I read somewhere that DBC can use memblocks too. It could sometimes be useful to make a memblock from the bitmap zero (the screen) and to access its data, instead of using point.

Of course, that'd be too slow if you modify the screen often. When I used DBC, I always did my best not to use point in real time

The sleeper must awaken !

Login to post a reply

Server time is: 2024-11-25 02:37:39
Your offset time is: 2024-11-25 02:37:39