Except where indicated otherwise, these notes apply to the screens opened by Personal Paint, Personal Fonts Maker 2 and ColorType. The information contained herein has been written for developers of software which locates, grabs, selects, switches to front/back, promotes or performs other functions on screens.
The Cloanto packages to which these notes apply do not have an Amiga Screen title (the corresponding pointer is NULL). This was not possible, as under many conditions it could not be afforded to have a standard screen bar with system-rendered text indicating the name of the program and potentially overwriting other data. A consequence of this is that software that scans the list of Amiga screens needs to take additional steps if it wants to locate information such as the screen title, rather than presenting an empty field to the user.
All Cloanto graphics programs can easily be recognized. If the scan of the list of windows in a screen having a NULL title determines that it contains a window as wide as the screen, and one pixel tall, then it is very likely a Cloanto screen of the type described here. The UserData field of that window points to the title. To make the process reliable even in the event that another application uses a similar format, it is best to check that UserData is non-NULL, and that the string ending with '\0' has a "reasonable" length (<255) and does not contain any unprintable characters (having codes in the range 127-159).
While Cloanto packages are in general compatible with screen "promoters" (utilities that intercept a request to open a given screen, and open another type and/or size of screen instead), it is never safe to promote from double-buffering to non-double-buffering modes (in the case of Personal Paint playing an animation), or from non-RTG to RTG modes, or vice versa. In case of difficulties, the documentation of Personal Paint advises the user to disable the screen promoting software. Ideally, any screen promotion software should include similar notices, or make similar considerations.
When Cloanto programs change screen mode (for example, from PAL to NTSC), they try to prevent that the System Workbench screen opens (if it was closed) or appears to the front. This would be possible by opening the new screen first, and then closing the old screen, but doing so has the disadvantage of requiring, for a brief moment, possibly almost twice as much RAM, which may not be available. Therefore, Cloanto programs such as Personal Paint first open a one-bitplane transition screen, then close the first screen, open the new screen and finally close the transition screen. The transition screen also contains a window, in order to always satisfy Console I/O requirements in case there is no other window in the system. During the transition phase, both the transition screen and the mouse pointer sprite are colored with the current color 0, to make them as "discrete" as possible. The size of the transition screen is as small as is allowed by the Display Database information, and in any case not smaller than 320x200 (it used to be smaller in older versions of Personal Paint, but some graphic systems which contained incorrect Display Database entries would crash). The reason why the screen has only one bitplane and is as small as possible is that it must occupy as little RAM as possible.
We encourage developers of Amiga compatible graphics subsystems to test their system with Personal Paint changing screen modes between various Amiga modes and various other screen modes. We have learned that the quick and repeated actions of opening and closing various screens and windows is a good way to test such a graphic system.
Cloanto packages always used the Amiga (Agnus) blitter according to the official Amiga system specifications, in an OwnBlitter()/DisownBlitter() context. In the case of RTG environments which use Fast RAM for bitmaps, a copy of the bitmap was created in Chip RAM, if this was required to give the Amiga blitter access to the data.
In more recent times, the use of the blitter, once an advantage the use of which was encouraged by Commodore, has more and more become a penalty: not only are recent CPUs faster than the Amiga blitter, but certain systems (e.g. DraCo) do not provide low-level blitter functionality. Also, RAM requirements now tend to abundantly exceed the limited sizes of the Chip RAM which can be accessed by the original Amiga blitter.
Personal Paint 7 includes a set of "virtual blitter" functions, which use the CPU or other processors to achieve effects previously delegated exclusively to the Amiga blitter (and which therefore required Chip RAM). The program can selectively or automatically use a library employing the Amiga blitter, or rather use another library which uses the CPU. This is of advantage when there is no blitter, when the CPU is faster than the blitter, and/or when Chip RAM is particularly slow or precious (as long as graphics.library functions do not require Chip RAM, which is also checked for). Hybrid libraries are also possible, as are 68K-replacement libraries (e.g. PowerPC), or 68K libraries especially compiled for certain processors (e.g. 68040).
The user can normally switch between the use of one library and the other by toggling the "Blitter" setting in the program user interface. In the event that the "Blitter" setting is active, but there is no blitter, the program tries to detect this condition and use the other library. Detecting this condition (no blitter on the host system) is not standard (not having a blitter is "not standard"...), especially when Amiga blitter functionality is partially emulated, and we therefore would ask developers of new "blitterless" systems to let us know how such a condition can be detected, so that we can update the libraries. Also, we would very much like to know about any new graphic systems in which the graphics.library functions can work on Fast RAM (e.g. how that can be detected, what functionality is provided).
In some editing contexts, Personal Paint (like many other Amiga programs) changes the "hot spot" of the mouse pointer to a position other than 0:0 (top left). In combination with certain utilities which replace original Amiga operating system components dealing with the mouse pointer functionality, a mismatch between the pointer and the intended hot spot has been reported. This occurs mainly on AGA systems, and always with mouse pointers having a hot spot other than 0:0. To the user, this results in the Personal Paint drawing pen not being aligned with the center of the cross-hair pointer, for example. To allow for better testing of this particular case, we are making available the following example where a new mouse pointer with non-0:0 hot spot is defined.
static USHORT __aligned chip Fire[] =
{
0x0000,0x0000, /* posctl */
0x0100,0x0000,0x0000,0x0100,0x0100,0x0000,0x0000,0x0100,
0x0100,0x0000,0x0000,0x0100,0x0000,0x0000,0xa82a,0x5454,
0x0000,0x0000,0x0000,0x0100,0x0100,0x0000,0x0000,0x0100,
0x0100,0x0000,0x0000,0x0100,0x0100,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,
0x0000,0x0000 /* reserved */
};
SetPointer(window, Fire, 27, 15, -8, -7);