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 / problems with point()

Author
Message
chwilly
16
Years of Service
User Offline
Joined: 23rd Feb 2009
Location:
Posted: 3rd Mar 2009 08:55
Is there a bug with the point() command. It is not returning the right numbers. I used Paint.NET to create a png image. According to Paint.NET the rgb values should be 128,128,128, and 64,64,64 and 48,48,48. After loading the png and then displaying it I use point() and then the rgbr, rgbg, rgbb commands to get the color values. The numbers are offset as follows:

for 128, 128, 128 I am getting 131, 129, 131
for 64, 64, 64 I am getting 65, 64, 65
for 48, 48, 48 I am getting 49, 48, 49

I also modified the example program that came with DB in examples/2d/exam07.dba and modified it from random rgb values and specified the above rgb values. It still returns the same offset values even though this is hard coded in the program and not loaded from an image file.

Does anyone know why or what this means?
Benjamin
22
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 3rd Mar 2009 12:52
Could you provide the image and a code snippet please?

Math89
21
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 3rd Mar 2009 13:43
Are your running in a 16 bit display mode? Because it could cause some inaccuracies with colours.

TheComet
17
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 3rd Mar 2009 16:33
try putting "set display mode 640,480,32" at the start of your program, just like math89 said.

Peachy, and the Chaos of the Gems

Yodaman Jer
User Banned
Posted: 3rd Mar 2009 20:14
Doesn't DB only support .bmp images, not .png's? Or is that only in Version 1.13?

BN2 Productions
21
Years of Service
User Offline
Joined: 22nd Jan 2004
Location:
Posted: 3rd Mar 2009 21:10
Side point:

Usually, it IS best to avoid the point command, on account of it being INCREDIBLY slow and it forces a screen refresh I have noticed (which is probably what makes it take so long)

Great Quote:
"Time...LINE??? Time isn't made out of lines...it is made out of circles. That is why clocks are round!" -Caboose
chwilly
16
Years of Service
User Offline
Joined: 23rd Feb 2009
Location:
Posted: 3rd Mar 2009 22:48
That was it. I didn't set the display mode to 32 bit. Is he default 16? Is there a better faster alternative to point()?
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 4th Mar 2009 02:26
The default is 16 bit display.

Quote: "Is there a better faster alternative to point()"


It depends on what you are trying to do. If you are using the point() command in a loop, SYNC (refresh) is automatically called each loop. This example shows what happens. At a Sync rate of 60, it should take 16 or 17 ms to run through a 1000 iteration loop. If you SYNC each loop (which point does) it basically takes 16 ms to get through 1 loop iteration - that means it's about 1000 times slower to refresh each loop:



So, alternatives: if you need to call POINT() each iteration in your main loop, use it as the last command in your main DO LOOP instead of SYNC:



This runs at about 138 fps on my machine.

If your screen doesn't change or changes very infrequently, another alternative is to use a memblock or an array to store the screen information and then get the color of a position by getting the index from the array or the position from the memblock of the screen coordinates. Should be faster if you have to loop through all of the values at once checking for a particular color.

I once created a windows api as an alternative, it was significantly faster than point, but you have to use it in windowed mode.

Check out:
gdi_point

Enjoy your day.

Login to post a reply

Server time is: 2025-05-17 02:35:28
Your offset time is: 2025-05-17 02:35:28