Path: utzoo!utgpu!water!watmath!dalcs!garfield!john13
From: john13@garfield.UUCP (John Russell)
Newsgroups: comp.sys.amiga
Subject: Christmas questions cause considerable consternation
Keywords: lots o' stuff : locklayers/ibase, blitting, IFF, timers
Message-ID: <4306@garfield.UUCP>
Date: 16 Dec 87 23:16:13 GMT
Distribution: na
Organization: CS Dept., Memorial U. of Newfoundland, St. John's
Lines: 120

--
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