1. Win32Lib: Flood Fill Demo

------=_NextPart_000_0011_01C02BD9.F0BEAF20
        charset="iso-8859-1"

For what it's worth, here is the floodFill demo I sent to Gene (with an
enhanced demo program).  The only tweak to Win32Lib required is described in
floodfill.ew (namely, you must make 'createBrush' a global routine).

Should be easy to add to Win32Lib (if there is even a demand for this
routine).  The only thing I can't figure out about it is that it leaves a
dithered remnant of the original color.

If anybody can figure out why, I'd love to hear about it.

Thanks,
  Brian

------=_NextPart_000_0011_01C02BD9.F0BEAF20
        name="floodfill.zip"

new topic     » topic index » view message » categorize

2. Re: Win32Lib: Flood Fill Demo

Hi Brian,

----- Original Message -----
From: "Brian Broker" <bkb at CNW.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, October 02, 2000 1:15 PM
Subject: Re: Win32Lib: Flood Fill Demo

<snip>
>  the Win32Lib constant definitions for Red, Green, and
> Blue are off by one and should use a value of 128 instead of 127... (and
> other color constants should be tweaked accordingly).

Why do you think that 128 should be used instead of 127?

You may very well be correct. I can't find any definitive documentation on
this. The red scale has 256 different shades (0 - 255), so halfway is 127.5,
which means that we have to pick an integer near that. So why 128 and not
127? Aren't they equally as good as each other?

It seems that Microsoft defines RED as (255,0,0).


-----
cheers,
Derek

new topic     » goto parent     » topic index » view message » categorize

3. Re: Win32Lib: Flood Fill Demo

Brian,

Your demo looks real nice!  Is there any way to programmatically set for 32
bit color, so the demo/method would work without the user having to do so to
get rid of the dithering?  If so, and if the change of "createBrush" to
global doesn't make any problems, then this would seem to be a nice add to
Win32Lib

Dan

----- Original Message -----
From: "Brian Broker" <bkb at CNW.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, October 01, 2000 7:15 PM
Subject: Re: Win32Lib: Flood Fill Demo


> On Sun, 1 Oct 2000 19:01:01 -0700, I wrote:
>
> >The only thing I can't figure out about it is that it leaves a
> >dithered remnant of the original color.
> >
> >If anybody can figure out why, I'd love to hear about it.
>
> I'll save you the trouble on this one.  It turns out that windows does
some
> dithering when you have your system set to 16-bit color.  I had to crank
it
> up to 32-bit to get my demo working properly.  But this brings up an
> interesting issue:  the Win32Lib constant definitions for Red, Green, and
> Blue are off by one and should use a value of 128 instead of 127... (and
> other color constants should be tweaked accordingly).
>
> -- Brian

new topic     » goto parent     » topic index » view message » categorize

4. Re: Win32Lib: Flood Fill Demo

On Mon, 2 Oct 2000 21:20:43 +1100, Derek Parnell wrote:

>Hi Brian,
>
>----- Original Message -----
>From: "Brian Broker" <bkb at CNW.COM>
>To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
>Sent: Monday, October 02, 2000 1:15 PM
>Subject: Re: Win32Lib: Flood Fill Demo
>
><snip>
>>  the Win32Lib constant definitions for Red, Green, and
>> Blue are off by one and should use a value of 128 instead of 127... (and
>> other color constants should be tweaked accordingly).
>
>Why do you think that 128 should be used instead of 127?
>
>You may very well be correct. I can't find any definitive documentation on
>this. The red scale has 256 different shades (0 - 255), so halfway is
127.5,
>which means that we have to pick an integer near that. So why 128 and not
>127? Aren't they equally as good as each other?

Because, if I run my flood fill demo in 16-bit color, I get dithered
remnants of the previous color, meaning that (127,0,0), (0,127,0), etc. are
not 'pure' colors.  If they were defined with 128 instead of 127, there
would be no dithering in 16-bit color (they would be pure colors) and my
demo would work 'properly' (i.e. there would be no dithered remnants left
over).  Follow?

>It seems that Microsoft defines RED as (255,0,0).

David decided to differentiate between bright red and plain red, which is
fine by me [ BrightRed = (255,0,0) ]

-- Brian

new topic     » goto parent     » topic index » view message » categorize

5. Re: Win32Lib: Flood Fill Demo

On Mon, 2 Oct 2000 06:12:04 -0700, Dan B Moyer wrote:

>Brian,
>
>Your demo looks real nice!

thank you

>Is there any way to programmatically set for 32
>bit color, so the demo/method would work without the user having to do so
>to get rid of the dithering?

Yes, I seem to recall a routine for being able to do this but I'd have to
look into it in more depth.  (of course, the user's graphics adapter and
display must actually support a higher color depth for it to work).

>If so, and if the change of "createBrush" to
>global doesn't make any problems, then this would seem to be a nice add to
>Win32Lib
>
>Dan

if the floodFill routine was added to Win32Lib, then there would be no need
to declare 'createBrush' as global (unless you are talking about having the
routine be just a separate add-on...)

-- Brian

new topic     » goto parent     » topic index » view message » categorize

6. Re: Win32Lib: Flood Fill Demo

> interesting issue:  the Win32Lib constant definitions for Red, Green, and
> Blue are off by one and should use a value of 128 instead of 127... (and
> other color constants should be tweaked accordingly).
> -- Brian
... seems so, just open a color picker dialog, open the custom color box,
then double-click on any 'solid' on the left.
... all values shown are 0, 32, 64, 128, 192, or 255 ...
on my humble 256 color screen, Wolf.

new topic     » goto parent     » topic index » view message » categorize

7. Re: Win32Lib: Flood Fill Demo

Brian,

Nope, wasn't suggesting FloodFill be separate, just didn't have my thinking
cap on straight & forgot that if it were added IN Win32Lib, then createBrush
wouldn't have to be changed to global!

Dan

I wrote:
<snip>
>
> >If so, and if the change of "createBrush" to
> >global doesn't make any problems, then this would seem to be a nice add
to
> >Win32Lib
> >
> >Dan

And Brian responded:
>
> if the floodFill routine was added to Win32Lib, then there would be no
need
> to declare 'createBrush' as global (unless you are talking about having
the
> routine be just a separate add-on...)
>
> -- Brian

new topic     » goto parent     » topic index » view message » categorize

8. Re: Win32Lib: Flood Fill Demo

Hi

 Brian graciously let me use his flood fill

and it is just what I needed.
Instead of intering the color constant for say "RED"
I found I could do one of two things.

 either make my own constant for 256 instead of 255

 The other way is to insert command rgb() into floodfill
and get any color I want providing the numbers were evenly divisable
by 8 such as:  rgb(64, 96, 168).

I dont know why it works but I figured it out by the comments you
all made.

 Thank you all,

   gene

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu