mark@unisec.usi.com (Mark Rinfret) (07/10/87)
I was going to email this to Leo Schwab and let him post it, but I just got mail returned to me that I sent to him last week, so to expedite things... First, thanks for EHB - unfortunately, I don't have it, but at least now I know. What this posting is really about is a bug I discovered in Leo's rendition of the IFF reader. I found that when attempting to display a DPaint II brush that was created in 640 x 200 mode, it was displayed in 320 x 200 mode, kinda' like a picture on a baloon being stretched :-). Your "fix" for resolution, based on bmhd.w and bmhd.h, was a little kludgy but worked if the threshhold was adjusted downward. I decided to read the docs to find out what was available and discovered pageWidth and pageHeight in the BitMapHeader structure. Use of these (and printing their values), revealed an erroneous definition in the file "myiff.h". You've defined xAspect and yAspect as UWORD. They should be UBYTE. This caused improper offsets for the pageWidth and pageHeight fields. Once this was corrected, and using pageWidth and pageHeight to set the correct viewport -> Modes value allowed me to display the 640 x 200 brush correctly. Thanks for the contribution(s)! In response to your solicitation for comments regarding your code, I would say that I have only a couple of minor gripes. Your definitions of the IFF stuff change the capitalizations for the definitions. Changing your source, while reading the official documentation led to a short spell of confusion. If you want to adopt your own conventions, that's fine, but stuff originated elsewhere and used by a wide audience is best left as is. Also (from memory, now), some of your variable names are a little less than meaningful. One that comes to mind is "so_far" which might better be named "data_remains" or "bytes_left" (I'm not throwing rocks - I live in a glass house too.) Of course, I like 4 character tabs, but that horse has already been beat to death. ...turning my head to face the crowd... My reason for resurrecting Leo's reader was to see if I could easily (an hour or less) hack it to get it to generate C source code from DPaint brushes. You already know where I spent my (precious) hour. I've grabbed a couple of these (executable only) from BBS's but they didn't even run. If someone has source for such a tool, would you email me a copy? Thanks. Mark -- | Mark R. Rinfret, SofTech, Inc. mark@unisec.usi.com | | Guest of UniSecure Systems, Inc., Newport, RI | | UUCP: {gatech|mirror|cbosgd|uiucdcs|ihnp4}!rayssd!unisec!mark | | work: (401)-849-4174 home: (401)-846-7639 |
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (07/15/87)
In article <1020@unisec.usi.com> mark@unisec.usi.com (Mark Rinfret) writes: > What this posting is really about is a bug I discovered in Leo's >rendition of the IFF reader. [ Goes on to describe bug. ] > Oops! I tried to be careful. Sigh. > My reason for resurrecting Leo's reader was to see if I could easily >(an hour or less) hack it to get it to generate C source code from DPaint >brushes. You already know where I spent my (precious) hour. [ ... ] I trust that my code was easier to deal with than EA's, which was the whole point. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor