john13@garfield.UUCP (John Russell) (12/17/87)
-- The end of another year, a new bunch of questions. I hope someone can answer these, I'm just starting to get into a programming mood again and am eagerly absorbing all those programming examples & techniques that I haven't had the time or the background knowledge for up until now. Here are some of the items which have been on my mind since just before exams started: 1. Problem with Layers/IBase locking. This is a strange problem, I'm wondering if anyone else has encountered it. I used the ActivateGadget Leo posted in a short program (mainly to see about requesters). I had the program working fine. Then a single line disappeared from my source file (don't ask me how), and after restoring it I haven't been able to get the program to work since. What happens is that the requester comes up, but before the gadget is rendered a system requester pops up in front -- and freezes before anything shows (ie it's just a titled window border with no white background or message inside). The symptoms look like a LockIBase is not being released, but I never LockIBase. The drives still click and validate disks, but everything (even the mouse) is frozen. Any ideas? I know Heliosmouse is not responsible. 2. How smart is ClipBlit()? I am wondering about blitting selected planes, bitmaps of differing depth, sizes, etc. Does clipblit do any error checking whatsoever? I know that you can read off the end of a rastport and get junk; is it OK to blit from a 1-plane screen to a 2-plane or vice versa (and does the writemask function in such a case)? Are the other blit routines more versatile, faster, check for more errors, or (more likely) just work at a lower level than clipblit? 3. Simple IFF routines. Thousands and thousands of lines of IFF code I've waded through... and not one modular or general-purpose enough for my liking. If I ever get the time to convert one to my particular needs, I'll make sure to distribute it... calls like Read_picture_info() -- returns a pointer to a structure whose tags are explained here, not 5 header files down. Will_this_picture_fit_my_screen() -- returns boolean. Create_a_screen/window_to_load_this_picture_in() -- optional. Crunch_picture_into_screen/window() -- you know, the way DPaint II remaps colours and dimensions if it wouldn't normally fit or have too many colours. Load_picture_into_screen/window() -- if it is of the right size & depth. This is one area in which highly generalized (and also highly specialized, like the Crunch() function above) examples are sadly lacking. I don't have to be able to re-write trackdisk.device to fopen a file, why should I have to understand every structure definition and memorize every defined symbol in the IFF standard to be able to display a picture that I may be able to _create_ in 10 lines of code? Why is there no iff.library with these calls already there, perfected and bug-free rather than every example saying "doesn't handle these 10 chunk types or overscan, processes these chunks in a non-portable way, and bypasses Intuition for this crucial section"? Yes, many of those thousands of lines I examined came from an (old) official IFF disk in the Fish collection -- all I really learned from that was that the people who a) can write Deluxe Paint, b) wrote the IFF standard, and c) work for Commodore (and any combination thereof) can write such programs (but even then it takes them thousands and thousands of lines...). Sorry if it sounds like I'm bitching, but shortly after the last time I did key-equivalent shortcuts appeared in Geos for the C64 so I'll go on believing that it might do some good. I'll say it again - if I can construct a complex and multipurpose graphical interface such as a window, something which was not even dreamed of not many years ago, by initializing one structure with simple and (dare I say?) intuitive parameters and calling OpenWindow(), reading in a picture should be just as easy. Joe User should be able to get it working right the same day he learns how to open a window. A NewPicture structure with pointer to rendering rastport or null if one should be created, pointer to newwindow structure if rendering should be done in a new window, constraints on size, # colours, viewmodes etc? Why not? Look for one Real Soon Now (right after I finish typing this all in :-). You know, I think I'll do that! 4. Alternatives for a timer. Several ideas I have in mind require a timer that wakes up my program every now and then (ie precision not a factor). Intuiticks is perfect, except it only signals when the window is active (or when I flip screens using wKeys, even if the window doesn't get activated). I'm looking for something that will _always_ send signals, won't muck up my waiting on Intuimessages, and ideally is as simple and painless (even to the point of being recreatable entirely from memory, with me that's a rarity :-) as a 'case INTUITICKS:' clause. The options I know of offhand are: - set up the timer device to send me requests, I don't have experience with this but I don't see any major difficulties unless there are factors I'm not aware of. - Intuiticks as I said before, maybe there is some way to massage them into always happening? - run in a tight loop with very low priority, so it keeps executing but doesn't get in the way of anything else; maybe bump a counter and give up the CPU until it's time to act. I've heard of, but don't have enough info to ask intelligent questions on the applicability of, the VBLANK interrupt and various functions like AddIntServer. While I used to do a lot on the ol' 64 in the way of raster and other such interrupts, I've managed to shield myself from such almost-hardware-level considerations on the Amiga up 'til now. <<Sigh>>, I suppose next I'll be removing disk-rattling copy protection ;-). Which, in most people's experience, is the cleanest, easiest, small-codest, anything-that-comes-to-mindest scheme for timing (code examples also appreciated if you reply by e-mail)? Any advantages at all of any particular scheme are welcome, I can think of some good uses for precise timing as well. If you've read this far, you certainly deserve a Merry Christmas! If you can also help with any of these, then a Happy New Year to you, and may your New Year's resolution be 1200 X 800 :-). John -- "Listen fathead, the ONE thing we DON'T need is some trigger-happy lunatic in charge... No I didn't mean you Mr. President... Yes sir, I'm sure you do get a lot of that sort of thing." -- Judge Harold T. Stone
dmose@agora.UUCP (Dan Mosedale) (12/21/87)
In article <4306@garfield.UUCP> john13@garfield.UUCP (John Russell) writes:
:3. Simple IFF routines.
:
:Thousands and thousands of lines of IFF code I've waded through... and not
:one modular or general-purpose enough for my liking. If I ever get the time
:to convert one to my particular needs, I'll make sure to distribute it...
:calls like Read_picture_info() -- returns a pointer to a structure whose tags
:are explained here, not 5 header files down. Will_this_picture_fit_my_screen()
:-- returns boolean. Create_a_screen/window_to_load_this_picture_in() --
:optional. Crunch_picture_into_screen/window() -- you know, the way DPaint II
:remaps colours and dimensions if it wouldn't normally fit or have too many
:colours. Load_picture_into_screen/window() -- if it is of the right size &
:depth.
:
:This is one area in which highly generalized (and also highly specialized,
:like the Crunch() function above) examples are sadly lacking. I don't have
:to be able to re-write trackdisk.device to fopen a file, why should I have to
:understand every structure definition and memorize every defined symbol in
:the IFF standard to be able to display a picture that I may be able to _create_
:in 10 lines of code? Why is there no iff.library with these calls already
:there, perfected and bug-free rather than every example saying "doesn't handle
:these 10 chunk types or overscan, processes these chunks in a non-portable
:way, and bypasses Intuition for this crucial section"?
:
:I'll say it again - if I can construct a complex and multipurpose graphical
:interface such as a window, something which was not even dreamed of not many
:years ago, by initializing one structure with simple and (dare I say?)
:intuitive parameters and calling OpenWindow(), reading in a picture should be
:just as easy. Joe User should be able to get it working right the same day he
:learns how to open a window. A NewPicture structure with pointer to rendering
:rastport or null if one should be created, pointer to newwindow structure if
:rendering should be done in a new window, constraints on size, # colours,
:viewmodes etc? Why not? Look for one Real Soon Now (right after I finish
:typing this all in :-). You know, I think I'll do that!
:
This is an excellent idea! Since IFF is fairly integral to the amiga,
perhaps the above mentioned routines ought to be added into ARP.library!
(Are you out there cheath? :)
:John
:--
:"Listen fathead, the ONE thing we DON'T need is some trigger-happy lunatic
: in charge... No I didn't mean you Mr. President... Yes sir, I'm sure you
: do get a lot of that sort of thing."
: -- Judge Harold T. Stone
==
\\ "These opinions may in some way represent those of my employer... //
\\ but I seriously doubt it." //
\\ // Dan Mosedale dmose@agora \\ //
\\/ ...tektronix!reed!percival!agora!dmose \// donw@zehntel.UUCP (Don White) (12/24/87)
In article <656@agora.UUCP>, dmose@agora.UUCP (Dan Mosedale) writes: > In article <4306@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: > :3. Simple IFF routines. > : > :Thousands and thousands of lines of IFF code I've waded through... and not > :one modular or general-purpose enough for my liking. If I ever get the time > :to convert one to my particular needs, I'll make sure to distribute it... > :calls like Read_picture_info() -- returns a pointer to a structure whose tags > :are explained here, not 5 header files down. Will_this_picture_fit_my_screen() > This is an excellent idea! Since IFF is fairly integral to the amiga, > perhaps the above mentioned routines ought to be added into ARP.library! > (Are you out there cheath? :) > > :John As a matter of fact, I HAVE a group of single call functions for - creating windows (done) ( MakeWindow(<window mode DEFINE>, "title"); ) - creating screens (done) ( MakeScreen(<screen mode DEFINE>,"title"); ) - loading IFF images (done) ( LoadIFF(<filename>,windowptr,scrnptr); ) - saving IFF images (still developing 40 % done) - running menus (still developing 20 % done) My only problem is figuring out how to use Object librarians well enough to make a library. Don White zehntel!donw P.O.BOX 271177 Concord, CA. 94527 - 1177
john13@garfield.UUCP (John Russell) (12/25/87)
In article <656@agora.UUCP> dmose@.UUCP (Dan Mosedale) writes: >In article <4306@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >:A NewPicture structure with pointer to rendering >:rastport or null if one should be created, pointer to newwindow structure if >:rendering should be done in a new window, constraints on size, # colours, >:viewmodes etc? Why not? Look for one Real Soon Now (right after I finish >:typing this all in :-). You know, I think I'll do that! > >This is an excellent idea! Since IFF is fairly integral to the amiga, >perhaps the above mentioned routines ought to be added into ARP.library! >(Are you out there cheath? :) Actually this is about the only project of any complexity that has caught my interest so I was hoping to follow up with flexible, extensible code examples. I jotted down ~250 lines of structure definitions, flag values, and gave some thought to general outlines of functions; real code will have to wait a little while, I'm finally absorbing those chapters in the RKM I just skimmed before and want to finish before I start anything major. I have no objections to someone else implementing the same idea, though. I would like to have some input if they do decide to go ahead with it. The main points that have occurred to me are: - NewPicture structure containing pointers to display structures you have created or NULL if they are to be created for you, and flags giving a description of the actions you want performed during picture manipulation - the routines I mentioned in my earlier letter could be controlled by "master" routines like OpenPicture(), ClosePicture(), etc which would use the NewPicture structure: much like OpenScreen() and OpenWindow() save you from initializing the ViewPort, Copperlists, and Layers - OpenPicture() returns Picture structure which you can examine and use to call other manipulation routines - you specify which parameters are taken from the file, and which file parameters you might override, through flags - each possible failure case (eg picture too big) can have an action associated with it, whether it's "fail", "clip in a certain way", etc - when the picture is opened, the special actions that were taken such as clipping or colour remapping are signalled by flags in the picture structure; also such things as unusual viewmodes can be tested for easily Pictures would be considered as either disk-resident or ram-resident. There would be routines for various types of operations on pictures that were already displayed, such as saving, resizing, rotating, bending... (sound familiar? :-). A global list of pictures would make it simple for multiple programs using these routines to share rastports, swap (parts of) pictures, and so on. This ties in to an earlier idea, the idea of having rastports independent of programs so that you could do some object-oriented plotting followed by painting followed by image processing ad infinitum all on a globally- accessible display structure. You could wind up with some killer images this way! If this were to be done as code to link into your own programs, another way to make it flexible is to have sections dealing with, say, HAM mode left out by compiling with a symbol like NO_HAM defined so that someone only concerned with certain types of pictures or certain types of behaviour could still write tight programs. John -- "...and intuition, in a case such as this, is of crucial importance." -- William Gibson, _Count_Zero_
peter@sugar.UUCP (Peter da Silva) (12/26/87)
The problem is that IFF is an extremely complex format, and that the IFF driver routines provided don't come with a simple explanation as to how to use them. You basically have to look at the source and demos and do a lot of guessing. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) (12/29/87)
In article <1311@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >The problem is that IFF is an extremely complex format, and that the IFF >driver routines provided don't come with a simple explanation as to how to >use them. You basically have to look at the source and demos and do a lot >of guessing. This file has been in the ReadMes directory of the IFF disk for quite a while. I tried to provide enough information for a programmer to compile the provided examples, plus a bit of info on what each module does. ------------------------------------------------------------------------------ >>> Tips for Compiling IFF Examples <<< Carolyn Scheppner - CBM IFF examples, in most cases, are not self-contained programs. They need to be linked with various IFF modules which contain the IFF reader/writer/general routines that are used both directly and indirectly by the example. Information on which IFF modules are required by the EA examples in the SOURCE directory can be found in the lnk.files directory. The examples in the EXAMPLES directory contain linkage information in their opening comments, and .with files are supplied for those which must be linked with IFF modules. See the AmigaDos Developer's Manual "The Linker" chapter for more info on WITH files. Examples and modules are listed below. The IFF header (.h) files are also required when compiling the examples. The headers can be found in the INCLUDE/iff directory. I will assume that you have set up your C development system so that there is plenty of room on your source & headers work disk. Make an "iff" subdirectory in your "include" directory and copy the IFF headers there. Note for AZTEC C people: get rid of the comments inside the parentheses in the function definitions in packer.h. Make a directory (or directories) on your work disk for the IFF object (.o) modules. Since I work out of ram:, I keep the IFF modules in 3 directories (iffrobj, iffwobj, iffobj). Then I can easily copy just the ones I need to ram:. The object modules you need are listed below (IFF reader, writer, general modules). Note for AZTEC C people: These are Amiga C object modules. Copy the source (.c) for the modules to your C work disk and recompile them with AZTEC (without linking). The compiler.h header contains a switch (FDwAT) for compatibility with various compilers. You may have to change the value of this switch. In addition, you may find it necessary to link with your 32 bit library. I use Lattice but I would appreciate a list of any changes needed in the IFF source for compilation under Manx. I could include the list on the next release of this disk, or possibly incorporate the changes into the source. To compile an example, copy the example source (.c) file to your C work disk (or ram: if that's where you work). Compile the file WITHOUT linking it. You should now have a .o file for the example. (Note: Following linkage instructions are for Amiga C but should be helpful with other development systems as well) Use your editor to create a WITH file for the example. You can start with the appropriate file from modified.lnk.files. Add the proper paths to the filenames so that ALINK can find each of the files. For example, if Example.o was in df1:obj, the IFF .o modules were all in df1:iffobj, your startup and lib's were in df0:lib, and you wanted your executable placed in df1:executables, this would be your Example.with file: FROM df0:lib/LStartup.obj, df1:obj/Example.o, df1:iffobj/iffr.o,* df1:iffobj/ilbmr.o, df1:iffobj/unpacker.o TO df1:executables/Example LIBRARY df0:lib/LC.lib, df0:lib/Amiga.lib When I'm working with IFF, I keep my files and all of the IFF .o modules I need in ram:, and I'm cd'd there. I assign the label LIB: to the directory containing my startup code and linker libraries. This is my Display.with: FROM LIB:AStartup.obj,Display.o,myreadpict.o,iffmsgs.o* iffr.o,ilbmr.o,unpacker.o TO Display LIBRARY LIB:Amiga.lib, LIB:LC.lib Linking is easy once you've set up the .with file: Alink with Display.with ------------------------------------------------------------------------- >>> List of IFF modules <<< IFF reader modules: iffr.o Lowest level reader rtns ilbmr.o Higher level ILBM reader rtns readpict.o Highest level ILBM reader unpacker.o Unpacking rtn IFF writer modules: iffw.o Lowest level writer rtns ilbmw.o Higher level ILBM writer rtns putpict.o Highest level ILBM writer packer.o Packing rtn General IFF modules: gio.o Fast IO rtns remalloc.o Memory allocation rtns -------------------------------------------------------------------------- -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< UUCP ...{allegra,ihnp4,rutgers}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=