Best way/library to draw individual pixels on screen? (for fractals)
Wolfnoliir
I would like to know what library and method you would recommend for
displaying individual pixels on the screen in the scope of producing
representations of fractals based on complex iteration (e.g. Mandelbrot
or Julia). So it is important that the method be speed efficient.
I would also be interested in knowing (very briefly) how one would go
about making a video player inside a GTK application.
I have some knowledge of SDL and OpenGL already.
Seebs
> Hello,
> I would like to know what library and method you would recommend for
> displaying individual pixels on the screen in the scope of producing
> representations of fractals based on complex iteration
Something suitable to my target platform. The answer would be very different
for the iPhone than it would for a Linux desktop...
Which is to say, this has very little to do with C. Try a group related to
the platform.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Wolfnoliir
> On 2010-03-03, Wolfnoliir <wolfn...@gmail.com> wrote:
>> Hello,
>> I would like to know what library and method you would recommend for
>> displaying individual pixels on the screen in the scope of producing
>> representations of fractals based on complex iteration
>
> Something suitable to my target platform. The answer would be very different
> for the iPhone than it would for a Linux desktop...
>
> Which is to say, this has very little to do with C. Try a group related to
> the platform.
>
> -s
Ian Collins
> Seebs a �crit :
>> On 2010-03-03, Wolfnoliir <wolfn...@gmail.com> wrote:
>>> Hello,
>>> I would like to know what library and method you would recommend for
>>> displaying individual pixels on the screen in the scope of producing
>>> representations of fractals based on complex iteration
>> Something suitable to my target platform. The answer would be very different
>> for the iPhone than it would for a Linux desktop...
>>
>> Which is to say, this has very little to do with C. Try a group related to
>> the platform.
>>
There isn't anything platform independent.
--
Ian Collins
Peter Nilsson
> Wolfnoliir <wolfnol...@gmail.com> wrote:
> > I would like to know what library and method you would
> > recommend for displaying individual pixels on the screen
> > in the scope of producing representations of fractals
> > based on complex iteration
>
> Something suitable to my target platform. The answer would
> be very different for the iPhone than it would for a Linux
> desktop...
I wouldn't recommend it, but as a one off I might run the
following and open the resultant mand.html file on either
platform.
#include <stdio.h>
#include <stdlib.h>
#define T -0.65
#define B -0.75
#define L -0.33
#define R -0.23
#define ROWS 300
#define COLS 300
#define Jre .5
#define Jim -.2
#define MAXITER 1000
#define SZ 1
#define FILENAME "mand.html"
double scale(double a, double b, double c, double v, double w)
{
return v + (a - b) / (c - b) * (w - v);
}
size_t mand(double cre, double cim, size_t max)
{
double re, im;
double nre, nim;
size_t iter;
re = Jre;
im = Jim;
for (iter = 0; iter < max; iter++)
{
nre = re * re - im * im + cre;
nim = 2 * re * im + cim;
re = nre;
im = nim;
if (re * re + im * im >= 4.0) return iter;
}
return iter;
}
int main(void)
{
FILE *fp;
size_t r, c;
fp = fopen(FILENAME, "w");
if (!fp) { puts("ERROR"); return 0; }
fputs("<table border=1><tr><td>\n", fp);
fputs("<table cellpadding=0 cellspacing=0>\n", fp);
for (r = 0; r < ROWS; r++)
{
fputs("<tr>\n", fp);
for (c = 0; c < COLS; c++ )
{
double x = scale(c, 0, COLS - 1, L, R);
double y = scale(r, 0, ROWS - 1, T, B);
size_t i = mand(x, y, MAXITER);
unsigned g = i * 255.0 / MAXITER;
g = 255 - g;
g = g % 16;
g = g * 17;
fprintf(fp, "<td width=\"%d\" height=\"%d\"", SZ, SZ);
fprintf(fp, "bgcolor=\"#%02X%02X%02X\"", g, g, g);
fprintf(fp, "<td></td>\n");
}
fputs("</tr>\n", fp);
}
fputs("</table>\n", fp);
fputs("</td></tr></table>\n", fp);
fclose(fp);
return 0;
}
> Which is to say, this has very little to do with C.
I'm sure this would come as a highly confusing shock to the OP
if they had read your statement elsewhere that Facebook can be
implemented in C.
> Try a group related to the platform.
That, I agree with.
--
Peter
Keith Thompson
> Wolfnoliir wrote:
>> Seebs a écrit :
Well, you could print one character per pixel, but I'm sure that's not
what the OP is looking for.
Or you could write an image file in some specified format (some
formats are binary, others are plain text) and leave the job of
displaying it up to some other platform-specific tool.
But you're right, there is no platform independent way to display
individual pixels on a screen. (Not all platforms even have screens.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Ersek, Laszlo
> Seebs a �crit :
(I wanted to answer this to your original post, but it's just as
relevant now.)
Compute the image in memory and write it out to a ppm file (P6).
http://en.wikipedia.org/wiki/Netpbm_format
The last time I did this was in 2001 or 2002, when I played with
Overhauser splines. It worked great. You can do anything with a ppm
file.
Cheers,
lacos
Wolfnoliir
of having to transfer data into a file before displaying it seems very slow.
I also have the impression that some may have misunderstood me: I am not
talking about putting pixels on the screen directly but in a window
actually. I am sorry that my first message was unclear.
Seebs
> Thanks but I would prefer something platform independent.
Then you are out of luck, because C exists on a broad range of platforms
which don't have "pixels".
Whatever you pick, even if it applies to multiple platforms, you will need
to commit to a set of platforms before you can pick it, and you should
probably pick one of them to start with.
Malcolm McLean
> Hello,
> I would like to know what library and method you would recommend for
> displaying individual pixels on the screen
>
>
Then use openGL to transfer the buffer to screen in a signle call.
Unfortunatetly the openGL documentation site is so sophisticated that
it keeps crashing my browser, so I couldn't look up the call for you.
The technical term is "blit".
Ersek, Laszlo
> I also have the impression that some may have misunderstood me: I am not
> talking about putting pixels on the screen directly but in a window
> actually. I am sorry that my first message was unclear.
I think one of the standard answers is Qt.
Cheers,
lacos
Wolfnoliir
Andrew Poelstra
Qt is a quagmire of inconsistencies, undocumented bugs and missing
functionality. And it forces you to use C++, which has all those
problems on its own.
If the OP doesn't want to save to disk, he should see if he can
save a PPM file to memory - which will be nonportable but likely
pretty simple on each platform that he ports to. (Or impossible,
in which case he can save to disk).
Failing that, perhaps a Gdk pixbuf would be portable enough.
--
Andrew Poelstra
http://www.wpsoftware.net/andrew
Keith Thompson
[...]
> Thanks for the answers. I may look this idea of ppm file up but the idea
> of having to transfer data into a file before displaying it seems very slow.
> I also have the impression that some may have misunderstood me: I am not
> talking about putting pixels on the screen directly but in a window
> actually. I am sorry that my first message was unclear.
Please understand that there simply is no platform-independent way to
display pixels, either on a screen, in a window, on a sheet of paper,
or anywhere else. There are plenty of platform-independent ways to
generate data that can then be interpreted *by some platform-specific
program* as pixel data. Or you can generate textual output, with,
say, '*' representing a pixel that's on and ' ' representing a
pixel that's off.
The C language is designed to be imlementable on a wide variety of
systems, some of which don't have graphic displays.
There are add-on various graphics libraries that provide
a platform-independent interface and a platform-specific
implementation. They can't be portable to *all* possible platforms,
but if you just want to support a few systems, that's your best
bet. If you only care about, say, Windows and Unix-like systems,
a solution should be possible. (I'm not familiar enough with such
libraries to offer specific advice.)
Wolfnoliir
Wolfgang Draxinger
>> This looks like what I am looking for. I'll go look it up. Thank you.
> I found glDrawPixels() which seems to work fine.:)
glDrawPixels is to be considered deprecated, if it's used in conjunction
with rendering other primitives - for just displaying a single image
convering the whole window it's okay, but make sure to use an internal
format, that requires no conversion. Most often this is GL_BGR.
The recommended way to draw pixel images using OpenGL is to first transfer
them into a texture, then render this using a quad. The reasoning behind
this is, that glDrawPixels forces synchronization of the rendering pipeline
thus stalling the rasterizer. Going the way over a pixel buffer object and a
texture allows for asynchronous processing.
Getting texels perfectly screen pixel aligned requires some thinking if
using a "normal" texture. I explained it here http://tinyurl.com/cgndc8
Using a GL_TEXTURE_RECTANGLE instead of GL_TEXTURE_2D it's straightforward.
Wolfgang
bartc
"Wolfnoliir" <wolfn...@gmail.com> wrote in message
news:4b8eddf5$0$9501$426a...@news.free.fr...
> I found glDrawPixels() which seems to work fine.:)
("Wolfgang Draxinger" <wdrax...@darkstargames.de> wrote in message
news:1486165.h...@narfi.yggdrasil.draxit.de...
> glDrawPixels is to be considered deprecated, if it's used in
> conjunction... )
If it's any help at this stage, there is also an OpenGL discussion group
comp.graphics.api.opengl
(Although, OpenGL is more for rendering, I wouldn't use it myself for basic
pixel graphics. (I use my own library which makes use of Win32/GDI, but
then I'm only interested in one platform.))
--
bartc
Squeamizh
wrote:
>
> >> I also have the impression that some may have misunderstood me: I am not
> >> talking about putting pixels on the screen directly but in a window
> >> actually. I am sorry that my first message was unclear.
>
> > I think one of the standard answers is Qt.
>
> >http://qt.nokia.com/
>
> > Cheers,
> > lacos
>
> Qt is a quagmire of inconsistencies, undocumented bugs and missing
> functionality. And it forces you to use C++, which has all those
> problems on its own.
C++ does not have all those problems on its own. I'm not sure why you
would say that.
Branimir Maksimovic
Squeamizh <squ...@hotmail.com> wrote:
> On Mar 3, 6:12 am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
> >
> > Qt is a quagmire of inconsistencies, undocumented bugs and missing
> > functionality. And it forces you to use C++, which has all those
> > problems on its own.
>
> C++ does not have all those problems on its own. I'm not sure why you
> would say that.
It's a flame bait ;)
Greets
Sometimes online sometimes not
Andrew Poelstra
> On Mar 3, 6:12�am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
>> Qt is a quagmire of inconsistencies, undocumented bugs and missing
>> functionality. And it forces you to use C++, which has all those
>> problems on its own.
>
> C++ does not have all those problems on its own. I'm not sure why you
> would say that.
>
It does, though. Perhaps I worded that too strongly (it does
look like a flame bait, even to me, though I assure you this
was not my intent.)
See http://www.yosefk.com/c++fqa
for a critique from somebody quite passionate about this issue.
Wolfnoliir
glDrawPixels() is working well)
I am using GL_RGB format because it seems more natural. Should I try
GL_BGR instead? What difference would it make?
I am also using GL_FLOAT. Would I gain performance by changing it to
GL_UNSIGNED_BYTE?
Peter Nilsson
> Wolfgang Draxinger a écrit :
<snip>
> Thanks. I will look this up when I have time. (for the
> time being glDrawPixels() is working well)
>
> I am using GL_RGB format because it seems more natural.
> Should I try GL_BGR instead? What difference would it
> make? I am also using GL_FLOAT. Would I gain performance
> by changing it to GL_UNSIGNED_BYTE?
Why not ask in a group that deals with open gl? Sure, it
saves you time, but it only increases the off topic noise
in clc and decreases your chance of getting quality peer
reviewed responses.
--
Peter
Wolfgang Draxinger
> I am using GL_RGB format because it seems more natural. Should I try
> GL_BGR instead? What difference would it make?
It might look more intuitive, but believe it or not, most graphics hardware
store pixels BGR order, oftenly padded to 32 bits with zero-bits prior to
the blue bits.
The history behind this is, that pixels are traditionally stored as unsigned
32 bit MSB integers by graphics hardware, where one could e.g. write
0x00ff0000 for blue, 0x0000ff00 for green and 0x000000ff for red. By storing
as such whole pixels could be manipulated by single instructions, instead of
performing the same instruction 3 times for every pixel. Now if you look at
the memory layout of these in MSB format the rest is ovbious.
> I am also using GL_FLOAT. Would I gain performance by changing it to
> GL_UNSIGNED_BYTE?
If using glDrawPixels: Yes. The on screen framebuffer most likely uses an
integer format, so floats require conversion first. Now the way glDrawPixels
works, this conversion must be done by the CPU beforehand. If you go the way
over a floating point texture, then conversion is done by the GPU's
rasterizer pipeline.
Wolfgang
F'up 2 c.g.a.opengl
Robbie Hatley
"Wolfnoliir" asked:
I chose not to do it that way in my fractal graphing programs.
Instead, I researched the "*.bmp" file format, and write images
to "*.bmp" files.
Why do it that way? Several reasons:
1. You don't need any libraries.
2. You don't need any high-level languages.
(The whole thing can be done in C, or even in assembly.)
3. You don't need any GUIs.
(A simple CLI program can graph fractals this way.)
4. Why "*.bmp" format? Because it's the simplest and most
widely used of the "lossless" picture file formats.
5. If you later decide to go from a CLI to a GUI program
for Microsoft Windows, the Win32 API already includes
ability to draw "*.bmp" type bitmaps directly to the screen.
The hard part is figuring out the bmp headers, and creating
appropriate structs. Once you get over that hurdle, the rest
is just writing numbers to a 2d array, which is trivial.
http://picasaweb.google.com/LagrangeL2/Mandelbrot#5417146700980354674
http://picasaweb.google.com/LagrangeL2/Mandelbrot#5417146213849908562
--
Cheers,
Robbie Hatley
lonewolf at well dot com
www dot well dot com slant tilde lonewolf slant
Robbie Hatley
"Andrew Poelstra" wrote:
> "Squeamizh" wrote:
>
> > "Andrew Poelstra" wrote:
> >
> > > Qt is a quagmire of inconsistencies, undocumented bugs and missing
> > > functionality. And it forces you to use C++, which has all those
> > > problems on its own.
> >
> > C++ does not have all those problems on its own. I'm not sure why you
> > would say that.
>
> It does, though. Perhaps I worded that too strongly (it does
> look like a flame bait, even to me, though I assure you this
> was not my intent.)
>
> See http://www.yosefk.com/c++fqa
>
> for a critique from somebody quite passionate about this issue.
Yossi Kreinin is "passionate", all right, but if you read in depth,
You'll see that he doesn't just criticize C++, but says it's
good for nothing, and the wrong choice for EVERY use. He uses
the words "shitty" and "crappy" a lot on his web site in
reference to C++. I get the impression that C++ is just too much
language for him to handle.
This is especially evidenced by the fact that he slams C++ for
presenting so many alternate ways of doing things, especially
for having both C features (such as arrays) and C++ features
(such as std::vector). But I think that's one of the BEST points
of C++, not the worst; it gives the programmer the option of
either doing things "close to the machine" (such as by using
arrays, or malloc/free), or doing things at a higher level of
abstraction (such as with std::vector, or new/delete). For
a programmer who lacks conciousness of abstraction, this
plethora of choices would seem daunting. As it apparently does
to Yossi Kreinin.
Dr Malcolm McLean
<see.my.signat...@for.my.contact.info> wrote:
> This is especially evidenced by the fact that he slams C++ for
> presenting so many alternate ways of doing things, especially
> for having both C features (such as arrays) and C++ features
> (such as std::vector). But I think that's one of the BEST points
> of C++, not the worst; it gives the programmer the option of
> either doing things "close to the machine" (such as by using
> arrays, or malloc/free), or doing things at a higher level of
> abstraction (such as with std::vector, or new/delete).
>
protocol by which components of programs communicate with each other.
If some use plain C-style arrays and some use vectors for essentially
the same job, you've got a similar situation to having three or four
different plugs and sockets. Of course you can mess about with
adapters and usually get things to work, but it's messy and
inefficient.
Andrew Poelstra
>
> "Andrew Poelstra" wrote:
>
>>
>> See http://www.yosefk.com/c++fqa
>>
>> for a critique from somebody quite passionate about this issue.
>
> Yossi Kreinin is "passionate", all right, but if you read in depth,
> You'll see that he doesn't just criticize C++, but says it's
> good for nothing, and the wrong choice for EVERY use. He uses
> the words "shitty" and "crappy" a lot on his web site in
> reference to C++. I get the impression that C++ is just too much
> language for him to handle.
>
This is true. It's unfortunate that he comes off as such a
kook, because he raises some valid points (for example,
the problems with memory management and exceptions, or the
inherent "publicization" of private members.)
> This is especially evidenced by the fact that he slams C++ for
> presenting so many alternate ways of doing things, especially
> for having both C features (such as arrays) and C++ features
> (such as std::vector). But I think that's one of the BEST points
> of C++, not the worst; it gives the programmer the option of
> either doing things "close to the machine" (such as by using
> arrays, or malloc/free), or doing things at a higher level of
> abstraction (such as with std::vector, or new/delete). For
> a programmer who lacks conciousness of abstraction, this
> plethora of choices would seem daunting. As it apparently does
> to Yossi Kreinin.
>
--
Andrew Poelstra
http://www.wpsoftware.net/andrew
Phil Carmody
> "Wolfnoliir" asked:
>
>> I would like to know what library and method you would recommend for
>> displaying individual pixels on the screen in the scope of producing
>> representations of fractals based on complex iteration (e.g. Mandelbrot
>> or Julia). So it is important that the method be speed efficient.
>> I would also be interested in knowing (very briefly) how one would go
>> about making a video player inside a GTK application.
>>
>> I have some knowledge of SDL and OpenGL already.
>
> I chose not to do it that way in my fractal graphing programs.
> Instead, I researched the "*.bmp" file format, and write images
> to "*.bmp" files.
>
> Why do it that way? Several reasons:
> 1. You don't need any libraries.
False
> 2. You don't need any high-level languages.
> (The whole thing can be done in C, or even in assembly.)
Irrelevant
> 3. You don't need any GUIs.
> (A simple CLI program can graph fractals this way.)
Irrelevant
> 4. Why "*.bmp" format? Because it's the simplest and most
> widely used of the "lossless" picture file formats.
False. OK, one of your predicates may be true, but for the
conjunction to be true you need both to be true.
> 5. If you later decide to go from a CLI to a GUI program
> for Microsoft Windows, the Win32 API already includes
> ability to draw "*.bmp" type bitmaps directly to the screen.
Your argument is on drugs.
> The hard part is
So it wasn't the simplest then. Nice of you to shoot your own
prior argument in the foot in the same post.
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
Keith Thompson
> "Robbie Hatley" <see.my.s...@for.my.contact.info> writes:
[...]
>> I chose not to do it that way in my fractal graphing programs.
>> Instead, I researched the "*.bmp" file format, and write images
>> to "*.bmp" files.
>>
>> Why do it that way? Several reasons:
>> 1. You don't need any libraries.
>
> False
Oh? What libraries do you need to generate bmp files?
Or were you callling his statement false, with no further explanation,
because he needs the C standard library?
>> 2. You don't need any high-level languages.
>> (The whole thing can be done in C, or even in assembly.)
>
> Irrelevant
To whom?
>> 3. You don't need any GUIs.
>> (A simple CLI program can graph fractals this way.)
>
> Irrelevant
To whom?
>> 4. Why "*.bmp" format? Because it's the simplest and most
>> widely used of the "lossless" picture file formats.
>
> False. OK, one of your predicates may be true, but for the
> conjunction to be true you need both to be true.
And if you actually wanted to be helpful, you'd explain further.
(I'd probably use ppm myself.)
[snip]
Phil Carmody
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>> "Robbie Hatley" <see.my.s...@for.my.contact.info> writes:
> [...]
>>> I chose not to do it that way in my fractal graphing programs.
>>> Instead, I researched the "*.bmp" file format, and write images
>>> to "*.bmp" files.
>>>
>>> Why do it that way? Several reasons:
>>> 1. You don't need any libraries.
>>
>> False
>
> Oh? What libraries do you need to generate bmp files?
A library which knows about the structure of bmp files. If he doesn't
import a 3rd-party one, he has to write his own. The latter is non-
trivial.
If writing the whole thing yourself was considered 'not needing
any libraries', then 'not needing any libraries' is a completely
weightless predicate.
> Or were you callling his statement false, with no further explanation,
> because he needs the C standard library?
>
>>> 2. You don't need any high-level languages.
>>> (The whole thing can be done in C, or even in assembly.)
>>
>> Irrelevant
>
> To whom?
Everyone. He hadn't stated that as a requirement or even desirable
before investigating it, so the fact that he's found something that
satisfies it is irrelevant.
>>> 3. You don't need any GUIs.
>>> (A simple CLI program can graph fractals this way.)
>>
>> Irrelevant
>
> To whom?
Ditto.
>>> 4. Why "*.bmp" format? Because it's the simplest and most
>>> widely used of the "lossless" picture file formats.
>>
>> False. OK, one of your predicates may be true, but for the
>> conjunction to be true you need both to be true.
>
> And if you actually wanted to be helpful, you'd explain further.
"Do more research. Start at the wikipedia page for image file formats."
> (I'd probably use ppm myself.)
Any of the PNM family, depending on the requirements. For simplicity,
they're hard to beat.
Richard Heathfield
> Keith Thompson <ks...@mib.org> writes:
>> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>>> "Robbie Hatley" <see.my.s...@for.my.contact.info> writes:
>> [...]
>>>> I chose not to do it that way in my fractal graphing programs.
>>>> Instead, I researched the "*.bmp" file format, and write images
>>>> to "*.bmp" files.
>>>>
>>>> Why do it that way? Several reasons:
>>>> 1. You don't need any libraries.
>>> False
>> Oh? What libraries do you need to generate bmp files?
>
> A library which knows about the structure of bmp files.
No, you don't.
> If he doesn't
> import a 3rd-party one, he has to write his own. The latter is non-
> trivial.
Actually, I disagree. It's trivial, especially if you are only
interested in, say, 24-bit ascending-row-order bitmaps.
And, if you're being picky enough to call a handful of helper routines a
"library", I can be picky enough to add that it's only a library if you
build a library out of those helper routines. There's nothing to stop
you putting them in your application source. (Not that you *would* do
that, but it's *possible*.)
So no, you don't need a library for bitmap format support.
> If writing the whole thing yourself was considered 'not needing
> any libraries', then 'not needing any libraries' is a completely
> weightless predicate.
The point is that writing the whole thing yourself is trivial and quick.
It's not like, say, JPEG, where you actually need to either use a
third-party library or do some serious research and a fair bit of
programming.
<snip>
>>>> 4. Why "*.bmp" format? Because it's the simplest and most
>>>> widely used of the "lossless" picture file formats.
>>> False. OK, one of your predicates may be true, but for the
>>> conjunction to be true you need both to be true.
Would you argue with "the most widely used, and one of the simplest,
"lossless" picture file formats"?
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Phil Carmody
> Phil Carmody wrote:
>> Keith Thompson <ks...@mib.org> writes:
>>> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>>>> "Robbie Hatley" <see.my.s...@for.my.contact.info> writes:
>>> [...]
>>>>> I chose not to do it that way in my fractal graphing programs.
>>>>> Instead, I researched the "*.bmp" file format, and write images
>>>>> to "*.bmp" files.
>>>>>
>>>>> Why do it that way? Several reasons:
>>>>> 1. You don't need any libraries.
>>>> False
>>> Oh? What libraries do you need to generate bmp files?
>>
>> A library which knows about the structure of bmp files.
>
> No, you don't.
>
>> If he doesn't import a 3rd-party one, he has to write his own. The
>> latter is non-
>> trivial.
>
> Actually, I disagree. It's trivial, especially if you are only
> interested in, say, 24-bit ascending-row-order bitmaps.
Quite possibly. I have a feeling that when the w2k source was leaked
that it was in the 24-bit bitmap handling that I found a buffer
over-run within 20 minutes of opening the zip, though. (OK, on the
reading side, not the writing side.)
> And, if you're being picky enough to call a handful of helper routines
> a "library", I can be picky enough to add that it's only a library if
> you build a library out of those helper routines. There's nothing to
> stop you putting them in your application source. (Not that you
> *would* do that, but it's *possible*.)
>
> So no, you don't need a library for bitmap format support.
But you don't need a library for anything, as anything that
can be written in a library you can write yourself, given
sufficient time and effort.
>> If writing the whole thing yourself was considered 'not needing any
>> libraries', then 'not needing any libraries' is a completely
>> weightless predicate.
>
> The point is that writing the whole thing yourself is trivial and
> quick. It's not like, say, JPEG, where you actually need to either use
> a third-party library or do some serious research and a fair bit of
> programming.
They are still shades of grey on a continuum.
>>>>> 4. Why "*.bmp" format? Because it's the simplest and most
>>>>> widely used of the "lossless" picture file formats.
>>>> False. OK, one of your predicates may be true, but for the
>>>> conjunction to be true you need both to be true.
>
> Would you argue with "the most widely used, and one of the simplest,
> "lossless" picture file formats"?
Yes. I would argue with that in the sense that I would use it as
my argument with which to argue against others.
I guess I've dealt with half a dozen lossless formats that are
at least as simple as BMP, but none could compare on how widely
they're used.
Dr Malcolm McLean
wrote:
>
> I guess I've dealt with half a dozen lossless formats that are
> at least as simple as BMP, but none could compare on how widely
> they're used.
>
images are units of 8 pixels wide, these often grab ypu unexpectedly.
The second one is that all the documentation assumes you will be
running the code on a Windows machine. In fact it is not possible to
portably define the headers in terms of structures. However it's easy
eanought o write a fucntionto read a little-endian integer from the
file.
The third one is the BGR, upside down raster format. It's just a
little bit of tinkering, but it's a nuisance, and it tempts you to
give your loader a cluntzy interface.
bartc
"Dr Malcolm McLean" <malcolm...@btinternet.com> wrote in message
news:9926b6c9-0d1d-437f...@q15g2000yqj.googlegroups.com...
> On 14 Mar, 21:05, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> wrote:
>>
>> I guess I've dealt with half a dozen lossless formats that are
>> at least as simple as BMP, but none could compare on how widely
>> they're used.
>>
> Three problems with BMP. Firstly the line-padding rules. Since most
> images are units of 8 pixels wide, these often grab ypu unexpectedly.
> The second one is that all the documentation assumes you will be
> running the code on a Windows machine. In fact it is not possible to
> portably define the headers in terms of structures. However it's easy
> eanought o write a fucntionto read a little-endian integer from the
> file.
Yes, the header is some 54 bytes I think, while scanlines are a multiple of
4 bytes. That means the entire image data, and any palette, are at an odd
2-byte alignment in the file, and in memory if you just load the whole thing
as one block.
(BMP was also used at one time for combining multiple icons in a single BMP
image. Each scanline row is padded to a 4n bytes, so the natural way to do
this is to combine these vertically.
So that if the icon is, say, 20x20 1-bit pixels, the 3rd icon starts at row
41 in the composite file. But it was decided to pack these horizontally
instead. Now the start of any row in the 3rd icon, starts at some bit offset
in the middle of the 2nd dword! Who designs this stuff?)
> The third one is the BGR, upside down raster format. It's just a
> little bit of tinkering, but it's a nuisance, and it tempts you to
> give your loader a cluntzy interface.
I think the palette uses RGB, and the image data might use BGR. Or is it the
other way. (Palettes and 24-bit image data do not co-exist, doesn't help
though).
But on the whole, compared with some file formats, BMP is fairly
straightforward.
--
Bartc
Sjouke Burry
> Hello,
> I would like to know what library and method you would recommend for
> displaying individual pixels on the screen in the scope of producing
> representations of fractals based on complex iteration (e.g. Mandelbrot
> or Julia). So it is important that the method be speed efficient.
> I would also be interested in knowing (very briefly) how one would go
> about making a video player inside a GTK application.
>
> I have some knowledge of SDL and OpenGL already.
structure is implemented.
It shows 2/4/4rle/8/8rle/and 24 bit rgb decoding and the diffs
between OS2 and M$ .
If you want the sourcecode, ask here or try to de-louse
my email adress.
Richard Heathfield
> On 14 Mar, 21:05, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> wrote:
>> I guess I've dealt with half a dozen lossless formats that are
>> at least as simple as BMP, but none could compare on how widely
>> they're used.
>>
> Three problems with BMP. Firstly the line-padding rules. Since most
> images are units of 8 pixels wide, these often grab ypu unexpectedly.
But forewarned is forearmed, and the rules are in the spec.
> The second one is that all the documentation assumes you will be
> running the code on a Windows machine. In fact it is not possible to
> portably define the headers in terms of structures.
Actually, it is. The non-portability comes not from structure defs, but
from unwarranted assumptions about alignment and endianness...
> However it's easy
> eanought o write a fucntionto read a little-endian integer from the
> file.
Right.
> The third one is the BGR, upside down raster format. It's just a
> little bit of tinkering, but it's a nuisance, and it tempts you to
> give your loader a cluntzy interface.
<shrug> I'm not quite sure what you mean by "cluntzy interface", but I'm
happy with mine. :-)
Dr Malcolm McLean
> Dr Malcolm McLean wrote:
>
> > The second one is that all the documentation assumes you will be
> > running the code on a Windows machine. In fact it is not possible to
> > portably define the headers in terms of structures.
>
> Actually, it is. The non-portability comes not from structure defs, but
> from unwarranted assumptions about alignment and endianness...
>
can't actually find any of the official Microsoft docs on the web,
though there is no shortage of unofficial BMP format specs.
Richard Bos
> Keith Thompson <ks...@mib.org> writes:
> > Phil Carmody <thefatphi...@yahoo.co.uk> writes:
> >> "Robbie Hatley" <see.my.s...@for.my.contact.info> writes:
> >>> 1. You don't need any libraries.
> >>
> >> False
> >
> > Oh? What libraries do you need to generate bmp files?
>
> A library which knows about the structure of bmp files. If he doesn't
> import a 3rd-party one, he has to write his own. The latter is non-
> trivial.
Nonsense. _Reading_ everyone else's widely varying BMP files, that's
non-trivial. Choosing one format for yourself to use and writing BMP
files in that format only, that's a very simple job.
Richard
Robbie Hatley
"Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in this
group, in response to my message about the ways in which I chose
to graph fractals with C programs writing images to bmp files:
> ... False ...
> ... Irrelevant ...
> ... Irrelevant ...
> ... False ...
No, Phil, there was nothing "false" or "irrelevant" in the post
you were pretending to be replying to.
> I find the easiest thing to do is to k/f myself and just troll away
No. But the easiest thing for *ME* (and others here) to do,
is, indeed, to killfile you. Life is short, and there's no time
for fussing and fighting with enfant provocateurs.
::: killfiles "Phil Carmody" ( thefatphi...@yahoo.co.uk ) :::
Done.
I suggest everyone here do likewise.
Robbie Hatley
"Richard Heathfield" wrote:
> Actually, I disagree. It's trivial, especially if you are only
> interested in, say, 24-bit ascending-row-order bitmaps.
Yes.
However, I also wrote run-length-encoding ("RLE")
compression routines, just for the challenge of it.
Some of the trickiest C code I ever wrote, primarily
because it needs a state machine, and I hadn't even
*heard of* a "state machine" yet when I wrote it.
So I thought of my routine as being a "status tracker",
for want of a better term. (Later, a co-worker informed
me that this kind of contraption is more properly called
a "finite state machine" in comp-sci lingo.)
Basically (for those who haven't done this kind of
programming in C) a "finite state machine" is a function
that processes an incoming data stream, with the things
to be done by the data determined by the "state" of
the function, and the "state" of the function being
determined by the data. Parsing things, reading data
off of serial comm ports, compressing video pixels, etc,
are things often done by state machines.
Keeping track of "state" is often done by enum:
/* Create a set of "states" for a finite state machine to control
the RLE process: */
enum
{
begin, /* begin segment with unknown pixel values */
ruf_ext, /* extend segment with variable ("rough") pixel values */
ruf_end, /* end segment with variable ("rough") pixel values */
run_ext, /* extend segment with invariant ("run") pixel values */
run_end /* end segment with invariant ("run") pixel values */
} SegmentState;
The general procedure is a loop like so:
do
{
Input next data.
Decide what to do with data based on state.
Decide what to do with state based on data.
} while (not yet at end of data)
> The point is that writing the whole thing yourself is trivial and quick.
> It's not like, say, JPEG, where you actually need to either use a
> third-party library or do some serious research and a fair bit of
> programming.
Yep, I looked into JPEG, but when I found out that I'd have to first
learn the mathematics of Fourier Transforms, and then code them in C,
I gave it up. Fractals tend to lose a lot with lossy file formats,
anway.
Robbie Hatley
"Dr Malcolm McLean" wrote of C++ (as compared to C):
> The problem is that basic structure, like arrays / vectors,
> act as a protocol by which components of programs communicate
> with each other. If some use plain C-style arrays and some
> use vectors for essentially the same job, you've got a similar
> situation to having three or four different plugs and sockets.
> Of course you can mess about with adapters and usually get
> things to work, but it's messy and inefficient
Well, yah. C++ is messy and inefficient. C is less messy,
but also less efficient in some ways (such as effort required
to set up data structures such as multimap of struct objects),
and also more efficient in other ways (the executables are
noticably smaller and faster than the same program written
in C++). But I like and use both languages, along with others.
Ian Collins
>
> Well, yah. C++ is messy and inefficient. C is less messy,
> but also less efficient in some ways (such as effort required
> to set up data structures such as multimap of struct objects),
> and also more efficient in other ways (the executables are
> noticably smaller and faster than the same program written
> in C++).
While not wanting to get into a religious war, that is complete nonsense.
> But I like and use both languages, along with others.
Good, use the best tool for the job.
--
Ian Collins
jacob navia
> "Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in this
> group, in response to my message about the ways in which I chose
> to graph fractals with C programs writing images to bmp files:
>
>> ... False ...
>> ... Irrelevant ...
>> ... Irrelevant ...
>> ... False ...
>
> No, Phil, there was nothing "false" or "irrelevant" in the post
> you were pretending to be replying to.
>
>> I find the easiest thing to do is to k/f myself and just troll away
>
> No. But the easiest thing for *ME* (and others here) to do,
> is, indeed, to killfile you. Life is short, and there's no time
> for fussing and fighting with enfant provocateurs.
>
> ::: killfiles "Phil Carmody" ( thefatphi...@yahoo.co.uk ) :::
>
> Done.
>
> I suggest everyone here do likewise.
>
I just don't read what carmody writes, and that is much easier. Why bother?
Branimir Maksimovic
jacob navia <ja...@nospam.org> wrote:
> Robbie Hatley a écrit :
> > ::: killfiles "Phil Carmody" ( thefatphi...@yahoo.co.uk ) :::
> >
> > Done.
> >
> > I suggest everyone here do likewise.
> >
> Look, I have never "killfiled" anyone.
Me too. I don't use anything with word "kill" in it ;)
>
> I just don't read what carmody writes, and that is much easier. Why
> bother?
Exactly! you don;t have to read.
Greets!
Branimir Maksimovic
"Robbie Hatley" <see.my.s...@for.my.contact.info> wrote:
>
> "Dr Malcolm McLean" wrote of C++ (as compared to C):
>
> > The problem is that basic structure, like arrays / vectors,
> > act as a protocol by which components of programs communicate
> > with each other. If some use plain C-style arrays and some
> > use vectors for essentially the same job, you've got a similar
> > situation to having three or four different plugs and sockets.
> > Of course you can mess about with adapters and usually get
> > things to work, but it's messy and inefficient
>
> Well, yah. C++ is messy and inefficient. C is less messy,
> but also less efficient in some ways (such as effort required
> to set up data structures such as multimap of struct objects),
Hm, assembler is less messy then C , but also less efficient
then C in some ways(such as effort....)
> and also more efficient in other ways (the executables are
> noticably smaller and faster than the same program written
> in C++).
and also more efficient, such as executables are noticeably smaller
and faster the same program written in C.
also not that easily disassembled, but more difficult
to debug ;)
But I like and use both languages, along with others.
>
same. ;)
Default User
> On Fri, 19 Mar 2010 23:13:51 +0100
> jacob navia <ja...@nospam.org> wrote:
> > I just don't read what carmody writes, and that is much easier. Why
> > bother?
>
> Exactly! you don;t have to read.
If you never plan to read the posts of a certain person, why not
killfile them?
Brian
Branimir Maksimovic
"Default User" <defaul...@yahoo.com> wrote:
I don;t see reason in filterng messages, except that
messages are pure spam and there is no purpose replaying
to them since spamers don;t read other posts anyway
and are not interested in conversation.
So normal posts I read alright ;)
Greets
>
>
>
> Brian
Seebs
> On 20 Mar 2010 05:45:18 GMT
> "Default User" <defaul...@yahoo.com> wrote:
>> If you never plan to read the posts of a certain person, why not
>> killfile them?
> I don;t see reason in filterng messages, except that
> messages are pure spam and there is no purpose replaying
How about "they annoy me and waste my time"? That's why I usually
killfile people.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Lorenzo Villari
Seebs <usenet...@seebs.net> wrote:
> On 2010-03-20, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > On 20 Mar 2010 05:45:18 GMT
> > "Default User" <defaul...@yahoo.com> wrote:
> >> If you never plan to read the posts of a certain person, why not
> >> killfile them?
>
> > I don;t see reason in filterng messages, except that
> > messages are pure spam and there is no purpose replaying
>
> How about "they annoy me and waste my time"? That's why I usually
> killfile people.
>
In rare occasions even some annoying people post interesting things
(to a certain degree), that's why I never killfile people...
Dr Malcolm McLean
overwhelming.
Ian Collins
What do you mean by "Introduce another language"?
If I have to write a web application, I use PHP and JavaScript. Should
I use C?
If I have to automate a system administration task, I use bash or ksh.
Should I use C?
There's always an appropriate tool for a job.
--
Ian Collins
Seebs
If I read enough conspiracy-theorist web sites, I'll eventually encounter
a fact. This doesn't mean it's a good use of my time.
If I had infinite time, I would not use a killfile.
Kenny McCormack
Whether you killfile or not is irrelevant. That is between you and your
maker/conscience. What matters is whether or not you talk about it in public.
As I've noted earlier, talking about your killfile in public is that
which marks one clearly as a dweeb.
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...
Default User
> On 2010-03-20, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > On 20 Mar 2010 05:45:18 GMT
> > "Default User" <defaul...@yahoo.com> wrote:
> >> If you never plan to read the posts of a certain person, why not
> >> killfile them?
>
> > I don;t see reason in filterng messages, except that
> > messages are pure spam and there is no purpose replaying
>
> How about "they annoy me and waste my time"? That's why I usually
> killfile people.
That's pretty much the way it is with me. My "usenet time" is much
reduced these days. I prefer to set the newsreader to show only new
messages and cruise though as quickly as possible. I don't want to read
messages that are likely a waste of time, and I certainly don't want to
study the sender before deciding whether to open the message.
Brian
Default User
> In rare occasions even some annoying people post interesting things
> (to a certain degree), that's why I never killfile people...
But if they do, then there will likely be a response from a "quality"
contributor, and I'll read the message in quotes.
Brian
Richard Heathfield
> On 16 Mar, 00:27, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Dr Malcolm McLean wrote:
>>
>>> The second one is that all the documentation assumes you will be
>>> running the code on a Windows machine. In fact it is not possible to
>>> portably define the headers in terms of structures.
>> Actually, it is. The non-portability comes not from structure defs, but
>> from unwarranted assumptions about alignment and endianness...
>>
> They used to document the format in terms of C-language structures.
How does that support your point?
<snip>
Dr Malcolm McLean
> Dr Malcolm McLean wrote:
> > On 16 Mar, 00:27, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> Dr Malcolm McLean wrote:
>
> >>> The second one is that all the documentation assumes you will be
> >>> running the code on a Windows machine. In fact it is not possible to
> >>> portably define the headers in terms of structures.
> >> Actually, it is. The non-portability comes not from structure defs, but
> >> from unwarranted assumptions about alignment and endianness...
>
> > They used to document the format in terms of C-language structures.
>
> How does that support your point?
>
fread(&mystruct, 1, sizeof(MYSTRUCT), fp) will always produce the same
results, even if the members of mystruct are of the right size.
Then structure defs inherently contain endianness, whilst the compiler
may insert any padding it chooses. (This is always done for the
purposes of alignment, but many processors allow unaligned slow reads,
so the choice is made by the compiler designer).
Richard Heathfield
> On 21 Mar, 08:04, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Dr Malcolm McLean wrote:
>>> On 16 Mar, 00:27, Richard Heathfield <r...@see.sig.invalid> wrote:
>>>> Dr Malcolm McLean wrote:
>>>>> The second one is that all the documentation assumes you will be
>>>>> running the code on a Windows machine. In fact it is not possible to
>>>>> portably define the headers in terms of structures.
>>>> Actually, it is. The non-portability comes not from structure defs, but
>>>> from unwarranted assumptions about alignment and endianness...
>>> They used to document the format in terms of C-language structures.
>> How does that support your point?
>>
> structs can contain padding.
Yes, but that's only relevant if you insist on freading the data into
those structures (and/or fwriting it out again). It is not unreasonable
to use structure syntax to "map out" a file format; it /is/ unreasonable
to ignore padding (which I admittedly forgot to mention), alignment, and
endianness when reading from or writing to such files.
Phil Carmody
> "Phil Carmody" <thefatphi...@yahoo.co.uk> wrote
>> I find the easiest thing to do is to k/f myself and just troll away
That is an inaccurate attribution, as you have not propagated
the fact that I was quoting someone else.
Not interacting with idiots is one thing I strive for. Thanks
for preventing such interaction at your end.
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1