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] Flood Fill using Memblock

Author
Message
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 28th Jan 2009 06:16 Edited at: 30th Jan 2009 16:39
I spent quite some time learning how to get a Floodfill in DBC. Still cant get it quite as fast as I'd like, I'm causing too many recrusions.



Here's a slow verion if anyone's curious. It show what's going on and what checks are being made. You'll notice at the bottom there will be 3 colors being draw out as the object gets filled.

Green = Checked 1 time and Draw dot.
Red = Recrusive Check Upward.
Blue = Recrusive Check Downward.

Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 31st Jan 2009 01:01 Edited at: 31st Jan 2009 01:18
I've optimized this to the best of my abilities and the speed has greatly improved. I tested this same code in DBPro and it works but only in the 32bit mode and it runs a bit slower. The default text size are different too .

How do we get the equivelant of "color = r|g|b" in DBPro as this line doesn't seem to work?



The slow testing version has also been greatly improved.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 31st Jan 2009 01:57 Edited at: 31st Jan 2009 02:15
I think bitwise OR is || in DBPro :

r||g||b

I see you made good use of the 16 bit conversion algorithm I showed you. You may want to include a test for different conversion types, 565, 555... but in most cases it will be 565.

Enjoy your day.
Quadrazar
15
Years of Service
User Offline
Joined: 7th Jan 2009
Location: onboard the Kobayashi Maru
Posted: 31st Jan 2009 02:58
The 32bits version is probably running slower because it has to write twice as much data compared to the 16 bit version. For a sqaure this would result in (16bitWriteTime ^ 2) = 32bitWriteTime.
If your 32bit version stays whitin this limit the computing time of the 32Bit is probably faster.

Quote: "How do we get the equivelant of "color = r|g|b" in DBPro as this line doesn't seem to work?"

color = r+g+b
since there r,g and b have no 'overlapping' bits.

make shure r g and b are Integer values. otherwise you'll get strange results.

if you calculate
63488 / 255 = 248,97254901960784313725490196078 (float)
63488 / 256 = 248 (int)

for the others you'll have to use a round function I think

I'm not shure if the conversion is right.
It could be that I'm wrong (can't test it so...)
32blue has 8 bits
16blue has 5 bits
b = rgbb(FillColor) / 8 * 5 ( 8/5 = 1.25)
b has to be an Int and is probably a the float.
b = floor ( rgbb(FillColor)*1.25)

32green has 8 bits
16green has 5 (or 6 bits according to the hue thread)
g = rgbg(FillColor) / 8 * 5 * 16
g = floor(rgbg(FillColor) / 1.25) * 16 (Five bits version)
g = floor(rgbg(FillColor) / 1.5 ) * 16 (Six bits vesion)

and for red
r = floor( rgbr(FillColor) / 1.25) * 256 (Five bits version)
r = floor( rgbr(FillColor) / 1.25) * 512 (Six bits vesion)

I don't know if basic has floor or round commands. It sould round a integer to and int.

Amiga 500 - 68000 processor / 7 Mhz, 512 Kb RAM, 4-channel PCM synthesizer (stereo)
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 31st Jan 2009 05:59 Edited at: 31st Jan 2009 06:10
The bitwise OR || and Quadrazar's example are both not returning a correct value. 16bit mode is just not working at all for me while using memblock, not just the color, everything memblock related is just wrong.

I also notice that making a memblock from bitmap (Screen) DBP is faster than DBC but when making memblock from bitmap (Memory), DBC is MUCH faster!

I made 2 different versions of this in DBP, one using the Lock Pixels, Dot and Point, the other using Memblock.

Somthing's very funny with the two versions.

1) The Lock Pixel version would be blazing fast giving a return speed of 15 after filling a small object. Then when filling the screen it's slow, returning at about 500.

2) The Memblock will return at about 280~290 while filling the screen, but stays consistant while filling everything else even the smallest object.

I've also tried using get image and making memblock from image instead but do difference.


DBP Memblock version.


DBP Lock Pixel version
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 31st Jan 2009 08:32
Could be a couple of different things. Does DBPro run in a window by default? If so, the bitmaps will most likely take on the bit depth of your desktop (which is probably 32 bit) no matter what you set display mode at. Also check the memblock data itself. 16 bit color may actually be split into 3 bytes already inside the memblock if you are running in fullscreen mode. 16 bit may also be rgb1555 meaning there's a bit reserved for an alpha channel in DBPro.

Quote: "color = r+g+b
since there r,g and b have no 'overlapping' bits."

I was under the impression that a bitwise OR operation would be faster than an addition because it eliminates the check for a carry. And since we don't need a carry...

Enjoy your day.
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 31st Jan 2009 15:35 Edited at: 31st Jan 2009 16:09
DBP has a separate .exe display setting aside from the set display statement and the default usually is windowed fullscreen.



I had the bit dept checking the memblock data as you suggested and it works! Aparently the screen depth() function isn't really reliable .

My desktop setting is in 32bit and it seems the only time DBP will actually be in actual 16bit mode is in exclusive mode with both display settings, the statement and .exe settings are set to 16bit. Or just not use the statement at all and only the .exe sittings.


I'm still having some issues with the 16bit mode. After filling a circle, then I fill a triangle, I notice that the previous circle is refilled with a different color. I'm not sure what's causing this lol.


[edit]


This is confusing I skipped the whole process of filling and only:

1) Made the memblock from bitmap
2) Convert the color into 2 bytes
3) Plot one pixel
4) Make image from memblock and paste

I'm still getting the previous color changing every time I click the mouse.

Attachments

Login to view attachments
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 31st Jan 2009 17:41
I updated my DBP Lock Pixels version, it's now using pitch and pointer instead of point and dot but there's still no improvements.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Jan 2009 19:06
Works very well. Does it need to be any faster?

One tiny criticism - I needed to change:



to



Without that change I couldn't accurately click the small features such as the centres of the letter "o"s, the dot on the "i", or the outlines of the boxes.
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 31st Jan 2009 19:28 Edited at: 31st Jan 2009 19:29
Thanks.

Quote: "Does it need to be any faster?"

Yes it does! Well I'm just trying to optimize it to the max, looking at the sheer speed the paint program can perform I'm sure these versions can be a bit faster than it is right now.

In DBC the -1 will make the mouseXY accurate, but you are right DBP don't need it.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Apr 2009 01:00
@Ashingda 27

I was messing around with your flood fill and came up with a couple of optimizations. Though small, they do squeeze out a little more speed. In the main fill loop, if you do the bit depth check outside of the for next loops (if FloodBytes(0)=2), it keeps the conditional from being checked every iteration. That reduces the command calls to DBC.

For some reason though, changing the Left and Right loops produces a fairly consistant speed increase. Changing All - Left Right Up and Down, produces an inconsistant speed boost. However, when it's at it's fastest, it's when all 4 direction loops have the conditional outside of the loop.

On my machine, your original code, filled the entire screen at about 410ms . The 4 loop conditional change can fill at about 310ms. The 2 loop conditional change can fill at about 326ms.
I'm sure there are other optimizations that could be done (figure out a way to eliminate the recursion). Here's both optimized versions:

left right


left right up down


Also, I get an Array Accessed out of Bounds error if I move the mouse to the upper right corner and click.

Enjoy your day.

Login to post a reply

Server time is: 2024-05-04 23:53:19
Your offset time is: 2024-05-04 23:53:19