[comp.binaries.ibm.pc.d] Wacky results from "dbwrendr"

rds95@leah.Albany.Edu (Robert Seals) (02/17/89)

Well, I got the recently posted "dbwrendr" aka "ray" and "tmp2gif"
and everything unpacked fine and stuff, and it runs... kinda.

After computing around 200 scan lines, the program terminates, apparently
normally. Then when using "tmp2gif" the bottom half of the picture is just
a repeat of the last scan line; I presume this is because of the
Amiga's 400 scan lines. So what's the scoop?

rob

labc-4dc@web-3g.berkeley.edu (Erik Talvola) (02/17/89)

In article <1575@leah.Albany.Edu> rds95@leah.Albany.Edu (Robert Seals) writes:
>Well, I got the recently posted "dbwrendr" aka "ray" and "tmp2gif"
>and everything unpacked fine and stuff, and it runs... kinda.
>
>After computing around 200 scan lines, the program terminates, apparently
>normally. Then when using "tmp2gif" the bottom half of the picture is just
>a repeat of the last scan line; I presume this is because of the
>Amiga's 400 scan lines. So what's the scoop?



If you look in the documentation concerning TMP2GIF, you will find that it
normally expects a 320x400 line image.  It then skips every other line to
get the final 320x200 GIF picture.  All of the sample files on the disk are
set up to be 320x200 resolution originally however.  If you run TMP2GIF with
a "-2" option (I think), it won't skip the lines and you will have the full
image.

--
Erik Talvola               | "It's just what we need... a colossal negative 
labc-4dc@web.berkeley.edu  | space wedgie of great power coming right at us
c164-2bf@bard.berkeley.edu | at warp speed." -- Star Drek

nanook@novavax.UUCP (Keith Dickinson) (02/17/89)

in article <1575@leah.Albany.Edu>, rds95@leah.Albany.Edu (Robert Seals) says:
> 
> Well, I got the recently posted "dbwrendr" aka "ray" and "tmp2gif"
> and everything unpacked fine and stuff, and it runs... kinda.
> 
> After computing around 200 scan lines, the program terminates, apparently
> normally. Then when using "tmp2gif" the bottom half of the picture is just
> a repeat of the last scan line; I presume this is because of the
> Amiga's 400 scan lines. So what's the scoop?
> 
> rob

Rob,
  You were trying to convert a picture that was only 200 scan lines tall.The
convert program defaults to 400 lines. It will trash every other line to
pack 400 lines into 200. This also causes the last line in the real image
to be repeated for half of the screen.

  Try running tmp2gif with the '-2' command line option. That should fix
it!

Keith Dickinson
--
_   /|  | Fidonet  : 369/2 [(305) 421-8593] Brave Mew World South
\'o.O'  | Internet : nanook@muadib.FIDONET.ORG
=(___)= | UUCP     : (novavax,hoptoad!ankh,muadib)!nanook
   U    | USNail   : 433 SE 13th CT. J-202, Deerfield Beach, Fl. 33441
  Ack!  | Disclamer: This message was created by a faulty AI program.
Don't blame me...I voted for Bill'n'Opus in '88

malloy@nprdc.arpa (Sean Malloy) (02/17/89)

In article <1575@leah.Albany.Edu> rds95@leah.Albany.Edu (Robert Seals) writes:
>Well, I got the recently posted "dbwrendr" aka "ray" and "tmp2gif"
>and everything unpacked fine and stuff, and it runs... kinda.
>
>After computing around 200 scan lines, the program terminates, apparently
>normally. Then when using "tmp2gif" the bottom half of the picture is just
>a repeat of the last scan line; I presume this is because of the
>Amiga's 400 scan lines. So what's the scoop?

When in doubt, RTFM. The file TMP2GIF.MAN explicitly states that the
program converts a 320x400 .TMP file into a 320x200 GIF file by
throwing away alternate lines. With 100 lines to fill, and no new
lines to read, the program just repeats the last scan line. However,
if your input .TMP file is already 320x200, the manual says to use the
invocation 'TMP2GIF -2 <file>' which tells TMP2GIF that the input is
only 200 lines high, so don't drop alternate lines.


	Sean Malloy
	Navy Personnel Research & Development Center
	San Diego, CA 92152-6800
	malloy@nprdc.navy.mil

troy@arthur.uchicago.edu (Troy Zerr) (02/18/89)

In article <1575@leah.Albany.Edu> rds95@leah.Albany.Edu (Robert Seals) writes:
>Well, I got the recently posted "dbwrendr" aka "ray" and "tmp2gif"
>and everything unpacked fine and stuff, and it runs... kinda.
>
>After computing around 200 scan lines, the program terminates, apparently
>normally. Then when using "tmp2gif" the bottom half of the picture is just
>a repeat of the last scan line; I presume this is because of the
>Amiga's 400 scan lines. So what's the scoop?
>
>rob
The summary says it all . . . 

QUESTION QUESTION QUESTION QUESTION
Is there someplace where I can get some .TMP files?  I'm working on a program
to display the files on an EGA in 640x350 mode by dithering the 320x200 .tmp
file to get an effective resolution of 64 colors or 48 shades of gray.  Running
a bunch of test files through my computer just takes too long.  Please
email any responses to

Troy Zerr
Troy@zaphod.uchicago.edu

csd@drutx.ATT.COM (DavisCS) (02/18/89)

In article <1575@leah.Albany.Edu>, rds95@leah.Albany.Edu (Robert Seals) writes:
...
> After computing around 200 scan lines, the program terminates, apparently
> normally. Then when using "tmp2gif" the bottom half of the picture is just
> a repeat of the last scan line; I presume this is because of the
> Amiga's 400 scan lines. So what's the scoop?
> 
> rob

Did you use the -2 option with "tmp2gif"? I tried it out and it worked for me.
I have an EGA with 640x350 resolution. However, the picture was pretty fuzzy
even though the program computed all points and guessed at nothing. So far, I
am assuming the fuzziness is due to computing the picture at 320x200 resolution
and then expanding to 640x400 (or 640x350?).

I have seen a few ray traced pictures in GIF format on BBS' that have pretty
good resolution (the gif's not the BBS'). A couple are named with some some
variation of "ball" and one is called "emrldcty.gif". Anybody know the source of
these creations?

Scott

akk2@uhura.cc.rochester.edu (Atul Kacker) (02/18/89)

I have used the dbwrender program and the accompanying tmp2gif program
quite succesfully, except the GIF file that gets created isn't right.
It is only about 2-3 thousand bytes in size and my GIF viewers don't
read them.  The screen image looks just fine.  Is there some magic
incantation that I need to do to get a good GIF file on disk?

Thanks,
-- 
Atul Kacker  |     Internet: akk2@uhura.cc.rochester.edu
             |     UUCP: {ames,cmcl2,decvax,rutgers}!rochester!ur-cc!akk2
-------------------------------------------------------------------------------

troy@zem.uchicago.edu (Troy Zerr) (02/18/89)

In article <884@ur-cc.UUCP> akk2@uhura.cc.rochester.edu (Atul Kacker) writes:
>I have used the dbwrender program and the accompanying tmp2gif program
>quite succesfully, except the GIF file that gets created isn't right.
>It is only about 2-3 thousand bytes in size and my GIF viewers don't
>read them.  The screen image looks just fine.  Is there some magic
>incantation that I need to do to get a good GIF file on disk?

1. Remember the -2 flag on the tmp2gif command.

2. What Gif Viewer depends on what display card you have.  PICEM ought to
work for VGA, since tmp2gif produces 320x200x256 pictures.  PICEM
won't work for the EGA since it doesn't know how to crunch 256 colors
into 16.

   If you have EGA, use CSHOW, from COMPUSERVE.  It can give you a
320x200x16 approximation.  However, expect it to look awful -- the
low resolution coupled with fewer colors wastes much of the picture
data.  CSHOW  (at least the version I have) won't do VGA modes.

   As I mentioned before, I'm working on a program to dither the
image.  I have an analog monochrome monitor, and I can get 48 shades
of gray out of it and it looks great.  One ought to get 64 colors from
a color monitor by using a similar dithering scheme, but obviously it 
would be hard for me to test on my system.

     If you have a CGA or Hercules card, don't bother.

If you do go through the trouble of calculating one of these beasts,
you owe it to yourself to see them on a color VGA.  They are REALLY NEAT.

Best of luck

Troy Zerr

marks@tekigm2.MEN.TEK.COM (Mark D. Salzman) (02/24/89)

For anyone that hasn't already figgured this out, it seems that the byte
ordering for the output file is backwards from the way TMP2GIF expects it
to be when done on a PC. I found the best results using both the -r and -2
switches as such:
			tmp2gif -2 -r <filename>

The only time you don't need these switches is when the .tmp file is done
on an Amiga or other machine with correct byte order.

Hope this helps.

-- 
Mark D. Salzman     Phone (206) 253-5542.  |  The more complex the mind,
Tektronix Inc., P.O. Box 3500, M/S C1-936  |  the greater the need for 
Vancouver, Washington. 98668               |  the simplicity of play.
{world_at_large}!tektronix!tekigm2!marks   |       James T. Kirk