drawing a line

[marko]

Hi everyone,
I'm an artist and I'm looking for a way to draw a line that will zig-zag
its way thru an image randomly, crisscrossing itself many times, based
on random numbers.

To give you an idea of what I'd like to do, here's a link to a gif :
http://www.chaosmos.net/chaosmoseng/chaosmos7.htm
(it is based on a simple algorithm :
http://www.chaosmos.net/chaosmoseng/chaosmos6.htm)

Is there a way to do that or am I barking up the wrong tree?

As a side note, I don't know anything about C language, I do only have
some knowledge of shell scripting and php.
FWIW I'm a FreeBSD user, so there is no OS issue.
Thanks for your answers

marko

 

[Nick Keighley]

I'm an artist and I'm looking for a way to draw a line that will zig-zag
its way thru an image randomly, crisscrossing itself many times, based
on random numbers.

To give you an idea of what I'd like to do, here's a link to a gif :
http://www.chaosmos.net/chaosmoseng/chaosmos7.htm
(it is based on a simple algorithm :
http://www.chaosmos.net/chaosmoseng/chaosmos6.htm)

Is there a way to do that or am I barking up the wrong tree?

well it's certainly programmable, But standard C, which this ng
discusses,
doesn't provide any graphics primitives. So you would need to pick a
graphics package of some sort, and that's off-topic to this ng. Try
looking
for a graphics ng they may be able to give more help.

As a side note, I don't know anything about C language, I do only have
some knowledge of shell scripting and php.

C may not be your best option then. Python maybe? Probably a similar
learning curve, but lots of goodies in the standard library.

FWIW I'm a FreeBSD user, so there is no OS issue.

why no OS issue? You've eliminated MSs GDI for instance.

 

[Richard Heathfield]

Nick Keighley said:

well it's certainly programmable, But standard C, which this ng
discusses,
doesn't provide any graphics primitives. So you would need to pick a
graphics package of some sort, and that's off-topic to this ng. Try
looking
for a graphics ng they may be able to give more help.

Well, that's not necessarily true. He could write all the necessary code in
standard C. I've done it, so I don't see why he can't, if he's prepared to
spend enough time learning. I should add that I haven't actually
implemented his precise requirements, but I /have/ written code that can
load a bitmap file into into memory, perform various graphical operations
on it, and write it back out to a file, and that would probably be all he
needs - he can use something like Image-Magick to do any necessary file
conversions. Okay, so I rely on having sufficient memory to load the image,
I'll grant you that, but my code works quite happily on Windows and Linux,
and I have no doubts whatsoever that it would also work on a mini, a
mainframe, or a Mac - or indeed anything that has sufficient memory
available to it.

Um, okay, a caveat - I'm not 100% sure it would cope on systems with huge
CHAR_BIT values, at least not without going back and looking closely at it
to check. So it might not work on some ancient mainframes or some modern
DSPs. But, given that caveat, it would probably be considered
comp.lang.c-conforming, so to speak.

<snip>

 

[Ian Malone]

Nick Keighley said:


Well, that's not necessarily true. He could write all the necessary code in
standard C. I've done it, so I don't see why he can't, if he's prepared to
spend enough time learning. I should add that I haven't actually
implemented his precise requirements, but I /have/ written code that can
load a bitmap file into into memory, perform various graphical operations
on it, and write it back out to a file, and that would probably be all he

Of course he may just want to get the job done, in which
case using a library or two might help. Especially if
you want to do things like draw anti-aliased lines and
don't want to have to learn the algorithms.
(The quick hack approach is to write out a raw bitmap
and use a graphics program capable of importing it, but
that quickly gets tiresome)

Um, okay, a caveat - I'm not 100% sure it would cope on systems with huge
CHAR_BIT values, at least not without going back and looking closely at it
to check. So it might not work on some ancient mainframes or some modern
DSPs. But, given that caveat, it would probably be considered
comp.lang.c-conforming, so to speak.

You're talking about reading binary file formats and adjusting
for the fact that your implementation has a bizarre choice
of CHAR_BIT (one not equal to 8...). Is this done by masking
and bit shifts?

 

[Richard Heathfield]

Ian Malone said:

You're talking about reading binary file formats and adjusting
for the fact that your implementation has a bizarre choice
of CHAR_BIT (one not equal to 8...). Is this done by masking
and bit shifts?

Yes, although if you're very very lucky, CHAR_BIT is 24, in which case .bmp
loads and saves actually become simpler!

 

[marko]

Richard Heathfield a écrit :

Well, that's not necessarily true. He could write all the necessary code in
standard C. I've done it, so I don't see why he can't, if he's prepared to
spend enough time learning. I should add that I haven't actually
implemented his precise requirements, but I /have/ written code that can
load a bitmap file into into memory, perform various graphical operations
on it, and write it back out to a file, and that would probably be all he
needs - he can use something like Image-Magick to do any necessary file
conversions. Okay, so I rely on having sufficient memory to load the image,
I'll grant you that, but my code works quite happily on Windows and Linux,
and I have no doubts whatsoever that it would also work on a mini, a
mainframe, or a Mac - or indeed anything that has sufficient memory
available to it.

This is interesting.
Would it be possible to get a copy of your code?
I'd be interested in testing it, and see if I can do anything from there
(as mentioned, I'm really not a c programmer)

m

 

[marko]

Nick Keighley a écrit :

well it's certainly programmable, But standard C, which this ng
discusses,
doesn't provide any graphics primitives. So you would need to pick a
graphics package of some sort, and that's off-topic to this ng. Try
looking
for a graphics ng they may be able to give more help.

ok, thanks for the tip!

 

[SM Ryan]

# Hi everyone,
# I'm an artist and I'm looking for a way to draw a line that will zig-zag
# its way thru an image randomly, crisscrossing itself many times, based
# on random numbers.

# As a side note, I don't know anything about C language, I do only have
# some knowledge of shell scripting and php.

Unless this is an exercise to learn C, I wouldn't use C or
any derivatives because there is so much overhead just getting
started. Other languages like Wish allow you to get graphics
up on your screen more easily.

 

[Arthur J. O'Dwyer]

Richard Heathfield a écrit :

This is interesting.
Would it be possible to get a copy of your code?
I'd be interested in testing it, and see if I can do anything from there (as
mentioned, I'm really not a c programmer)

I dunno about Richard's code (haven't looked for it), but I have what
sounds like a very similar image library at
http://www.contrib.andrew.cmu.edu/~ajo/free-software/ImageFmtc.h
http://www.contrib.andrew.cmu.edu/~ajo/free-software/ImageFmtc.c

(and other files named Image???c.? in that directory do related things).

Also, try searching the newsgroup archives.

HTH,
-Arthur

 

[Richard Heathfield]

marko said:

Would it be possible to get a copy of your code?

I certainly plan to publish it one day, but not just yet.

But really, it doesn't do anything difficult. The BMP file format is - er,
the BMP file formats are - well-known and quite easy to parse, once you
realise something stupidly obvious (i.e. you can decide to deal exclusively
with 24-bit bitmaps, making your life a trillion times easier). And my
"frame buffer" is just a bunch of h pointers to long, each of which points
to w longs. There is nothing here that's hard to do, honest.

 

[Malcolm]

marko said:


I certainly plan to publish it one day, but not just yet.

But really, it doesn't do anything difficult. The BMP file format is - er,
the BMP file formats are - well-known and quite easy to parse, once you
realise something stupidly obvious (i.e. you can decide to deal
exclusively
with 24-bit bitmaps, making your life a trillion times easier). And my
"frame buffer" is just a bunch of h pointers to long, each of which points
to w longs. There is nothing here that's hard to do, honest.

It's OK to write 24-bit bitmaps exclusively in these days of infinite hard
drives. However you still need to read the lot, unless you are in control of
whoever uses the program.
Then there is an evil little twist. Microsoft Visual Studio will only import
bitmaps that are upside down. That's right. MS programming dept can't even
parse their own file format.

 

[Malcolm]

Hi everyone,
I'm an artist and I'm looking for a way to draw a line that will zig-zag
its way thru an image randomly, crisscrossing itself many times, based on
random numbers.

To give you an idea of what I'd like to do, here's a link to a gif :
http://www.chaosmos.net/chaosmoseng/chaosmos7.htm
(it is based on a simple algorithm :
http://www.chaosmos.net/chaosmoseng/chaosmos6.htm)

Is there a way to do that or am I barking up the wrong tree?

As a side note, I don't know anything about C language, I do only have
some knowledge of shell scripting and php.
FWIW I'm a FreeBSD user, so there is no OS issue.
Thanks for your answers

Off-topic but
This looks like a job for BASICdraw.
The program is avialable for free on my website and marries a BASIC
intepreter to image-handling software.
You can save as BMP, by the way, a little bug makes it look as though the
only save format is JPEG.
Version 1.1 with some fixes is nearly due for release, so tell me on any
more bugs or enhancement requests.

 

[Richard Heathfield]

Malcolm said:

[...] The BMP file format is -
er, the BMP file formats are - well-known and quite easy to parse, once
you realise something stupidly obvious (i.e. you can decide to deal
exclusively with 24-bit bitmaps, making your life a trillion times
easier). [...]

It's OK to write 24-bit bitmaps exclusively in these days of infinite hard
drives. However you still need to read the lot, unless you are in control
of whoever uses the program.

Yes, one day I suppose I'll extend my reader to read any bitmap, but for now
it meets my needs, as I am the one who converts the images into bitmap
format in the first place, so I'm careful to use something which knows
(such as the GIMP, or Image-Magick, or - to be fair - almost anything,
nowadays).

Then there is an evil little twist. Microsoft Visual Studio will only
import bitmaps that are upside down. That's right. MS programming dept
can't even parse their own file format.

<shrug> I suppose I could care less, but it's difficult to see how. I am not
attracted to bitmaps because of their (limited) support in Windows, but
because BMP (or at least the subset of it that I choose to acknowledge) is
a nice simple non-lossy file format that's dead easy to read into a frame
buffer for graphical messing about with in ISO C. It's the graphical
messing about in ISO C which interests me, not the peculiarities of
storage. Otherwise I'd be using GIF or JPEG or PNG or something.

 

[Malcolm]

Malcolm said:

[...] The BMP file format is -
er, the BMP file formats are - well-known and quite easy to parse, once
you realise something stupidly obvious (i.e. you can decide to deal
exclusively with 24-bit bitmaps, making your life a trillion times
easier). [...]

It's OK to write 24-bit bitmaps exclusively in these days of infinite
hard
drives. However you still need to read the lot, unless you are in control
of whoever uses the program.

Yes, one day I suppose I'll extend my reader to read any bitmap, but for
now
it meets my needs, as I am the one who converts the images into bitmap
format in the first place, so I'm careful to use something which knows
(such as the GIMP, or Image-Magick, or - to be fair - almost anything,
nowadays).

Then there is an evil little twist. Microsoft Visual Studio will only
import bitmaps that are upside down. That's right. MS programming dept
can't even parse their own file format.

<shrug> I suppose I could care less, but it's difficult to see how. I am
not
attracted to bitmaps because of their (limited) support in Windows, but
because BMP (or at least the subset of it that I choose to acknowledge) is
a nice simple non-lossy file format that's dead easy to read into a frame
buffer for graphical messing about with in ISO C. It's the graphical
messing about in ISO C which interests me, not the peculiarities of
storage. Otherwise I'd be using GIF or JPEG or PNG or something.

I agree.
PCs are also very good for low-end graphical work. BMP is the one format
that virtually every PC tool will support.

 

[marko]

Arthur J. O'Dwyer a écrit :

I dunno about Richard's code (haven't looked for it), but I have what
sounds like a very similar image library at
http://www.contrib.andrew.cmu.edu/~ajo/free-software/ImageFmtc.h
http://www.contrib.andrew.cmu.edu/~ajo/free-software/ImageFmtc.c

(and other files named Image???c.? in that directory do related things).

thanks, I'll take a look at it!

Also, try searching the newsgroup archives.

ditto

m