Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #144934
| Path | csiph.com!goblin3!goblin.stu.neva.ru!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail |
|---|---|
| NNTP-Posting-Date | Sun, 16 Jun 2019 16:36:07 -0500 |
| Message-Id | <aje7tf-602.ln1@aretha.foo> |
| From | Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> |
| Subject | Re: OT: Flood fill algorithm (Graphics) |
| Newsgroups | comp.lang.c |
| Date | Thu, 13 Jun 2019 00:25:14 +1000 |
| References | <5cf9d25b.2656172643@core> |
| User-Agent | KNode/0.10.9 |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=us-ascii |
| Content-Transfer-Encoding | 7Bit |
| Lines | 28 |
| X-Usenet-Provider | http://www.giganews.com |
| X-Trace | sv3-26jpB74ToqPbmsTeIiGdzx4U2FyNk8yPC31D1TMmU9unhveS9XYhDiAMHTtNUMR4306Zk2NIJGXwEIb!LheUJlNcrqXbKdrLDcyOyhxc+pODrA7GLCMQvllsEsT2h+Tb |
| X-Complaints-To | abuse@giganews.com |
| X-DMCA-Notifications | http://www.giganews.com/info/dmca.html |
| X-Abuse-and-DMCA-Info | Please be sure to forward a copy of ALL headers |
| X-Abuse-and-DMCA-Info | Otherwise we will be unable to process your complaint properly |
| X-Postfilter | 1.3.40 |
| X-Original-Bytes | 2128 |
| Xref | csiph.com comp.lang.c:144934 |
Show key headers only | View raw
Groovy hepcat Scott was jivin' in comp.lang.c on Fri, 7 Jun 2019 02:02
pm. It's a cool scene! Dig it.
> I'm messing around with a flood fill function I wrote a long time ago.
>
> Flood fills can be seductively simple, until you find yourself
> cornered with a recursive algorithm that chews through memory like
> crazy. So I wrote mine to be non-recursive and use as little memory as
> possible in the form of a simple queue.
Years ago I wrote a flood fill that was partially recursive. It filled
a line at a time iteratively, first finding the start and end of the
line. But then it visited each pixel in the line checking that the
pixel directly above was the same colour as the area to be filled, and
recursing at the pixel above. Then it did the same for the pixel below.
Or something like that. It's been a while, so the ol' memory may have a
parity error or two.
This algorithm correctly filled anything I threw at it. It was a very
simple single colour fill, though.
--
----- Dig the NEW and IMPROVED news sig!! -----
-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!
Back to comp.lang.c | Previous | Next — Previous in thread | Find similar | Unroll thread
OT: Flood fill algorithm (Graphics) nobody@example.org (Scott) - 2019-06-07 04:02 +0000
Re: OT: Flood fill algorithm (Graphics) fir <profesor.fir@gmail.com> - 2019-06-06 23:54 -0700
Re: OT: Flood fill algorithm (Graphics) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-07 07:57 -0700
Re: OT: Flood fill algorithm (Graphics) nobody@example.org (Scott) - 2019-06-07 16:06 +0000
Re: OT: Flood fill algorithm (Graphics) jadill33@gmail.com - 2019-06-07 09:56 -0700
Re: OT: Flood fill algorithm (Graphics) unidef <jon@unidef-systems.com> - 2019-06-10 02:47 -0500
Re: OT: Flood fill algorithm (Graphics) Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2019-06-13 00:25 +1000
csiph-web