POV-Ray : Newsgroups : povray.general : My 3.1e unofficial ATARI problem Server Time
2 Nov 2024 13:21:36 EDT (-0400)
  My 3.1e unofficial ATARI problem (Message 1 to 3 of 3)  
From: LE COAT Francois
Subject: My 3.1e unofficial ATARI problem
Date: 24 Mar 1999 03:54:43
Message: <36F8A917.83887EC9@ief.u-psud.fr>
Hello Everybody,

I compiled 3.1e version for ATARI platforms. But I have a problem.
When I generate PPM format, the R and B channel of the image seems
to be inverted. I looked at the ppm.c source code, and I can't
find the error. I precise that I used 3.1e for UNIX/LINUX and that
I use GCC 2.8.1. The all seems to work correctly. Maybe you have
a solution ... ATARI has 68k processors, and it's Big Endian.
Maybe the 3.1e version was adapted from 3.10 for DOS, and it
remains problems of Little Endian Intel's way. Can you help me ?

Thanks,

Regards,

-- Francois LE COAT
Author of Eureka 2.12 (2D Graph Describer 3D Modeller)
WEB : http://eureka.atari.org


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: My 3.1e unofficial ATARI problem
Date: 24 Mar 1999 10:51:45
Message: <36f90a11.0@news.povray.org>
In article <36F8A917.83887EC9@ief.u-psud.fr> , LE COAT Francois 
<lec### [at] iefu-psudfr>  wrote:

> I compiled 3.1e version for ATARI platforms. But I have a problem.
> When I generate PPM format, the R and B channel of the image seems
> to be inverted. I looked at the ppm.c source code, and I can't
> find the error. I precise that I used 3.1e for UNIX/LINUX and that
> I use GCC 2.8.1. The all seems to work correctly. Maybe you have
> a solution ... ATARI has 68k processors, and it's Big Endian.
> Maybe the 3.1e version was adapted from 3.10 for DOS, and it
> remains problems of Little Endian Intel's way. Can you help me ?

Hmm, I have never seen this behaviour on a Macintosh for both 68K and
PowerPC versions. In general there is no (known) code in POV-Ray that
requires adjustment for Endianes or has problems with it.
Maybe your C library allows only output of 7 bit characters? However, then
the other output formats shouldn't work either. Are you sure the program
that views the image works correctly? In case you don't have another program
to view the PPM I would suggest to post a small image that shows the problem
for you in the povray.binaries.images group and ask there is someone can
check it out.


    Thorsten


Post a reply to this message

From: LE COAT Francois
Subject: Re: My 3.1e unofficial ATARI problem
Date: 25 Mar 1999 03:14:53
Message: <36F9F142.3731E1BB@ief.u-psud.fr>
Hello,

Thorsten Froehlich wrote:
> 
> In article <36F8A917.83887EC9@ief.u-psud.fr> , LE COAT Francois
> <lec### [at] iefu-psudfr>  wrote:
> 
> > I compiled 3.1e version for ATARI platforms. But I have a problem.
> > When I generate PPM format, the R and B channel of the image seems
> > to be inverted. I looked at the ppm.c source code, and I can't
> > find the error. I precise that I used 3.1e for UNIX/LINUX and that
> > I use GCC 2.8.1. The all seems to work correctly. Maybe you have
> > a solution ... ATARI has 68k processors, and it's Big Endian.
> > Maybe the 3.1e version was adapted from 3.10 for DOS, and it
> > remains problems of Little Endian Intel's way. Can you help me ?
> 
> Hmm, I have never seen this behaviour on a Macintosh for both 68K and
> PowerPC versions. In general there is no (known) code in POV-Ray that
> requires adjustment for Endianes or has problems with it.
> Maybe your C library allows only output of 7 bit characters? However, then
> the other output formats shouldn't work either. Are you sure the program
> that views the image works correctly? In case you don't have another program
> to view the PPM I would suggest to post a small image that shows the problem
> for you in the povray.binaries.images group and ask there is someone can
> check it out.

In fact I discovered the bug. PPM is a UNIX file format. It begins with
texts information lines, and is followed by raw RGB image data. In fact
when in ppm.c my compiler (GCC) finds :
fprintf(fp,"P6\n");
that is the first magic identification of PPM files, it wrote to file
carriage return ('\015') followed by line feed ('\012'). Because PPM
is a UNIX file format, only CR should be written. Because there's a
LF after CR, it is interpreted as part of the RAW data. When I read
the file produced by POV, all the raw data are shifted. The portable
way of writing the previous C line would be :
fprintf(fp,"P6\015");
I suspect that the problem I encountered is not a specific 68k problem,
but it occurs on DOS versions, with DOS friendly compilers. It should
also occurs on MACS, because the control character is line feed
('\012').

Anyway, I corrected the ppm.c file, and the POV 3.1e PPM export is
now correct. Thanks for your suggestions. I verified that my viewers
(I have two) are correct.

Thanks for all,

Regards,

-- Francois LE COAT
Author of Eureka 2.12 (2D Graph Describer 3D Modeller)
WEB : http://eureka.atari.org


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.