john13@garfield.MUN.EDU (John Russell) (10/16/88)
I was looking at a display using a custom copperlist, and it occurred to me it was a shame the picture could not be displayed that way from any other program. So I thought, why not? Why not create an IFF chunk which would contain a specialized copperlist? Obviously it would be Amiga-specific, but the bitmap data could still be manipulated by any IFF cognizant program on any system. Would anyone like to comment on the feasability of this scheme, and if so what would be a good way to store the information in a file? I've no experience with copperlists myself. Also nice would be a way to store fragments of code in a picture file, say to deal with a special compression format. I can think of some nifty applications for that sort of thing (maybe pictures that could auto-convert themselves from other formats?). Would it be possible to store object code in the middle of the picture file, send it to its own temporary file in ram:, and then loadseg and execute that? John -- "The 68000 processor can't possibly handle a colour display. You must have a 68020 system and not know it." -- Amiga and Atari ST owners shared a chuckle over this view from sales *and* technical people at the local Apple dealer
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/17/88)
In article <4937@garfield.MUN.EDU> john13@garfield.MUN.EDU (John Russell) writes: >I was looking at a display using a custom copperlist, and it occurred to me >it was a shame the picture could not be displayed that way from any other >program. So I thought, why not? Why not create an IFF chunk which would >contain a specialized copperlist? Obviously it would be Amiga-specific, but >the bitmap data could still be manipulated by any IFF cognizant program on >any system. > This is probably not a good idea because it violates the IFF rule of portability. Copperlists, or a method of describing copperlists, is inherently non-portable. Not all machines have hardware registers to report where the video beam is on-screen, so duplicating the displayable image on foreign hardware would be difficult to impossible. Sure you can edit the bitmap, but since the copperlist is inextricably tied to the layout of the bitmap, this may not buy you much. And before you say it, CAMG *is* portable. It describes additional information about what the image looks like, and how it was stored. HAM pictures can be decoded on foreign hardware, as well as HALFBRIGHT pictures. The HIRES and LACE bits also say something about what the picture looks like. So CAMG is portable. >Also nice would be a way to store fragments of code in a picture file, say to >deal with a special compression format. [ ... ] Executable code again violates the rule of portability. You wouldn't be able to drag the picture over to, say, a 386 with a VGA card, since you can't execute the embedded code. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor