Been reading posts for months, and haven't seen this
come up yet, but I'm sure someone has done this already.
I want to input a series of  image_mapped  jpg/gif/etc within
a scene - say 30 frames - to play on render plasma screen
(similar to DESK.pov sample) as camera pans past.  I don't
have the luxury of time like I used to, to figure these out.  POV
user for at least 6 years though. (not a newbie)  Thanks for input.

Post a reply to this message

"dbwr" <dbw### [at] netzeronet> wrote in message news:40134384@news.povray.org...
> Been reading posts for months, and haven't seen this
> come up yet, but I'm sure someone has done this already.
> I want to input a series of  image_mapped  jpg/gif/etc within
> a scene - say 30 frames - to play on render plasma screen
> (similar to DESK.pov sample) as camera pans past.  I don't
> have the luxury of time like I used to, to figure these out.  POV
> user for at least 6 years though. (not a newbie)  Thanks for input.

When you specify your image_map file name, use concat(str1, str2) to build
it from the frame_number value. In your case, you could do something like
this:

    ....
    image_map
    {
        png concat("file_", str(frame_number, -3), ".png")
    }
    ....

Note: str(frame_number, -3) pads zeros, which most software does it saves
frames. Change it to the number of zeros it pads.

Note: concat takes any number of string arguments, all of which get pieced
together.

Post a reply to this message

Dan P wrote:

> When you specify your image_map file name, use concat(str1, str2) to build
> it from the frame_number value. In your case, you could do something like
> this:
> 
>     ....
>     image_map
>     {
>         png concat("file_", str(frame_number, -3), ".png")
>     }
>     ....
> 

This requires your frame rate to exactly match that of the movie you are 
including.  A more consistent approach would be to interpolate based on 
'clock' rather than 'frame_number'.

(I frequently alter my frame rate when debugging).  The following seems 
to work as I expected it to do.  It returns the filename to be used in 
the image_map.

Cheers,
Marvin

////////////////////////////////////////////////////////////////////
//
// Return filename for an embedded movie.  Parameters are:
//   iclk = clock value for the first frame,
//   zclk = clock value for the first frame,
//   ifrm = the number of the first frame,
//   zfrm = the number of the last frame,
//   digs = the number of digits to pad (NEGATIVE),
//   base = Portion of filename to put before digits,
//   suff = Portion of filename to put after digits.
//
// NOTE: This should not be used when 'clock' is outside of the
// range of 'iclk' to 'zclk'.
//
// For example, from clock 0.0 to 1.0 the following will interpolate
// and return a string in the sequence "file000.png" to "file040.png"
//
//    EmbeddedMovie(0.0, 1.0, 0, 40, -3, "file", ".png" )
//
//
#macro EmbeddedMovie(iclk, zclk, ifrm, zfrm, digs, base, suff )
	#local nfrm = ifrm+(zfrm-ifrm)*(clock-iclk)/(zclk-iclk);
	concat(base, str(nfrm, digs, 0), suff)
#end

Post a reply to this message

"Marvin Taylor" <pov### [at] maltasoftcom> wrote in message
news:4016ef9f$1@news.povray.org...
> Dan P wrote:
<clip>
> This requires your frame rate to exactly match that of the movie you are
> including.  A more consistent approach would be to interpolate based on
> 'clock' rather than 'frame_number'.

A thing to consider when merging two movies with different frame rates is
whether the playback will be noticably inconsistent if the frame rate of the
embedded movie and the framerate of the containing movie are different. You
may have to "average" frames together in order to get a smoother
presentation. If the framerates don't share a common divisor, you'll find it
more challenging to average them together, but it's possible (that's how
they manage to show 24fps movies on 60fps television screen).

Averaging frames together also happens to be the way to do motion blur. The
following C program is a program I built to do just that with PPM files
(that povray can output):

The usage is simple:
blur x y x2 y2 file1.ppm, file2.ppm, file3.ppm, ...
x y x2 y2 grabs that rectangle out of the PPM file so that you can cut out
parts of an image.
It will average as many frames together as you provide on the command line.
I use pnmtopng to process the PPM's later to import into Flash.
Viva la Open Source, baby!


#include <stdio.h>
#include <stdlib.h>


unsigned *buffer = NULL;
char *page = NULL;
unsigned units = 0;
int frames = 0;
int width;
int height;
unsigned x;
unsigned y;
unsigned x2;
unsigned y2;
unsigned w;
unsigned h;



void load (char *path);
void readToken (FILE *stream, char *buf);
void blur();



int main (int argc, char **argv)
{
 int i = 1;

 x = atoi(argv[i++]);
 y = atoi(argv[i++]);
 x2 = atoi(argv[i++]);
 y2 = atoi(argv[i++]);

 w = x2 - x;
 h = y2 - y;

 while (argv[i] != NULL)
 {
  load(argv[i]);
  ++i;
  ++frames;
 }

 blur();

 free((void *) buffer);
 free((void *) page);

 return 0;
}



void blur()
{
 unsigned i;
 unsigned xn;
 unsigned yn;
 unsigned r;
 unsigned g;
 unsigned b;

 fprintf (stderr, "Blurring %u frames together.\n", frames);

 printf ("P6\n%d %d\n255\n", w, h);
 fprintf (stderr, "Building a %d by %d file.\n", w, h);

 for (yn = y ; yn < y2 ; yn++)
 {
  for (xn = x ; xn < x2 ; xn++)
  {
   i = (yn * (width * 3)) + (xn * 3);

   putchar (buffer[i++] / frames);
   putchar (buffer[i++] / frames);
   putchar (buffer[i] / frames);
  }
 }

 fflush(0);
}



void load (char *path)
{
 FILE *stream;
 char s_version[1024];
 char s_width[1024];
 char s_height[1024];
 char s_depth[1024];
 unsigned size;
 unsigned i;
 int c;


 if ((stream = fopen(path, "rb")) != NULL)
 {
  readToken(stream, s_version);
  readToken(stream, s_width);
  readToken(stream, s_height);
  readToken(stream, s_depth);

  width = atoi(s_width);
  height = atoi(s_height);

  if (buffer == NULL)
  {
   units = width * height * 3;
   buffer = (unsigned *) malloc(units * sizeof(int));
   page = (char *) malloc(units);

   fprintf (stderr,
     "Memory: %u for a %d x %d file.\n",
     units, width, height);

   for (i = 0 ; i < units ; i++)
   {
    buffer[i] = 0;
    page[i] = 0;
   }
  }

  i = 0;

  while ((c = fgetc(stream)) != EOF)
  {
   buffer[i++] += c;
  }

  fclose(stream);
 }
 else
 {
  fprintf (stderr, "  FAILED to read %s\n", path);
 }
}



void readToken (FILE *stream, char *buf)
{
 int c;
 c = fgetc(stream);

 while (c != EOF)
 {
  *(buf++) = c;

  c = fgetc(stream);

  if (isspace(c))
  {
   *buf = '\0';
   return;
  }
 }
}

Post a reply to this message

Posting such code is like a red flag in front of a bull for a long-time
coder like me...
  It takes almost inhuman amounts of self-control to resist the temptation
of giving a lecture about good programming habits... :)

  Anyways, I have done a program with the same idea and with even more
features years ago:
  http://iki.fi/warp/PovUtils/average/

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:4016fdd4@news.povray.org...
>   Posting such code is like a red flag in front of a bull for a long-time
> coder like me...
>   It takes almost inhuman amounts of self-control to resist the temptation
> of giving a lecture about good programming habits... :)
>
>   Anyways, I have done a program with the same idea and with even more
> features years ago:
>   http://iki.fi/warp/PovUtils/average/

Hey, you're the guy! You're the guy that taught me how to do it! I didn't
look at your code, yet I read your web-page a while back and was inspired by
it. I didn't realize that was you!!! I can't believe you're on this group -- 
I feel like I've bumped into a celebrity! You've had an impact on my life.
Thanks for putting together that web-page!

Post a reply to this message

Okay, now you've got me all excited. A while back, I started to work on a
Motion Blur program that would import many different kinds of graphics to do
what your Averager did, only with a dialog-based interface. I even went and
bought Visual C++ .Net 2003 so I could use the CImage class. But, life got
in the way and I let it slide off my plate.

Lately, I've become enamored with Open Source as a concept and am wondering:
would you guys be interested in a joint-venture to build a Motion-Blur
compiler studio over this newsgroup? We could take this to the next level!

I'm also working on a program I've been calling ColdStitch which will, with
luck, be an Open Source replacement for SPatch/HamaPatch (but using DirectX
instead of OpenGL* and it will have a lot more features and the target goal
is to make it shrug off a Poser model like it ain't no thang). Part of the
development was to also have it import and export just about every 3D format
I can think-of... and, and I can't stress this enough, it would be Free
Software under the GNU license so that nobody can go and suddenly call it
"Shareware" and kill it.

If there's interest in this, this could be a lot of fun! Or, I'm fairly new
to this group -- is this already happening and can I get in on the action?

PS: Please don't judge my coding skills on that posting -- I wrote that as a
quick one-off to get the job done and I thought it might illustrate the
concept. I know you should never use global variables and should comment
code -- I write C code sometimes like I write PERL code and I didn't
originally plan on releasing that to the public. :-)


* Don't give me no guff about DirectX... I don't see SGI working it's
tail-off to make OpenGL better, but Microsoft is clamoring to do so because
of their gaming franchise, and Microsoft seems to be turning a new leaf
lately... along with the rest of the industry. .NET is wonderful thing.

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> PS: Please don't judge my coding skills on that posting -- I wrote that as a
> quick one-off to get the job done and I thought it might illustrate the
> concept.

  IMHO quick coding is not an excuse to break every possible good coding
principle in the market... ;)

> I know you should never use global variables and should comment
> code

  Global variables were just one of the many problems in your code,
and comments aren't necessary if the code is otherwise very clear and
easy to read.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Dan P" <dan### [at] yahoocom> wrote in
news:40170c7c$1@news.povray.org: 

>  an Open Source replacement for SPatch/HamaPatch 
>

http://jPatch.sourceforge.net

Works nicely and is cross platform.


-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

"Tom Galvin" <tom### [at] imporg> wrote in message
news:Xns947E38A2533E6tomatimporg@203.29.75.35...
> "Dan P" <dan### [at] yahoocom> wrote in
> news:40170c7c$1@news.povray.org:
>
> >  an Open Source replacement for SPatch/HamaPatch
> >
>
> http://jPatch.sourceforge.net

Cool! Thanks!

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:4017878f@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > PS: Please don't judge my coding skills on that posting -- I wrote that
as a
> > quick one-off to get the job done and I thought it might illustrate the
> > concept.
>
>   IMHO quick coding is not an excuse to break every possible good coding
> principle in the market... ;)
>
> > I know you should never use global variables and should comment
> > code
>
>   Global variables were just one of the many problems in your code,
> and comments aren't necessary if the code is otherwise very clear and
> easy to read.

(Bracing my ego) Okay, I'll bring the red scarf out and wave it to and fro.
How can I make my code better?

Post a reply to this message

"Dan P" <dan### [at] yahoocom> wrote in message
news:401851cb@news.povray.org...
> "Tom Galvin" <tom### [at] imporg> wrote in message
> news:Xns947E38A2533E6tomatimporg@203.29.75.35...
> > "Dan P" <dan### [at] yahoocom> wrote in
> > news:40170c7c$1@news.povray.org:
> >
> > >  an Open Source replacement for SPatch/HamaPatch
> > >
> >
> > http://jPatch.sourceforge.net

Definitely not a bad start! I am shocked at the speed and the user interface
is more pleasant than HamaPatch (and more professional than a lot of
"professional" software I see as well). Personally, I'm going to go in the
direction of exploiting a very specific technology for the heavy-duty side
at the expense of what JPatch excels at:
cross-platformabili..illi...ility... (is that a word?) It's great to know
that JPatch is coming along so good and I can see already that it will
replace HamaPatch very nicely, thank-you-very-much.

I look forward to seeing more!!!

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> How can I make my code better?

  That depends on whether you definitely want to stick to C or if you would
like to do it the right way in C++... :)
  With C++ many things can be done a lot more nicely and safely (eg. minimize
the risk of memory leaks).
  However, let's make this the C-way for once. C is quite cumbersome in many
ways, but it may be sometimes good to know how things can be done better
there (you never know when you will be forced to use C in some project).
C offers some tools for better modularity, even though not many.

  So let's see your code:

> unsigned *buffer = NULL;
> char *page = NULL;
> unsigned units = 0;
> int frames = 0;
> int width;
> int height;
> unsigned x;
> unsigned y;
> unsigned x2;
> unsigned y2;
> unsigned w;
> unsigned h;

  I haven't looked yet if all those variables are needed, but anyways,
you should encapsulate them inside a struct. Besides not contamining
the global namespace it makes it easier to enhance your program in
the future. For example, if you want for some reason to keep many images
on memory at the same time it will be much easier having them in struct
instances.
  So perhaps something like this:

struct BlurData
{
    unsigned* buffer;
    char* page;
    unsigned units;
    int frames, width, height;
    unsigned x, y, x2, y2, w, h;
};

  Then in the main() function you can create an instance of this struct
which can be used in the functions it calls:

> int main (int argc, char **argv)
> {
      BlurData data = { NULL, NULL, 0, 0 };

>  int i = 1;
>
>  x = atoi(argv[i++]);
>  y = atoi(argv[i++]);
>  x2 = atoi(argv[i++]);
>  y2 = atoi(argv[i++]);

  Here you don't check if the number of command-line parameters is correct.
That is what 'argc' (argument count) is for.
  If the user didn't give the correct amount of parameters the program
should print a syntax reminder. Instead, your program misbehaves and
prints nothing helpful. It will probably cause a segmentation fault.

  Also, you don't check that the user gave correct parameters, and even
if the parameters are valid, if they make sense.
  atoi() will return 0 if the parameter is not a number. If you want to
go the easy way you could just define that if the user gives invalid
parameters it's the same as he had given a 0. However, you should at
least check that not all the four parameters are 0.

  Using 'i' to index fixed positions in 'argv' seems useless, but that
isn't so bad. It makes it easier to change the number of command-line
parameters.

  So you could perhaps do something like this:

if(argc < 6) /* we need at least 4 coordinates and one file */
{
    fprintf(stderr, "Syntax: %s <x1> <y1> <x2> <y2> <ppm files>\n", argv[0]);
    return EXIT_FAILURE;
}

data.x = atoi(argv[i++]);
data.y = atoi(argv[i++]);
data.x2 = atoi(argv[i++]);
data.y2 = atoi(argv[i++]);

if((data.x==0 && data.y==0 && data.x2==0 && data.y2==0) ||
   data.x2 < data.x || data.y2 < data.y)
{
    fprintf(stderr, "Invalid coordinate parameters.\n");
    return EXIT_FAILURE;
}

data.w = data.x2 - data.x;
data.h = data.y2 - data.y;

  The two last checks in the previous 'if' were so that w and h wouldn't get
screwed up.

>  while (argv[i] != NULL)

  You should use 'argc' to see where do the parameters end. I don't think
you can do that according to the C standard. 'argv[argc]' and beyond can
probably be anything, giving you trash (and if you are lucky causing a
segmentation fault).
  So it should be: while(i < argc)
  We can also do it this way:

for(i = 5; i < argc; ++i)
{
    load(argv[i], &data);
    ++data.frames;
}

  I think that it would be better if load() increased 'data.frames', but
that's a minor detail.

  Naturally blur() has to get the data as parameter now, so the call
would become: blur(&data);

>  free((void *) buffer);
>  free((void *) page);

  Why are you casting the the pointers to void* before freeing them?

  And by the way, this is one of the bad things about C. In C++ you could
make the struct to automatically free those arrays when it goes out of
scope.
  Doing it in the C-way (which you are pretty much forced to do, usually)
not only breaks modularity badly, but is also dangerous because it
increases the danger of memory leaks.

  If we were using C++, we could enhance our struct (which in fact should
be a class with the variables in its private part, but that's another
story) with a destructor, like this:

struct BlurData
{
    (The data here)

    ~BlurData
    {
        if(buffer) free(buffer);
        if(page) free(page);
    }
};

  Then the arrays will be automatically freed when 'data' goes out of
scope (so it doesn't matter where the program is terminated).

  Naturally if we were using C++ we wouldn't make it a struct at all,
but a fully-functional class which in itself makes the blur and handles
practically everything. (main() would simply create an instance of this
class and give it the file names.)

>  return 0;

  Usually you should return EXIT_SUCCESS from main() if you want to be
sure of portability.
  EXIT_SUCCESS is *usually* 0, but the standard does not specify that.

> void blur()
> {
>  unsigned i;
>  unsigned xn;
>  unsigned yn;
>  unsigned r;
>  unsigned g;
>  unsigned b;

  You can write that as:

unsigned i, xn, yn, r, g, b;

>  fflush(0);

  It's 'fflush(stdout);', and it's unneeded anyways.

> void load (char *path)

  It's a good practice to take that kind of parameter as "const char* path".
It not only avoids you accidentally modifying it, but it also avoids all
kinds of problems, specially in C++.

>  char s_version[1024];
>  char s_width[1024];
>  char s_height[1024];
>  char s_depth[1024];

  This should be something which immediately turns on every alarm in your
head.
  Static buffer overflow is the oldest and most common exploit of all time,
and it still is nowadays.

  Why? Because of the attitude of programmers: "This is a small program
it doesn't really matter". They don't get accustomed to writing secure
code, they don't know how to do it, and then when they write code to
a program which will become something important...

  Believe or not, people are still making this mistake, in the year 2004,
in crucially important programs which can be used to exploit systems.
It all starts with all those "small and unimportant" programs...

  Please don't teach yourself bad habits. Get rid of them from the very
start.

  Besides, you are reserving 4 kilobytes of memory for something which
probably needs a few bytes. It doesn't matter here, but it can start
mattering when the same thing is done millions of times...

  In C++ there's a safe way of parsing words from a stream by using
the std::getline() function. In C it requires more work to get a secure
dynamic string working.
  However, you don't even need dynamic strings in this case. For example,
you are storing some version information in 's_version' but you don't use
it anywhere. Also, you are storing numbers in char arrays for no apparent
reason.

  In C there's a great function for parsing files with a fixed content:
fscanf(). Learn to use it. You don't need temporary buffers for reading
integers with it.
  As for the version, you can simply "read it away" from the input file.
You don't need to store it anywhere.

>  if ((stream = fopen(path, "rb")) != NULL)
>  {

  In my personal opinion it's better to handle the failure first and
the success then. Now the failure handling is many tens of lines below,
and it's hard to find.
  As for the failure printing itself, it's a good habit to print the *reason*
why opening failed, not just that it failed.
  There's a nice function in C for doing exactly that: perror().

  And I have never understood why people use obfuscated C for no apparent
reason to open a file. Why it can't be opened and checked in two separate
lines? It's not like it would be less efficient or anything, but certainly
easier to read.

  So my suggestion is:

stream = fopen(path, "rb");
if(stream == NULL)
{
    fprintf(stderr, "Couldn't open ");
    perror(path);
    return;
}

  The fprintf/perror combination is a nice trick I figured out years ago
to print out a nicely-formatted error message.

>    buffer = (unsigned *) malloc(units * sizeof(int));

  Allocating space for ints but converting it to an unsigned array is
a bit odd. It usually works, but...
  Better safe than sorry, just use sizeof(unsigned). It's not that hard.

  By the way, you don't check whether the subsequent images have a proper
size with regard to the first image. It's a good idea to check that.
(For instance, if the subsequent images are bigger than the first one
you will be writing outside your array, causing a segmentation fault.
If they are smaller, the result will be quite odd.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:40190021@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > How can I make my code better?
>
>   That depends on whether you definitely want to stick to C or if you
would
> like to do it the right way in C++... :)
>   With C++ many things can be done a lot more nicely and safely (eg.
minimize
> the risk of memory leaks).
>   However, let's make this the C-way for once. C is quite cumbersome in
many
> ways, but it may be sometimes good to know how things can be done better
> there (you never know when you will be forced to use C in some project).
> C offers some tools for better modularity, even though not many.
>
>   So let's see your code:

This is GREAT stuff you're pointing out!!
Every C/C++ programmer should sit down and read the previous message in
full!

>   I haven't looked yet if all those variables are needed, but anyways,
> you should encapsulate them inside a struct. Besides not contamining
> the global namespace it makes it easier to enhance your program in
> the future. For example, if you want for some reason to keep many images
> on memory at the same time it will be much easier having them in struct
> instances.

That's a great point! I had never thought of that.

>   Then in the main() function you can create an instance of this struct
> which can be used in the functions it calls:

<stuff about parameters>

That's one of those things that I didn't put in because I was in a hurry :-)
Definitely good advice for any production piece of software, though.

>   Naturally blur() has to get the data as parameter now, so the call
> would become: blur(&data);

Always a good thing to pass things around. Otherwise, it's just hard to use
it again. Good advice!

> >  free((void *) buffer);
> >  free((void *) page);
>
>   Why are you casting the the pointers to void* before freeing them?

I saw that in a book and wondered the same thing when I first saw it. It
just stuck in my head as one of those, "Well, I'm sure the author knew a
reason... maybe it's for some compatibility I don't know of?" kind of
things.

>   And by the way, this is one of the bad things about C. In C++ you could
> make the struct to automatically free those arrays when it goes out of
> scope.
>   Doing it in the C-way (which you are pretty much forced to do, usually)
> not only breaks modularity badly, but is also dangerous because it
> increases the danger of memory leaks.

(Raising a glass to that!)

<class stuff>

Definitely. I do C for little things, but always C++ for anything "real".

>   Usually you should return EXIT_SUCCESS from main() if you want to be
> sure of portability.
>   EXIT_SUCCESS is *usually* 0, but the standard does not specify that.

I did not know that! I'll remember that!!!

> > void blur()
> > {
> >  unsigned i;
> >  unsigned xn;
> >  unsigned yn;
> >  unsigned r;
> >  unsigned g;
> >  unsigned b;
>
>   You can write that as:
>
> unsigned i, xn, yn, r, g, b;

Well, this one we differ on. I find it easier to conceptualize the code when
everything is on a seperate line. It doesn't affect compile-time, but I
think it makes the code more readable. It's a style-thang.

> >  fflush(0);
>
>   It's 'fflush(stdout);', and it's unneeded anyways.

Good point on using the variable. I've worked on systems where I had trouble
with putchar() without flushing, though.

> > void load (char *path)
>
>   It's a good practice to take that kind of parameter as "const char*
path".
> It not only avoids you accidentally modifying it, but it also avoids all
> kinds of problems, specially in C++.

Hey, great idea!

<stuff about buffer-overrun exploits>

Normally, I do worry about that for any production code (I always use
strncpy, or things like that, for example). That is a great point about
vulernabilities.

>   In C there's a great function for parsing files with a fixed content:
> fscanf(). Learn to use it. You don't need temporary buffers for reading
> integers with it.

Cool

>   As for the version, you can simply "read it away" from the input file.
> You don't need to store it anywhere.

It's  just a habit to read things like that for future enhancements. Maybe
not a good one.

> >  if ((stream = fopen(path, "rb")) != NULL)
> >  {
>
>   In my personal opinion it's better to handle the failure first and
> the success then. Now the failure handling is many tens of lines below,
> and it's hard to find.

I've never heard that take on it before, but it is a logical take! I usually
like to list the code in good->error order because it becomes easier to read
what it is supposed to do in succession. I guess you can call that an
"optimistic" coding structure :-)

>   As for the failure printing itself, it's a good habit to print the
*reason*
> why opening failed, not just that it failed.
>
>   There's a nice function in C for doing exactly that: perror().

So true!

>   And I have never understood why people use obfuscated C for no apparent
> reason to open a file. Why it can't be opened and checked in two separate
> lines? It's not like it would be less efficient or anything, but certainly
> easier to read.

Laziness.

>   The fprintf/perror combination is a nice trick I figured out years ago
> to print out a nicely-formatted error message.
>
> >    buffer = (unsigned *) malloc(units * sizeof(int));
>
>   Allocating space for ints but converting it to an unsigned array is
> a bit odd. It usually works, but...
>   Better safe than sorry, just use sizeof(unsigned). It's not that hard.

Oh, you're right -- that was a bug on my part. I used unsigned so I can use
up to 65535 instead of being stuck with half that.

>   By the way, you don't check whether the subsequent images have a proper
> size with regard to the first image. It's a good idea to check that.
> (For instance, if the subsequent images are bigger than the first one
> you will be writing outside your array, causing a segmentation fault.
> If they are smaller, the result will be quite odd.)

Again... laziness :-}

Thank you very much for the helpful critique! You have made an impact on my
coding style already, particularly with the exit success message. I really
appreciate that you took the time to help me out!!!

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> >   Usually you should return EXIT_SUCCESS from main() if you want to be
> > sure of portability.
> >   EXIT_SUCCESS is *usually* 0, but the standard does not specify that.

> I did not know that! I'll remember that!!!

  It's way too common that people don't care about the return value of
the program they are making (specially if it's a command-line program).
  Often they return EXIT_SUCCESS and EXIT_FAILURE because they have been
taught to do so, but they don't really understand why they should do so.
  In the worst case they don't care what the program returns and they
for example *always* return 0 regardless of the cause of the program
termination, or what is a lot worse, always return a value different
from 0.

  It is important that a program returns EXIT_FAILURE when it could not
do what it was supposed to do (eg. bad command-line parameters, couldn't
open an input file, etc). It's also important to return EXIT_SUCCESS when
the program was able to correctly perform its task and everything went fine.

  One could ask "why is it so important? If I run the program from the
command line, what does it matter what it returns? I will see from its
printout if it went well or wrong."

  However, programs are not always run from the command line. One common
usage of command-line programs where the correct return value is crucial
is when running it from a Makefile.
  The make program will *stop* if the program returns an error code
(usually a value different from 0). Thus if the program returns an error
code needlessly it will make the program unusable in a Makefile.
  It's also important for the program to return an error code when an
error happens: If it always returns success, make will not know to
stop and will think the program was successful and will continue (thus
potentially causing all kinds of weird results, the reason of which can
be very hard to find).

> > >  fflush(0);
> >
> >   It's 'fflush(stdout);', and it's unneeded anyways.

> Good point on using the variable. I've worked on systems where I had trouble
> with putchar() without flushing, though.

  flushing a stream is necessary when you need to ensure that the output
is really written to its destination at that point (streams are usually
buffered and things may not be written immediately to the destination).
  If it's enough for the output to be written when the program ends then
there's no need to flush explicitly because the compiler will generate
the flushing call at the end of the program anyways (the C standard
actually requires this, AFAIK).

  One example of a useful use of fflush() is when you are printing some
progress information with printf() (using "\r" to go to the beginning
of the line after each update): fflush(stdout) will ensure that the
progress information is actually printed to standard output at that point.

  fflush() shouldn't be called too often because it makes the program slow.
For example calling fflush() after each output character is madness unless
there's a really good reason for you to do so... :)

  (By the way, stderr is usually unbuffered, which means that it's in
practice flushed after each character. This means that stderr should not
be used for printing megabytes of data. :) )

  And by the way, fflush() takes a FILE pointer, not a file descriptor.
When you give it a 0 you are actually giving it a NULL pointer.

> Oh, you're right -- that was a bug on my part. I used unsigned so I can use
> up to 65535 instead of being stuck with half that.

  Which 10-years old system are you using where ints are 16-bit? ;)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

"Darren" <dne### [at] sanrrcom> wrote in message
news:401a7b78$1@news.povray.org...
> Warp wrote:
> >   If it's enough for the output to be written when the program ends then
> > there's no need to flush explicitly because the compiler will generate
> > the flushing call at the end of the program anyways (the C standard
> > actually requires this, AFAIK).

Ah yes, but remember: we might take this code and wrap it in a class later,
so having that fflush there might help us avoid future bugs. Also, even
though the C standard requires this, experience has shown me that not
everybody keeps to the standard when they write their C compilers (see
Visual Studio). To me, flushing the buffer is kindof like closing a file. I
don't have to at the end, but it's good practice and it really doesn't hurt
anything if the stream isn't buffered.

Also, the reason I output using STDOUT is because the netpbm library works
that way. Remember, I chained this program together in a pipe to create PNG
files from PPM files. I don't think there is even a way to use netpbm
without using STDOUT, although I might be wrong (happens a lot).

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> Ah yes, but remember: we might take this code and wrap it in a class later,
> so having that fflush there might help us avoid future bugs.

  If you are going to enhance the program to something which may be used
somewhere where flushing can be important, you can add it then. :)

> Also, even
> though the C standard requires this, experience has shown me that not
> everybody keeps to the standard when they write their C compilers (see
> Visual Studio).

  Can you imagine a compiler which does not output all data written to
a file if you don't fflush() explicitly? Can you imagine how many buggy
programs that would create? Almost every single program would misbehave
if this was the case.
  I can't imagine that. Believe me: Compilers do generate code which flushes
the output.

> To me, flushing the buffer is kindof like closing a file. I
> don't have to at the end, but it's good practice and it really doesn't hurt
> anything if the stream isn't buffered.

  I see no reason. The stream *will* be flushed, period. There's no doubt
about that.
  If you use fflush() too much you are just potentially creating inefficient
code.

  There are *tons* of things which one really *should* do but which no-one
does because of laziness or whatever (for example, have you ever checked
that your printf() call really succeeded?). However, I don't think calling
fflush() is one of them.

  fflush() is important and handy when you really have to make sure that
the output is flushed immediately, but using it needlessly is a waste
of code. :)

> Also, the reason I output using STDOUT is because

  Did someone put that decision into question?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <40170c7c$1@news.povray.org>,
 "Dan P" <dan### [at] yahoocom> wrote:

> * Don't give me no guff about DirectX... I don't see SGI working it's
> tail-off to make OpenGL better, but Microsoft is clamoring to do so because
> of their gaming franchise, and Microsoft seems to be turning a new leaf
> lately... along with the rest of the industry. .NET is wonderful thing.

...
I don't know where to start. Argh...
*beats Daniel repeatedly over the head with a clue-bat...*

Look into OpenGL 2.0. OpenGL is being actively developed, and the 
stability of its API is an advantage. And both DirectX and .NET are 
completely, utterly useless to anyone not on a recent version of Windows.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:401b8003@news.povray.org...
>> > Also, the reason I output using STDOUT is because
>
>   Did someone put that decision into question?

I thought somebody said pushing megabytes of data through STDOUT was a bad
idea, but I might have misread.

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-5D04D9.14013731012004@news.povray.org...
> In article <40170c7c$1@news.povray.org>,
>  "Dan P" <dan### [at] yahoocom> wrote:
>
> > * Don't give me no guff about DirectX... I don't see SGI working it's
> > tail-off to make OpenGL better, but Microsoft is clamoring to do so
because
> > of their gaming franchise, and Microsoft seems to be turning a new leaf
> > lately... along with the rest of the industry. .NET is wonderful thing.
> ...
> I don't know where to start. Argh...
> *beats Daniel repeatedly over the head with a clue-bat...*
>
> Look into OpenGL 2.0. OpenGL is being actively developed, and the
> stability of its API is an advantage. And both DirectX and .NET are
> completely, utterly useless to anyone not on a recent version of Windows.

Okay, I'm admittedly at fault here because I used an antiquated phrase to
start that footnote and I can see where some people might not understand
what "Don't give me not guff" might mean. What that means is that,
undoubtedly, some people are going to feel very strongly about this
perception and I know why and it is just a matter of opinion. Kind of like
predicting the stock market -- lots of people have different opinions on
where it is going to go and the future will tell. I happen to think that
DirectX is the future, not OpenGL, based on two things: 1. Microsoft is
realizing that their gaming business very important and they tend to do well
on things they find important (think IDEs), and 2. I have been in SGI and I
have reason not to have confidence in that company based on personal,
anecdotal experience.

Also, my target audience is people with the latest version of Windows. I
have decided to go in a different direction than JPatch, which is why I'm
thrilled that JPatch exists. I'm looking to exploit a specific technology,
yet provide the source openly. It's like the fight between Linux Torvalds
and Andy Tanenbaum; they both have completely different opinons on how
someone should build an operating system, but they are both valid and based
on personal opinion. Linus just happened to build his into Linux. See page:
http://cscserver.cc.edu/jtowell/AAATeaching/csc317/Linus%20vs_%20Tanenbaum.htm

I'm not mad, I just have an opinion and I realize it will differ and that
people feel very strongly about it.

Post a reply to this message

In article <40170c7c$1@news.povray.org> , "Dan P" 
<dan### [at] yahoocom> wrote:

> * Don't give me no guff about DirectX... I don't see SGI working it's
> tail-off to make OpenGL better, but Microsoft is clamoring to do so because
> of their gaming franchise, and Microsoft seems to be turning a new leaf
> lately... along with the rest of the industry. .NET is wonderful thing.

Remember that there is more than gaming.  And DirectX, from a programmer's
perspective is an impossible API.  It just changes 90% with each version.

OpenGL has many flaws, its error reporting and state model being the major
ones that get in the way of smooth development.  Some of the extensions are
a bit odd to use (consider texture "objects" versus display lists and how
they are activated), but they are fairly portable and the API is very
stable.

For any project whose code you don't finish and forget, like you do for
games, this is extremely important if you want to be able to support your
applications for more than one version of Windos.

    Thorsten

PS: Please try not to post such irrelevant statements like ".NET is
wonderful thing.".  Such discussion does not belong here.

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <cjameshuff-5D04D9.14013731012004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

> Look into OpenGL 2.0. OpenGL is being actively developed

Note that Open GL 2.0 started as a marketing activity of one single company
and not as a standard proposal.  Up until today, "OpenGL 2.0" is still very
little more than that, and nobody can be certain any final standard, should
one result of it, will ever fulfill the marketing promises that were made.
And OpenGL 1.5 offers access to essentially all the same features.  Not that
there is any driver for Windos yet that even full support OpenGL 1.4 <sigh>

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:401c1ec3@news.povray.org...
> In article <40170c7c$1@news.povray.org> , "Dan P"
> <dan### [at] yahoocom> wrote:
> Remember that there is more than gaming.  And DirectX, from a programmer's
> perspective is an impossible API.  It just changes 90% with each version.

Evolution.

> PS: Please try not to post such irrelevant statements like ".NET is
> wonderful thing.".  Such discussion does not belong here.

It was relevant to the posting. It isn't relevant to this one. Not sure why
you brought it up. Such discussion doesn't belong here.

Post a reply to this message

In article <401c0f53$1@news.povray.org> , "Dan P" 
<dan### [at] yahoocom> wrote:

> 1. Microsoft is
> realizing that their gaming business very important and they tend to do well
> on things they find important (think IDEs), and

If you do games, yes.  But maybe you missed it, but there are other uses of
3D graphics.  And the interest and money behind that is several magnitudes
bigger than what 3D games can ever reach.  One of these interests is
commonly referred to as "military".  And you sure don't think anybody still
designs houses, cars, ships, trains or and other machine or device with
pencil and paper these days, do you?

> 2. I have been in SGI and I
> have reason not to have confidence in that company based on personal,
> anecdotal experience.

You have no clue about the specification process of OpenGL, do you?  Because
if you did you would know that SGI released the OpenGL specification process
to a industry group a *very* long time ago.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <401c2147$1@news.povray.org> , "Dan P" 
<dan### [at] yahoocom> wrote:

>> Remember that there is more than gaming.  And DirectX, from a programmer's
>> perspective is an impossible API.  It just changes 90% with each version.
>
> Evolution.
>
>> PS: Please try not to post such irrelevant statements like ".NET is
>> wonderful thing.".  Such discussion does not belong here.
>
> It was relevant to the posting. It isn't relevant to this one. Not sure why
> you brought it up. Such discussion doesn't belong here.

It was just a warning that the following might happen:

*plonk*

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:401c217f@news.povray.org...
> In article <401c0f53$1@news.povray.org> , "Dan P"
> <dan### [at] yahoocom> wrote:
>
> You have no clue about the specification process of OpenGL, do you?
Because
> if you did you would know that SGI released the OpenGL specification
process
> to a industry group a *very* long time ago.

Wow, Thorsten, friend, take a deep breath. I don't know much about OpenGL
except SGI originally made it and they still have it trademarked. I don't
trust SGI and, in fact, I don't even /like/ SGI. And, for the record, I'm
not all much on Microsoft either, but I do know that they are aggressively
working on DirectX to meet their needs and, as a side-effect, they wind up
meeting mine. You might trust SGI not to wait until you guys fix it up and
make it great before they take it from you and make money off it, but I
don't. The OpenSource movement doesn't mean you should be naive about how
corporations work. You really should make your own specification that isn't
owned by a corporation if you want to make something open for a community to
work on and /keep/.

Just because SGI released the specification process a long time ago doesn't
mean they forgot about it. Think about Unisys and GIF.

I'm not making a game with DirectX -- I'm making a patch editor that will
hopefully come to fruition some day. DirectX is generally used for games,
yet it is actually just an abstraction layer that lets me exploit the
hardware capabilites of my equipment. That's why the called it DirectX -
Direct for direct to hardware, X to mean all the different hardware (X is a
variable). I also think that it will be easier to distribute and install the
editor using DirectX over OpenGL. And, really, I just want to learn more
about DirectX in the process. I understand you want things, but this patch
editor is really just about what I want and if other people can benefit from
it, great.

And remember: I'm not Bill, I'm just a guy who wants to make a great patch
editor.

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:401c22c6@news.povray.org...
> It was just a warning that the following might happen:
>
> *plonk*

You must learn that when people don't agree with you, it doesn't mean they
don't know anything. Really, relax dude -- I haven't said anything that is
"wrong", yet, so I don't deserve a plonk. Facts I have stated:

1. SGI owns the trademark to OpenGL.
2. DirectX is a hardware abstraction layer that lets me exploit the
capabilities of my hardware for speed.
3. DirectX isn't only for games.
4. .NET is a wonderful thing.

Please, feel free to debunk these claims somehow before you carelessly plonk
somebody.

Post a reply to this message

In article <401c22c6@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:
> In article <401c2147$1@news.povray.org> , "Dan P"
> <dan### [at] yahoocom> wrote:
>
>>> Remember that there is more than gaming.  And DirectX, from a programmer's
>>> perspective is an impossible API.  It just changes 90% with each version.
>>
>> Evolution.
>>
>>> PS: Please try not to post such irrelevant statements like ".NET is
>>> wonderful thing.".  Such discussion does not belong here.
>>
>> It was relevant to the posting. It isn't relevant to this one. Not sure why
>> you brought it up. Such discussion doesn't belong here.
>
> It was just a warning that the following might happen:
>
> *plonk*

FYI, for everybody reading this thread without a technical background:

Do not take anything he says for fact; hardly anything is. There is no point
to argue on such a level and thus no reason to respond to him.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:401c49e8$1@news.povray.org...
> FYI, for everybody reading this thread without a technical background:
>
> Do not take anything he says for fact; hardly anything is. There is no
point
> to argue on such a level and thus no reason to respond to him.

I fully support Thorsten in this claim. Now, Thorsten is going to teach you
all why I don't have a technical background by debunking what I have said:

1. SGI owns the trademark to OpenGL.
2. DirectX is a hardware abstraction layer that lets me exploit the
capabilities of my hardware for speed.
3. DirectX isn't only for games.
4. .NET is a wonderful thing.

Thorsten is interested in you understanding these things are wrong and why
the prove I'm not technical.
Unselfishly, he will lay out his claims for these things so that you don't
wind up like me: plonked.
He is interested in you understanding what the facts are so you will be
enlightened.

And remember: Thorsten is an important person.

Post a reply to this message

"Dan P" <dan### [at] yahoocom> wrote in message
news:401c581e$1@news.povray.org...
> "Thorsten Froehlich" <tho### [at] trfde> wrote in message
> news:401c49e8$1@news.povray.org...

Oh, and my grammar doesn't count ;-)

Post a reply to this message

ok ... OK.   Start a new thread.
I started this one days ago, and let's end it already.

Period.

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> I thought somebody said pushing megabytes of data through STDOUT was a bad
> idea, but I might have misread.

  You did. I said writing megabytes of data to stderr is a bad idea
because stderr is unbuffered.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> I'm not making a game with DirectX -- I'm making a patch editor that will
> hopefully come to fruition some day. DirectX is generally used for games,
> yet it is actually just an abstraction layer that lets me exploit the
> hardware capabilites of my equipment. That's why the called it DirectX -
> Direct for direct to hardware, X to mean all the different hardware (X is a
> variable). I also think that it will be easier to distribute and install the
> editor using DirectX over OpenGL.

  You should perhaps get some information about OpenGL instead of basing
your opinions in prejudgements and assumptions. Writing text like the
one above is only causing more knowledgeable people to die from laughter.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> > Remember that there is more than gaming.  And DirectX, from a programmer's
> > perspective is an impossible API.  It just changes 90% with each version.

> Evolution.

  Nope. It means that MS is unbelievably bad at designing APIs.

  And by the way, have you ever compared Direct3D code to equivalent
OpenGL code?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> Facts I have stated:

> 1. SGI owns the trademark to OpenGL.

  You seem to imply that Microsoft does not own trademarks to DirectX.

> 2. DirectX is a hardware abstraction layer that lets me exploit the
> capabilities of my hardware for speed.

  You seem to imply that OpenGL is not a hardware abstraction layer.

> 3. DirectX isn't only for games.

  Quite clearly you are missing the point of the original reply.

> 4. .NET is a wonderful thing.

  And how is this related to anything?
  That statement just sounds like you are victim of hype.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> I fully support Thorsten in this claim. Now, Thorsten is going to teach you
> all why I don't have a technical background by debunking what I have said:

  You are missing the point. By what you have said you are indirectly
implying things (such as that DirectX is not trademarked, OpenGL is not
an abstraction layer to use hardware, etc).

  If you say (in practice) "I prefer DirectX because it's an abstraction
layer to use hardware" you are practically saying "OpenGL is not an
abstraction layer to use hardware and does not allow me to use it".
This of course is a laughable claim.
  Understand now?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <401c0f53$1@news.povray.org>,
 "Dan P" <dan### [at] yahoocom> wrote:

> Okay, I'm admittedly at fault here because I used an antiquated phrase to
> start that footnote and I can see where some people might not understand
> what "Don't give me not guff" might mean.

Oh, I understood that perfectly. However, you're making what IMO is such 
a bad decision that I felt I had to warn you anyway...if someone points 
a gun at their foot, I'm going to tell them point it elsewhere, whether 
or not they say they know what they're doing.


> DirectX is the future, not OpenGL, based on two things: 1. Microsoft is
> realizing that their gaming business very important and they tend to do well
> on things they find important (think IDEs), and 2. I have been in SGI and I
> have reason not to have confidence in that company based on personal,
> anecdotal experience.

DirectX is certainly not the future. Gaming is unimportant overall, and 
has very unusual needs that aren't helpful to most 3D applications. It's 
you're decision, but must warn you that I see it as an extremely bad 
one. At least make sure you abstract the code so you can easily drop in 
an OpenGL replacement...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote in
news:cjameshuff-3EE179.12061601022004@news.povray.org: 


> 
> DirectX is certainly not the future. Gaming is unimportant overall,
> and has very unusual needs that aren't helpful to most 3D
> applications. It's you're decision, but must warn you that I see it as
> an extremely bad one. At least make sure you abstract the code so you
> can easily drop in an OpenGL replacement...
> 

Another point.

DirectX = Windows only
Open GL = Windows/Mac/Linux/Unix/...

Keep in mind that Windows is not the platform of choice for most graphics 
professionals.


-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

I've decided to ultimately answer this thread by writing the software.
This is my last reply on this opinion thread.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:401cced2@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > I fully support Thorsten in this claim. Now, Thorsten is going to teach
you
> > all why I don't have a technical background by debunking what I have
said:
>
>   You are missing the point. By what you have said you are indirectly
> implying things (such as that DirectX is not trademarked, OpenGL is not
> an abstraction layer to use hardware, etc).
>
>   If you say (in practice) "I prefer DirectX because it's an abstraction
> layer to use hardware" you are practically saying "OpenGL is not an
> abstraction layer to use hardware and does not allow me to use it".
> This of course is a laughable claim.
>   Understand now?

Okay, wait a second. I'm breaking my silence on this because I just happen
to be in the mood to. You are reading my statements wrong. I never said I
preferred DirectX because it was an abstraction layer anywhere -- look at
the posts and /read/ what they /actually/ say and not what you /want/ them
to say. No kidding OpenGL is also an abstraction layer -- that's a given and
to assume I don't know that is pretty insulting. I was responding to
Thronsten's claim that everything I say is false by listing the only
assertions I made, all of which are demonstrably true. In fact, I haven't
said anything false at all. Don't assume what I say, read what I say. You're
judging me based on emotion and making assumptions about how I feel.

You won't find many people who have hated Microsoft as much as I in the
past. I have progressed to hating all corporations -- something opensource
folks LIKE MYSELF should respect -- and have decided to exploit technologies
based on which would be best for my target audience. That's my decision to
make -- it doesn't make me stupid, it is a choice, and I never stated
otherwise. I want to make a patch editor that uses everything that the
newest video cards has to offer and I am targetting Windows. I haven't said
that doing otherwise is a bad idea -- in fact, I said that I'm happy that
people /were/ doing that so that there were alternatives to my software.

In short, I would like to respectfully ask you to treat me with respect if
you expect respect back from me. And get a dictionary and look up the word
"tact".

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> You are reading my statements wrong. I never said I
> preferred DirectX because it was an abstraction layer anywhere

  If in a DirectX vs. OpenGL discussion you stress that "all I have said
is that DirectX is a hardware abstraction layer" you are making an
implication. Granted, you are not directly claiming anything about
OpenGL, but there's no other way of understanding it than that you are.

> No kidding OpenGL is also an abstraction layer -- that's a given and
> to assume I don't know that is pretty insulting.

  I did not claim that you don't know what OpenGL is. I said that by
accentuating something about DirectX you are indirectly making the
claim that DirectX is better than OpenGL because of that thing.

  If I'm not completely wrong, the main issue here was why use DirectX
which is Windows-only when you can use OpenGL which is cross-platform.
If you prefer DirectX you should presents arguments in its favor, and
"it's a hardware abstraction layer" is certainly not one.

> I was responding to
> Thronsten's claim that everything I say is false by listing the only
> assertions I made

  I assume that Thorsten made the same assumption as I did: By presenting
a pro-DirectX argument you are indirectly claiming that OpenGL lacks that
feature.

> Don't assume what I say, read what I say.

  It's the writer who is responsible of making his point clear to the
reader. If you write your point unclearly and in a way which can cause
confusion, it's your fault. Be careful about how you write things if
you want to avoid misunderstandings.

> You won't find many people who have hated Microsoft as much as I in the
> past. I have progressed to hating all corporations -- something opensource
> folks LIKE MYSELF should respect -- and have decided to exploit technologies
> based on which would be best for my target audience. That's my decision to
> make -- it doesn't make me stupid, it is a choice, and I never stated
> otherwise. I want to make a patch editor that uses everything that the
> newest video cards has to offer and I am targetting Windows. I haven't said
> that doing otherwise is a bad idea -- in fact, I said that I'm happy that
> people /were/ doing that so that there were alternatives to my software.

  What it seems to me is that you made a suggestion to the community,
the community gave you feedback and you didn't like the feedback and
got angry.

  You should be aware that if you make a suggestion like "hey, let's make
a very useful windows-only program for POV-Ray" you will most certainly
get answers of the type "why should it be windows-only?". That's only
normal and does not mean the community is despising your idea. It only
means that since POV-Ray is a multi-platform software enjoyed by a wide
variety of people using many different platforms, it's always nice to
get third-party utility programs which also work on those several
platforms.
  If the reason why you are making it windows-only is questionable (for
example of the type "I will use DirectX because I like it more") people
are going to complain. That's also normal and should not be taken as a
personal offence. People are not saying "DirectX sucks" or "you are stupid"
by this, they are only complaining to the fact that you are limiting the
portability of your program and thus depriving other platform users from
the program for no good reason.

  If you make such suggestion you should be aware of the response the
community will give you. Getting angry from the feedback is not wise.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:401f6e11@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > You are reading my statements wrong. I never said I
> > preferred DirectX because it was an abstraction layer anywhere
>
>   If in a DirectX vs. OpenGL discussion you stress that "all I have said
> is that DirectX is a hardware abstraction layer" you are making an
> implication. Granted, you are not directly claiming anything about
> OpenGL, but there's no other way of understanding it than that you are.

No, Warp, I was responding to Thornsten saying everything I say is wrong.
Not that I have this burning, insecure need to be right, but I'm not Jesus
so don't punch me in the face. I listed out the few assertions I made that
weren't opinion and DirectX being an abstraction layer was one of many.

> > No kidding OpenGL is also an abstraction layer -- that's a given and
> > to assume I don't know that is pretty insulting.
>
>   I did not claim that you don't know what OpenGL is. I said that by
> accentuating something about DirectX you are indirectly making the
> claim that DirectX is better than OpenGL because of that thing.

Then you misunderstood. "Seek first to understand," is what Steven Covey
rights. Don't just go off on me until you understand what I'm saying. I am
saying that DirectX is a  hardware abstraction layer and, thus, is not just
for games. For example, I used Vegas Audio which uses DirectSound -- part of
DirectX. The fact that Thornsten says it is only for games shows his
ignorance about DirectX, but notice I didn't flame him because I have too
much tact.

>   If I'm not completely wrong, the main issue here was why use DirectX
> which is Windows-only when you can use OpenGL which is cross-platform.
> If you prefer DirectX you should presents arguments in its favor, and
> "it's a hardware abstraction layer" is certainly not one.

It wasn't. See next paragraph:

> > I was responding to
> > Thronsten's claim that everything I say is false by listing the only
> > assertions I made
>
>   I assume that Thorsten made the same assumption as I did: By presenting
> a pro-DirectX argument you are indirectly claiming that OpenGL lacks that
> feature.

No I'm not.

> > Don't assume what I say, read what I say.
>
>   It's the writer who is responsible of making his point clear to the
> reader. If you write your point unclearly and in a way which can cause
> confusion, it's your fault. Be careful about how you write things if
> you want to avoid misunderstandings.

If you don't understand, ask. Don't just go off and flame. Do you really
want me to pick apart what people can misunderstand about your messages?

> > You won't find many people who have hated Microsoft as much as I in the
> > past. I have progressed to hating all corporations -- something
opensource
> > folks LIKE MYSELF should respect -- and have decided to exploit
technologies
> > based on which would be best for my target audience. That's my decision
to
> > make -- it doesn't make me stupid, it is a choice, and I never stated
> > otherwise. I want to make a patch editor that uses everything that the
> > newest video cards has to offer and I am targetting Windows. I haven't
said
> > that doing otherwise is a bad idea -- in fact, I said that I'm happy
that
> > people /were/ doing that so that there were alternatives to my software.
>
>   What it seems to me is that you made a suggestion to the community,
> the community gave you feedback and you didn't like the feedback and
> got angry.

Oh, I got angry about somebody saying, "Everything this guy says is wrong,
don't listen to him." Imagine that. I'm not pro anything. I have no emotion
about hardware and software. I do have a bit of emotion when a certain prima
donna has to stroke his ego at my expense.

>   You should be aware that if you make a suggestion like "hey, let's make
> a very useful windows-only program for POV-Ray" you will most certainly
> get answers of the type "why should it be windows-only?". That's only
> normal and does not mean the community is despising your idea. It only
> means that since POV-Ray is a multi-platform software enjoyed by a wide
> variety of people using many different platforms, it's always nice to
> get third-party utility programs which also work on those several
> platforms.

__READ__ my post. I didn't even mention POV-Ray. POV-Ray was just going to
be one of the output formats. Yes, yes, it's on a POV-Ray group, but guess
what -- POV-Ray is just one of the tools we all use.

>   If the reason why you are making it windows-only is questionable (for
> example of the type "I will use DirectX because I like it more") people
> are going to complain. That's also normal and should not be taken as a
> personal offence. People are not saying "DirectX sucks" or "you are
stupid"
> by this, they are only complaining to the fact that you are limiting the
> portability of your program and thus depriving other platform users from
> the program for no good reason.

I didn't SAY I liked DirectX. DirectX is an ugly API. I just wanted to push
my hardware as far as possible and I can't generally do that with OpenGL.
And, I DID say I don't like SGI. Never said a thing about DirectX. I don't
in fact like SGI. That doesn't mean I like Microsoft. It's simple, simple
logic -- just because A is an apple doesn't mean B has to be an orange.

And, to your second point, "Do not take anything he says for fact; hardly
anything is. There is no point to argue on such a level and thus no reason
to respond to him. Do not take anything he says for fact; hardly anything
is. There is no point to argue on such a level and thus no reason to respond
to him." - Thornsten. Pretty hard to take that the right way. Talk about
your inferences!

Finally, I had said I was thrilled there was a cross-platform patch editor
out there because now I can make a platform-specific version without guilt.
I'm not depriving anybody: I'm looking for a niche. And, frankly, I don't
really care about depriving people of anything, particularly when they
wouldn't have what they would have been deprived of hadn't I written the
software in the first place. This isn't some evangelical journey I'm on to
get everybody to hug each other. I'm out to make a great piece of software
if my skills allow it.

>   If you make such suggestion you should be aware of the response the
> community will give you. Getting angry from the feedback is not wise.

This is something that analytical-types tend to misunderstand. I don't have
to be angry to make an assertion. Just remember: before you judge, seek
first to understand. Don't assume a person is unknowledgable and plonk them.
If you don't care, just don't respond. And, if you are feeling insecure
about yourself and you need people to think you're smart, don't do it at the
expense of others. You should have learned that in high school, whether you
were the bully or the victim. Really, I'm only miffed at Thornsten here,
whom I feel must have issues. Yes, Thornsten, I am impressed that you are
one of the four who worked on 3.5, but you're not god; nobody is, and
everybody deserves a level of respect. If you can't get that respect without
putting others down in your group, you should take a hard look in the
mirror.

Now, if you want to respond to this, fine, but this is all I really have the
energy or time to say on this issue.

Post a reply to this message

"Darren" <dne### [at] sanrrcom> wrote in message
news:401fd6db$1@news.povray.org...
> Warp wrote:
> >   I did not claim that you don't know what OpenGL is. I said that by
> > accentuating something about DirectX you are indirectly making the
> > claim that DirectX is better than OpenGL because of that thing.
>
> That's called PostModernist Deconstructionalism. :-)

Hey, that's true!
Freaky.

I guess he can be forgiven, then; it's just society :-)

Post a reply to this message

In article <401fd1cb$1@news.povray.org> , "Dan P" 
<dan### [at] yahoocom> wrote:

> I am
> saying that DirectX is a  hardware abstraction layer and, thus, is not just
> for games. For example, I used Vegas Audio which uses DirectSound -- part of
> DirectX. The fact that Thorsten says it is only for games shows his
> ignorance about DirectX, but notice I didn't flame him because I have too
> much tact.

First, I did not say that it is only for games, I only pointed out that
there are other applications that use 3D graphics than just games.  You were
the one who said "Don't give me no guff about DirectX... I don't see SGI
working it's tail-off to make OpenGL better, but Microsoft is clamoring to
do so because of their gaming franchise [...]".  So, it was you who clearly
said that DirectX is only being heavily developed because of the market for
games.

But lets settle this once and for all, Microsoft is very clear about what
DirectX is for:

>>>
Where Applicable
DirectX is a set of low-level application programming interfaces (APIs) for
creating games and other high-performance multimedia applications. It
includes support for high-performance 2-D and 3-D graphics, sound and music,
input, force feedback, multimedia streaming, and network communication for
applications such as multiplayer games.
<<<
<http://msdn.microsoft.com/library/en-us/directx9_c/directx/directx9cpp.asp>

So, you can hardly claim more.  The term "other high-performance multimedia
applications" is a rubberband marketing phrase, so I am sure you are going
to be interpreting it in your favor no matter what I say, so I am just not
saying anything about it.

> Never said a thing about DirectX.

"Don't give me no guff about DirectX... I don't see SGI working it's
tail-off to make OpenGL better, but Microsoft is clamoring to do so because
of their gaming franchise [...]"

Which obviously says (not implies) that OpenGL is no being improved, but
Direct X is.  So you clearly said something in favor of DirectX and in
disfavor of OpenGL.  Anyway, your claim "Never said a thing about DirectX."
is plain wrong...

> And, to your second point, "Do not take anything he says for fact; hardly
> anything is. There is no point to argue on such a level and thus no reason
> to respond to him. Do not take anything he says for fact; hardly anything
> is. There is no point to argue on such a level and thus no reason to respond
> to him." - Thorsten. Pretty hard to take that the right way. Talk about
> your inferences!

Hmm, lets see, earlier in this thread you claimed "to having that fflush
there might help us avoid future bugs. Also, even though the C standard
requires this, experience has shown me that not everybody keeps to the
standard when they write their C compilers (see Visual Studio). To me,
flushing the buffer is kindof like closing a file.".

Honestly, for me to say this isn't a "fact" is about the nicest thing to
say.  The opposite of "fact" can be, depending on the context (law or common
speech) be an "opinion" or "fiction".  However, your claim about fflush and
fclose is indeed best described as pure and indisputable "nonsense".

And the fact that you keep this discussion going also confirms my initial
point.  You didn't want a serious discussion, just a forum to distribute
what you consider "facts".  Yet, I would appreciate you stop making
incorrect claims about things I never said and instead reflect on the amount
of nonsense and irrelevant content compared to valuable content you have
produced or caused up until now in this thread.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> I guess he can be forgiven, then

  I suppose you know how arrogant that kind of expression sounds (no
matter how many smileys you put after it)...

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:401fff62@news.povray.org...
> In article <401fd1cb$1@news.povray.org> , "Dan P"
> <dan### [at] yahoocom> wrote:
> First, I did not say that it is only for games, I only pointed out that
> there are other applications that use 3D graphics than just games.  You
were
> the one who said "Don't give me no guff about DirectX... I don't see SGI
> working it's tail-off to make OpenGL better, but Microsoft is clamoring to
> do so because of their gaming franchise [...]".  So, it was you who
clearly
> said that DirectX is only being heavily developed because of the market
for
> games.

Yes, the gaming market is affecting how much effort Microsoft puts into it
because of how much money it is making them. It is their motivator for
making it good and it will eventually pass OpenGL... EVENTUALLY pass
OpenGL... because of this.

> But lets settle this once and for all, Microsoft is very clear about what
> DirectX is for:
>
> >>>
> Where Applicable
> DirectX is a set of low-level application programming interfaces (APIs)
for
> creating games and other high-performance multimedia applications. It
> includes support for high-performance 2-D and 3-D graphics, sound and
music,
> input, force feedback, multimedia streaming, and network communication for
> applications such as multiplayer games.
> <<<
>
<http://msdn.microsoft.com/library/en-us/directx9_c/directx/directx9cpp.asp>
>
> So, you can hardly claim more.  The term "other high-performance
multimedia
> applications" is a rubberband marketing phrase, so I am sure you are going
> to be interpreting it in your favor no matter what I say, so I am just not
> saying anything about it.

Your own words demonstrate you know, deep down inside, that you're on shaky
ground here because I'm making an "other high-performance multimedia
application". If you knew more about the DirectX API, you'd see that games
is just one of the applications for it.

> > Never said a thing about DirectX.
>
> "Don't give me no guff about DirectX... I don't see SGI working it's
> tail-off to make OpenGL better, but Microsoft is clamoring to do so
because
> of their gaming franchise [...]"
>
> Which obviously says (not implies) that OpenGL is no being improved, but
> Direct X is.  So you clearly said something in favor of DirectX and in
> disfavor of OpenGL.  Anyway, your claim "Never said a thing about
DirectX."
> is plain wrong...

No, no, no, read it -- words have meanings -- I say SGI isn't clamoring, I'm
not saying other people aren't. However, because there is so much
on-the-line for Microsoft, I think DirectX will surpass OpenGL.

> > And, to your second point, "Do not take anything he says for fact;
hardly
> > anything is. There is no point to argue on such a level and thus no
reason
> > to respond to him. Do not take anything he says for fact; hardly
anything
> > is. There is no point to argue on such a level and thus no reason to
respond
> > to him." - Thorsten. Pretty hard to take that the right way. Talk about
> > your inferences!
>
> Hmm, lets see, earlier in this thread you claimed "to having that fflush
> there might help us avoid future bugs. Also, even though the C standard
> requires this, experience has shown me that not everybody keeps to the
> standard when they write their C compilers (see Visual Studio). To me,
> flushing the buffer is kindof like closing a file.".

Still having to nitpick the details, eh?

> Honestly, for me to say this isn't a "fact" is about the nicest thing to
> say.  The opposite of "fact" can be, depending on the context (law or
common
> speech) be an "opinion" or "fiction".  However, your claim about fflush
and
> fclose is indeed best described as pure and indisputable "nonsense".

STDOUT is buffered. I flushed a buffered stream. fflush is for flushing a
buffered stream. Is it so hard to imagine I'd make that decision in that
case, even if the compiler does it itself?

> And the fact that you keep this discussion going also confirms my initial
> point.  You didn't want a serious discussion, just a forum to distribute
> what you consider "facts".  Yet, I would appreciate you stop making
> incorrect claims about things I never said and instead reflect on the
amount
> of nonsense and irrelevant content compared to valuable content you have
> produced or caused up until now in this thread.

You see, that's why I copy and paste what you say instead of summarizing it.
What I consider "facts"... again, debunk these facts, Thorsten. Debunk what
I have said. I don't care about distributing it -- I care about making a
patch editor, but if you're going to claim I'm wrong about the facts
regarding DirectX, then debunk them. Since the best you can do is nitpick
about fflush, something completely unrelated to the argument, I think at
this point you're just trying to save face. It must feel awful to have to
grasp like that. As if one misunderstanding (or even several) about a
complex field like computer programming makes me incompetent and not to be
listened to. It must be tiring to be so perfect, Thorsten.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:402002b7@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
> > I guess he can be forgiven, then
>
>   I suppose you know how arrogant that kind of expression sounds (no
> matter how many smileys you put after it)...

Yes, I do. Golden rule, Warp.

Post a reply to this message

In article <40200575$1@news.povray.org> , "Dan P" 
<dan### [at] yahoocom> wrote:

>> So, you can hardly claim more.  The term "other high-performance
> multimedia
>> applications" is a rubberband marketing phrase, so I am sure you are going
>> to be interpreting it in your favor no matter what I say, so I am just not
>> saying anything about it.
>
> Your own words demonstrate you know, deep down inside, that you're on shaky
> ground here because I'm making an "other high-performance multimedia

Exactly as I predicted...

> application". If you knew more about the DirectX API, you'd see that games
> is just one of the applications for it.

If I wouldn't know as much as I do about DirectX, I couldn't know what you
should, but don't, know about it.

> No, no, no, read it -- words have meanings -- I say SGI isn't clamoring, I'm
> not saying other people aren't. However, because there is so much
> on-the-line for Microsoft, I think DirectX will surpass OpenGL.

At this point in time you still assumed that SGI would be developing OpenGL
and you didn't know until I told you that you were wrong there.  So you
cannot come back later to say what you meant back then was something
different just because of facts you only learnt about later.

>> Hmm, lets see, earlier in this thread you claimed "to having that fflush
>> there might help us avoid future bugs. Also, even though the C standard
>> requires this, experience has shown me that not everybody keeps to the
>> standard when they write their C compilers (see Visual Studio). To me,
>> flushing the buffer is kindof like closing a file.".
>
> Still having to nitpick the details, eh?

No, just that your claim tells me something about your overall knowledge
about what you are talking about or doing.  What it tells me, that is up to
you to guess.

> STDOUT is buffered. I flushed a buffered stream. fflush is for flushing a
> buffered stream. Is it so hard to imagine I'd make that decision in that
> case, even if the compiler does it itself?

Not "even if".  It cannot not write everything o file upon closing a file.
Huge difference, at least if you would know what you initially implied by
claiming it was needed.

> You see, that's why I copy and paste what you say instead of summarizing it.
> What I consider "facts"... again, debunk these facts, Thorsten. Debunk what
> I have said.

You have demonstrated in this thread that you are either unwilling to
understand or incapable of understanding the subject being discussed at all.
For the same reason nobody would argue with a two year old child about the
time it has to go to bed, I am not going to argue with you about any of your
so-called "facts".  You just lack the ability to understand the arguments
because you obviously don't know enough about what I could be telling you.
Thus, arguing with you would only waste my time.

The sooner you realize you don't know what you are talking about the better.
Right now you are only making a bigger fool out of yourself with every new
post:  As you probably have noticed, I am not the only person telling you
this...

> I don't care about distributing it -- I care about making a
> patch editor, but if you're going to claim I'm wrong about the facts
> regarding DirectX, then debunk them. Since the best you can do is nitpick
> about fflush, something completely unrelated to the argument,

It is very much related to the argument: It is related to your knowledge
about programming and computer science in general, because it is such a
fundamental misconception.  To return the the metaphor of children, if you
cannot crawl first, it is unlikely would will be able to walk soon.  Much
less being able to talk about how to walk prior to having done it.  Since
you don't know the basics, you cannot understand the more complex concepts
(like DirectX, which is more complex and stdio), and consequently whatever
you have to say about them will be full of misconceptions.  This in turn
makes it pointless to argue about it with you.

> I think at
> this point you're just trying to save face. It must feel awful to have to
> grasp like that.

Why does a personal insult that is so out of context belong here?

> As if one misunderstanding (or even several) about a
> complex field like computer programming makes me incompetent and not to be
> listened to.

Because you misunderstand very basic aspects, not even about stdio, but
about how something like stdio would (not) have to been specified in order
to allow such arbitrary problems like you suggested would exist.  By pure
logical reasoning you should have been able to deduce that you claim cannot
be correct, and thus you would need to investigate.  That process is called
research, and as you didn't do it, the only conclusion can be that you were
never properly thought how to research in the field of computer science.
Consequently, the lack of your ability to deduce the obvious suggests you
are not competent enough to talk about what you are currently talking about.
This in turn makes it pointless for anybody who has proven him or herself
competent in the same subject area to argue with you about it.

> It must be tiring to be so perfect, Thorsten.

Again, what do these personal insults have to do with anything?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Dan P" <dan### [at] yahoocom> wrote in
news:40200575$1@news.povray.org: 

> 
> No, no, no, read it -- words have meanings -- I say SGI isn't
> clamoring, I'm not saying other people aren't. However, because there
> is so much on-the-line for Microsoft, I think DirectX will surpass
> OpenGL. 
> 

You are entitled to your opinion, but I don't think we will see, DirectX 
for Linux or Mac anytime soon.  IMHO, the industry is shifting back to 
multiple platforms and open standards.  MS is a bit late for the party.  A 
few more quarters like the last few should bring them around.



-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40201623@news.povray.org...
> In article <40200575$1@news.povray.org> , "Dan P"
> <dan### [at] yahoocom> wrote:
>
> >> So, you can hardly claim more.  The term "other high-performance
> > multimedia
> >> applications" is a rubberband marketing phrase, so I am sure you are
going
> >> to be interpreting it in your favor no matter what I say, so I am just
not
> >> saying anything about it.
> >
> > Your own words demonstrate you know, deep down inside, that you're on
shaky
> > ground here because I'm making an "other high-performance multimedia
>
> Exactly as I predicted...

Why thank you. I do make good points, don't I? I can understand why you
didn't want me to mention that point.

> > application". If you knew more about the DirectX API, you'd see that
games
> > is just one of the applications for it.
>
> If I wouldn't know as much as I do about DirectX, I couldn't know what you
> should, but don't, know about it.

And that would be? Oh wait -- I forgot; you don't back up claims.

> > No, no, no, read it -- words have meanings -- I say SGI isn't clamoring,
I'm
> > not saying other people aren't. However, because there is so much
> > on-the-line for Microsoft, I think DirectX will surpass OpenGL.
>
> At this point in time you still assumed that SGI would be developing
OpenGL
> and you didn't know until I told you that you were wrong there.  So you
> cannot come back later to say what you meant back then was something
> different just because of facts you only learnt about later.

If they aren't developing it, why are they retaining the trademark? Keep in
mind that you don't matter; you're just cheap labor to them so you don't
count, a corporate tool, someone who isn't smart enough to use others like
they do. But, that's my OPINION.

> >> Hmm, lets see, earlier in this thread you claimed "to having that
fflush
> >> there might help us avoid future bugs. Also, even though the C standard
> >> requires this, experience has shown me that not everybody keeps to the
> >> standard when they write their C compilers (see Visual Studio). To me,
> >> flushing the buffer is kindof like closing a file.".
> >
> > Still having to nitpick the details, eh?
>
> No, just that your claim tells me something about your overall knowledge
> about what you are talking about or doing.  What it tells me, that is up
to
> you to guess.

Okay...?

> > STDOUT is buffered. I flushed a buffered stream. fflush is for flushing
a
> > buffered stream. Is it so hard to imagine I'd make that decision in that
> > case, even if the compiler does it itself?
>
> Not "even if".  It cannot not write everything o file upon closing a file.
> Huge difference, at least if you would know what you initially implied by
> claiming it was needed.

I think we're having a language barrier. I'm not perfect in my grammar
(hell, I used "right" for "write" in a past message), but this one has left
me stumped. Are you saying that the program can't write everything out to a
file upon closing a file? Huh?

> > You see, that's why I copy and paste what you say instead of summarizing
it.
> > What I consider "facts"... again, debunk these facts, Thorsten. Debunk
what
> > I have said.
>
> You have demonstrated in this thread that you are either unwilling to
> understand or incapable of understanding the subject being discussed at
all.

I'm still WAITING for your to debunk the simple truths, regardless of how
much you don't like them.

> For the same reason nobody would argue with a two year old child about the
> time it has to go to bed, I am not going to argue with you about any of
your
> so-called "facts".  You just lack the ability to understand the arguments
> because you obviously don't know enough about what I could be telling you.
> Thus, arguing with you would only waste my time.

Uh huh. I don't understand baby-babbling either. Does that mean the baby is
competent? Or does that mean the baby doesn't know what he's babbling on
about? Hell, I'm not even asking you to argue; just acknowledge that you
were wrong in saying that most of what I say doesn't have worth. I'm not
perfect, but pal, neither are you, and I'm surprised you know anything at
all given how much you think you know everything already. Where was your
compulsion to learn?

> The sooner you realize you don't know what you are talking about the
better.
> Right now you are only making a bigger fool out of yourself with every new
> post:  As you probably have noticed, I am not the only person telling you
> this...

No, you are one of two people who are both arrogant (actually, three,
counting me). I happen to still respect Warp, however, since he knows how to
back up his claims instead of trying to deflect like a coward.

> > I don't care about distributing it -- I care about making a
> > patch editor, but if you're going to claim I'm wrong about the facts
> > regarding DirectX, then debunk them. Since the best you can do is
nitpick
> > about fflush, something completely unrelated to the argument,
>
> It is very much related to the argument: It is related to your knowledge
> about programming and computer science in general, because it is such a
> fundamental misconception.  To return the the metaphor of children, if you
> cannot crawl first, it is unlikely would will be able to walk soon.  Much
> less being able to talk about how to walk prior to having done it.  Since
> you don't know the basics, you cannot understand the more complex concepts
> (like DirectX, which is more complex and stdio), and consequently whatever
> you have to say about them will be full of misconceptions.  This in turn
> makes it pointless to argue about it with you.

LOL -- you once again say that I have fundamental misconceptions and then go
on to some empty insult. Man, I'm starting to enjoy this little tiff; you
make me laugh. Unfortunately, since I haven't yet seen you back up your
insults to me, it's just amusing noise. You sure do have your insults down,
I have to say, and I'm not too surprised since when you can't walk the walk,
you gotta talk I guess.

> > I think at
> > this point you're just trying to save face. It must feel awful to have
to
> > grasp like that.
>
> Why does a personal insult that is so out of context belong here?

Oh... oh you feel insulted by that sentence? Have you ever read your own
text as if you wrote it to yourself?

> > As if one misunderstanding (or even several) about a
> > complex field like computer programming makes me incompetent and not to
be
> > listened to.
>
> Because you misunderstand very basic aspects, not even about stdio, but
> about how something like stdio would (not) have to been specified in order
> to allow such arbitrary problems like you suggested would exist.  By pure
> logical reasoning you should have been able to deduce that you claim
cannot
> be correct, and thus you would need to investigate.  That process is
called
> research, and as you didn't do it, the only conclusion can be that you
were
> never properly thought how to research in the field of computer science.
> Consequently, the lack of your ability to deduce the obvious suggests you
> are not competent enough to talk about what you are currently talking
about.
> This in turn makes it pointless for anybody who has proven him or herself
> competent in the same subject area to argue with you about it.

I just love it when people try to sound smart to cover up their
incompetence. Perhaps you can try out for a spot on Fraiser? First off, I
did NOT know that I did not have to fflush stdio and never said I did. In
fact, I thanked Warp for teaching me that. Now, Thorsten, this is called
learning from others and acknowledging their help. Appreciating them. This
is a tough concept for you, I can tell, since everything I say you get
defensive over. What are you hiding, Thorsten? Are you hiding that you don't
know everything either? Or are you worried that I might no something you
don't? So far, I see no evidence to the contrary; just lots of empty,
unsubstantiated claims that I'm some sort of child. But, it is funny though.
I haven't been on a newsgroup like this since the mid-nineties and I forgot
that there are people like you.

> > It must be tiring to be so perfect, Thorsten.
>
> Again, what do these personal insults have to do with anything?

Can you /imagine/ if I answered your postings like you are answering mine?
I'd be saying that every sentence! So, so very fragile you are. It is so
sad. I hope you get better and, although I'm sure nobody will believe this,
I really hope you get better. It must be very difficult and lonely being a
God of All That Is Computer, Thorsten.

If it helps, I forgive you, for I realize you have some growing to do and
when you're ready, I'm here for you.

Post a reply to this message