Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Graphics
Message-ID: <306.UUL1.3#5129@willett.UUCP>
Date: 21 Jan 90 13:47:49 GMT
Organization: Latest Link in ForthNet Chain (Pittsburgh, PA)
Lines: 54


 Date: 01-21-90 (02:15)              Number: 1718 (Echo)
   To: MARK SMILEY                   Refer#: 1710
 From: MIKE SPERL                      Read: NO
 Subj: GRAPHICS                      Status: PUBLIC MESSAGE

 Mark,

     Thank you for the upload.  My suggestions are being uploaded 
 as the file brecall.zip for your testing and use.  We were on the 
 same track regarding our ideas and methods, so much of what is in 
 the file is just another approach to what you've done; thought you
 might like to see it, anyway.  It seems to work with test screens 
 and with the landscape program.

     I tried to make a large buffer unsuccessfully, so then I made
 small buffers, but only had memory enough for two.  No good.  The
 compression will have to solve the buffer problem, I guess.  If
 you can figure out a way to make a buffer large enough to hold 
 four bit planes, then we can address the buffer in the same manner 
 that F-PC addresses lists, which would not require the time for 
 compression, and the latter could be postponed to file writing 
 time. 

     In landscape I used a file temp.$$$ to hold the screen image 
 for recall.  It could be renamed for permanent saving.  Most users
 can supply disk space; I used my 2Mbyte ramdisk, which makes it 
 very fast.  I'd hate to wait for a floppy!  You might consider 
 oonly compressing files for saving; that way the program runs 
 faster.

     Re: forth faster than C?  That would seem to depend on 
 programming sstyle.  Nest is the big bottleneck in forth, so 
 decomposing words into smaller words is to be avoided.  This is a 
 good technique for development and debugging, but after code is 
 running it's a good idea to combine words that fit well into a 
 single process, just as we did in the case of the lines.  It's
 been said that forth is made up of lots of small words, and that's 
 fine for the kernel, where most of them are called by next rather 
 than nest because they're in assembler, and those that aren't are 
 so valuable and general there's no choice.  But any small word 
 should stand on its own, and not be simply a part of another.
 I feel that the main object in optimizing forth is the elimination
 of next, and assembler words should be written for that purpose
 as well as eliminating the numerous pushes and pops and >r's in
 stack manipulations.

     The inline code in (bsave) and (brecall) in the upload is an
 example of this philosophy.  ;-)

     - Mike -
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'