Xref: utzoo comp.lang.c:25910 comp.lang.c++:6467 comp.sys.ibm.pc:44415
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!mit-eddie!apollo!nelson_p
From: nelson_p@apollo.HP.COM (Peter Nelson)
Newsgroups: comp.lang.c,comp.lang.c++,comp.sys.ibm.pc
Subject: Zortech problems
Message-ID: <48a441bf.20b6d@apollo.HP.COM>
Date: 14 Feb 90 16:48:00 GMT
Sender: root@apollo.HP.COM
Distribution: usa
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 68



   A while back I posted a question about allocating large 2
   dimensional arrays AND ACCESSING THEM AS 2 DIMENSIONAL
   ARRAYS.   Specifically, I wanted to allocate a number of
   2d arrays in which no individual array would exceed 64K
   but the total for all of them would exceed 64K.

   Compilers which support the 'huge' memory model, like 
   Microsoft's have no problem with this ....

   char array1[200][200]
   char array2[200][200]

                                             
   The Zortech runs out of memory with this.  Of course you
   can work around it by mallocating the space.  If you want
   to retain something like the desired data structure you can 
   mallocate a row of pointeres to columns of 1d arrays, etc, etc.
   But why does Zortech make you go to this trouble?

   Anyway, I've run into some other problems too:

   My application involves Cellular Automata.   Such programs 
   run for hours in graphics mode.   I also have fractal programs
   that run for a long time.   

   What if I have a 1-hour program that I want to stop after 5 
   minutes because I don't like the way it's turning out?   I could
   type Break or ctrl-C except that once Zortech enters graphics
   mode it disables this feature!  And, as far as I can tell, none
   of the "get" string or character functions (getc, getch, etc)
   Zortech supplies will return without *waiting for a keystroke*,
   so I can't write a routine which periodically checks to see if
   anyone has typed "quit" or something from the keyboard.  I imagine
   there must be some DOS call that can fix this.   But why does
   Zortech create the need to find a workaround in the first place?
   Zortech itself had no helpful suggestions on this either except to 
   reboot the machine (gee, thanks) but one of their experts is 
   going to take a closer look at this issue.

   An even more glaring problem is the apparent lack of any way
   to output text in graphics mode!!!  I was so surprised when I 
   saw this that I called the Zortech office to make sure.  They 
   confirmed it: there is no way to put text on the screen with their
   "improved" Flash Graphics package.    I'v been in the computer
   graphics biz since 1982 and I've never seen a graphics package 
   or set of graphics library calls that didn't offer some rudimentary
   text capability!   Even my $70 QuickC can output text in graphics
   mode!   

   Finally, I tried running one of my programs, which ran just fine
   on my own Hercules monochrome display, on a friend's 286 system
   with a Paradise VGA card.  Zortech sez that at fg_init time they
   check to see what kind of graphics card is present and set up
   to output to that.  No such luck.  The software mangled the timing
   of the VGA display and outputted ca-ca.   I called Zortech and they
   suggested there was something wrong with the card.   My friend has
   two kids and LOTS of game sofware and has never had any other problems.

   I've only used a tiny subset of Zortech's C and C++ and library
   features and I'm dismayed at the number of problems I've already
   found.   Right now Zortech is the only game in town for C++ on a PC. 
   But when Microsoft and Borland release their long-awaited products
   Zortech runs a serious risk of being completely blown away if it
   doesn't clean up its act fast.   

                                                  ---Peter