slc@hoptoad.UUCP (05/01/87)
I'm trying to convert a number of small (20 by 20), low-res, IFF brush files from DPaint II, into c source files, using Mike Farren's GI program. The files all end up with exactly the same data! Also, the color map is definitely wrong, saying that certain colors are missing, even when I create a brush that uses all 32 colors. Has the brush file format changed from DPaint I to DPaint II? Or can anybody shed some light on what is going on here?
tenney@well.UUCP (05/01/87)
I remember a program (ILBMDUMP I think) that was included on the
IFF disk (one of the fish disks, #16 if I recall) that takes an
IFF file and writes out a C program. I've recently used a modified
version of it with both versions of DPaint aok.
-- Glenn Tenney
UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney
ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY
As Alphonso Bodoya would say... (tnx boulton)
Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!ewhac@well.UUCP (05/01/87)
In article <2972@well.UUCP> tenney@well.UUCP (Glenn S. Tenney) writes: >I remember a program (ILBMDUMP I think) that was included on the >IFF disk (one of the fish disks, #16 if I recall) that takes an >IFF file and writes out a C program. I've recently used a modified >version of it with both versions of DPaint aok. > You're right, 'ILBMDump' is on Fish Disk #16. It also doesn't work as documented. 'ILBMDump' works great for creating BOB source files, but totally barfs when you ask it to create source structures for sprites. I stared at the code (which looked valid), but never could figure out what was wrong. I guess it was a compiler bug (what do you expect from Lettuce? :-) ). This was extremely disappointing as it was the first tool I tried to use when creating the sprite imagery for Robotroff. I ended up hacking on Mike Farren's 'gi' program. I guess EA loses again. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."
farren@hoptoad.UUCP (05/01/87)
In article <2078@hoptoad.uucp> slc@hoptoad.UUCP (Steve Costa) writes: > >I'm trying to convert a number of small (20 by 20), low-res, IFF brush >files from DPaint II, into c source files, using Mike Farren's GI program. >The files all end up with exactly the same data! Also, the color map is >definitely wrong, saying that certain colors are missing, even when I >create a brush that uses all 32 colors. > >Has the brush file format changed from DPaint I to DPaint II? Or can >anybody shed some light on what is going on here? > gi makes a whole lot of unwarrented assumptions about the way a brush file looks. It sounds, from the symptoms, like DPaint II has added some additional chunks to the beginning of the files, and this would cause gi to lose it in a big way. When I get my hands on DPaint II, I would be pleased to modify gi so that it'll work with DPaint II brushes as well as the originals (I've been thinking about slicking it up anyhow, so wotthehell...). If and when this happens, I'll be sure and post it. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
slc@hoptoad.uucp (Steve Costa) (05/01/87)
I used NEWZAP to look at the hex data for my DPaint II brushes, and discovered that the "BODY" label was 64 bytes farther on than gi expected. So, I changed gi.c to fseek() 64 bytes further and re-compiled it; it seems to work. Sounds simple in retrospect, but it was unknown territory for me. It's not generalized, but it will work for my purposes.
mike@ames.UUCP (Mike Smithwick) (05/01/87)
[Atari?? Just say no!] In article <2078@hoptoad.uucp> slc@hoptoad.UUCP (Steve Costa) writes: > >I'm trying to convert a number of small (20 by 20), low-res, IFF brush >files from DPaint II, into c source files, using Mike Farren's GI program. >The files all end up with exactly the same data! Also, the color map is >definitely wrong, saying that certain colors are missing, even when I >create a brush that uses all 32 colors. > >Has the brush file format changed from DPaint I to DPaint II? Or can >anybody shed some light on what is going on here? I had the same problem. Apparently the format is different than DPaint One brushes, so I hope you didn't chuck your earlier disk!! Yoshould be able to take your DPII brushes, bring them up under DPI, save them again, and get the right format. -- *** mike (powered by M&Ms) smithwick *** "ever felt like life was a game, and someone gave you the wrong instruction book?"
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) (05/02/87)
In article <2078@hoptoad.uucp> slc@hoptoad.UUCP (Steve Costa) writes: > >I'm trying to convert a number of small (20 by 20), low-res, IFF brush >files from DPaint II, into c source files, using Mike Farren's GI program. >The files all end up with exactly the same data! Also, the color map is >definitely wrong, saying that certain colors are missing, even when I >create a brush that uses all 32 colors. > >Has the brush file format changed from DPaint I to DPaint II? Or can >anybody shed some light on what is going on here? I checked out brush files from both DPaint and DPaint II. DPaint II brushes contain CRNG (color cycling) chunks, DPaint brushes do not. This should not bother a correctly written IFF reader because that's what IFF is all about. IFF readers are supposed to just skip chunks they don't care about or don't understand. It sounds like GI is not doing this, but rather is making assumptions about the order and position of the chunks it is interested in. The IFF disk contains a utility called ILBMDump which converts a brush to a C source file. But it only writes out source for the image data, not for the colormap. The source is provided and could be modified to handle additional chunks. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) (05/06/87)
In article <2082@hoptoad.uucp> slc@hoptoad.UUCP (Steve Costa) writes: > >I used NEWZAP to look at the hex data for my DPaint II brushes, and >discovered that the "BODY" label was 64 bytes farther on than gi expected. >So, I changed gi.c to fseek() 64 bytes further and re-compiled it; it seems >to work. Sounds simple in retrospect, but it was unknown territory for me. > >It's not generalized, but it will work for my purposes. I'm glad you found a quick fix for yourself, even though it makes me CRINGE to see IFF files handled in such an incompatible way. Now PLEASE listen, everybody: It's not that hard to write a cheap chunk-oriented IFF reader. You don't even need the IFF modules. I've even written one in Basic. If you don't use the IFF modules, it may not be TOTALLY compatible but it will at least be able to handle FILES WITH EXTRA CHUNKS ! --------------------------------------------------------------------------- It's very simple: 1. Open the file 2. Make sure the first ULONG is "FORM" 3. Make sure the third ULONG is "ILBM" (or whatever FORM you want) LOOP UNTIL EOF: (You have 2 ULONG variables, ChunkID and ChunkLen) { 4. Read next ULONG into ChunkID, Read following ULONG into ChunkLen (Using switch statement on ChunkID or a bunch of if-elseif-elseif's) 5. Is this a chunk I want ? YES: Read the WHOLE chunk and do what you want. NO: Seek ChunkLen number of bytes EITHER YES OR NO: If ChunkLen is odd, Seek 1 byte (Now you are now positioned at the next ChunkID or EOF) } -------------------------------------------------------------------------- This type of reader will give a moderate amount of cross-application and cross-version compatibility to simple utilities which operate on IFF files. It is NOT intended for commercial applications ! This simple reader does NOT follow all of the IFF rules or handle all of the permutations of IFF files. But it WILL allow utilities like "gi" to find the chunks they need REGARDLESS of what additional chunks are in the FORM. So please, take a little extra time and write code that will last. --------------------------------------------------------------------------- The preceding was a public service message from the IFF POLICE !!!!!! (Hardcoding Seeks on IFF Files ???? Go ahead... Make my day.) BLAAAAMMMMMMMM ! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
farren@hoptoad.UUCP (05/06/87)
In article <1836@cbmvax.cbmvax.cbm.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) writes: > So please, take a little extra time and write code that will last. >--------------------------------------------------------------------------- >The preceding was a public service message from the IFF POLICE !!!!!! > (Hardcoding Seeks on IFF Files ???? Go ahead... Make my day.) > BLAAAAMMMMMMMM ! When I did gi, it was a quick and dirty utility designed to do a quick and dirty job, which it did quite nicely. Considering that this was long before Fish #1, and the only docs I had on IFF files at all were a couple of Xeroxed sheets that said, basically, "There are chunks. They have names. An ILBM header looks like this: ", I refuse to apologize for what I did way back in the stone age, 'specially since it has helped so many others out along the way. Lighten up. I am now considering rewriting gi, to add in all of the nifty little things people have been asking for, and the ones I want to put in. What I have in mind for improvements right now are: 1. The ability to see what your image will look like with an arbitrary color set, after the bit-plane transformations have been done. 2. The ability to setup your image as sprites, with output of the appropriate structures for sprites. 3. The ability to transform an entire screen into data, so that back- grounds and such can be incorporated right into your routine. Mostly useful for title pages, etc. 4. The ability to have gi produce a directly linkable object file, so you don't have to wait for interminably long compiles of images. 5. The ability to read arbitrary IFF files (there. see? I ain't iggorant.) 6. A full intuition interface, much easier to use. Anything else you'd like? Please let me know. All good suggestions will be incorporated. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"