Obviously, the whole idea of the DevCon (and indeed ARise, JMS, and
all the others) was to provide a forum for discussing what we can do,
rather than what we should tell the Amiga's owners to do. Rather than
employ what Worms author Andy Davidson called "blind optimism", our aim
is to do quite the opposite and perform actions in spite of (but
wherever possible, with the assistance of) the Amiga's owners. I'm not
saying that we should shut them out, merely let them worry about more
pressing matters. We can always ask for help when we need it, as they
seem like decent, open-minded people. Besides, the idea for the DevCon
happened long before Gateway appeared on the scene.
It has been suggested that
Adobe's move in placing their IFF ILBM plug-in for Photoshop 4 in the
"goodies" folder is indicative of their acknowledgement that the Amiga's
grip on graphical applications is loosening. My interpretation is that
now 24-bit resolutions are the norm, people (Amiga users and otherwise)
are simply ignoring IFF ILBM. The reason for this is simple: ILBMs use
ByteRun (sometimes called "packbits") compression, which produces
consistently poor results for images which do not have continuous
patches of colour. Although IFF ILBM is indeed a standard on the Amiga,
most people tend to prefer JPEG (which, unlike IFF ILBM uses lossy
compression algorithms) or in some cases TIFF (which uses LZW - Lempel
Ziv Welch compression, similar to that used in archivers such as Lha) as
the resulting files are considerably smaller. This is also true, I
believe, of the Mac, despite the fact that PICT is a reasonably flexible
format. As the PC has a large array of standards to choose from, this
isn't quite as noticeable. Odd though it sounds, one of the original
formats, PCX, has with the aid of much kludging (not unlike PC hardware,
really) managed to make it into 24-bit. IFF ILBM doesn't need such a
thing, as it was designed from the beginning to be extendable. The
compression field in the ILBM bitmap header (BMHD) is actually byte
wide, and so can be extended easily to accommodate more compression
modes. Which compression algorithm do we use ? How do we implement it ?
The answer lies before us, XPK (ref: util/pack/xpk_Develop.lha from
Aminet). This is a reasonably mature standard which not only benefits
from continuing development, but is also well-documented. Although the
package is designed for non-commercial use, I'm sure that with some
consultation with the programmers, we could utilise this within the IFF
ILBM standard. The beauty of XPK is that it too is extremely flexible,
and so in the event of superior compression a lgorithms being developed,
the IFF ILBM standard would instantly benefit. However, as compression
and decompression is done at the application level, we have a problem in
that many applications would need recoding, or would need some kind of
third party conversion tool (or someone willing to hack together a
patch). Tweaking datatypes would certainly not be a problem, as IFF ILBM
is pretty easy to parse. I am uncertain as to the legal position of this,
as well as the IFF standard in general as technically we have no right to
modify the standard by ourselves.
Another topic raised at the DevCon was that of
extending AmigaGuide. Someone suggested that we should have something
that is capable of "wowing" people. While this is indeed an interesting
proposal, showing someone how cool the Amiga's on-line help is doesn't
come very close to the top of my list of what to demonstrate. People
mostly agreed that an indigenous standard such as the existing
AmigaGuide isn't really the way to go. It has been suggested that HTML
is a worthy replacement, however with the recent attempts by Micro$oft
and Netscrape to code each other out of the market with yet more HTML
tags, this at first seems to be a bad idea. After all, we need a
standard that we alone control, and so we can modify it and our handling
of it without fear that our 28K viewer suddenly explodes into 4 megs!
Some time ago, work progressed on so-called "Advanced AmigaGuide" which
contained support for inline images and so on, however I've yet to hear
any more about it. Work is underway on a new standard called iXGuide.
The current implementation appears promising, if a little rough round
the edges. This alternative seems quite logical, as backwards
compatibility is more or less guaranteed. The other choice, as suggested
by Kermit Woodall, is to simply freeze the HTML standard at, say, level
2. At least this way, we have a firm target of what to aim for without
someone else moving the goalposts. However, HTML does present some
implementation difficulties, as demonstrated by the time taken for Amiga
web browsers to mature fully in terms of support for tables. This makes
the possibility of a complete HTML datatype (as suggested at the DevCon)
that supports the complete set of table, and image tags seem unlikely.
Although structured drawing packages (and
indeed other applications such as word processors which utilise
structured images) are not widespread on the Amiga, the use of
structured images is increasing due to the advances in printer
technology. However, structured drawing formats despite being many in
number (including our own IFF DR2D) are exceptionally difficult to parse
(certainly far more than bitmapped images). The most obvious example is
PostScript. While this is a far from perfect standard, it's use in Amiga
packages is inhibited by the extreme difficulty to write a parsing
routine for what is effectively a programming language. In order to
encourage more use of such formats in Amiga applications, it would be
prudent to abstract this sort of task away from the application
programmer. Datatypes are once again the obvious answer. However, we
would need a completely new class of datatype objects as it would not be
possible to use picture.datatype as it is primarily for bitmapped
images. By providing a datatypes system for structured images, we would
not only reduce the work for application programmers, but we would also
open the door to third party extensions. This would ultimately lead to
more reliable implementations of structured image parsing. As 2D structured
graphics are fairly global in the way they represent images, deriving an
internal format for use/conversion by the application should not be too
great a task.
Following on from the above discussion, it is
clear that the 3D graphics market is in dire need of standardisation.
Although Imagine and Lightwave objects are usually the norm, there are
also packages such as Real 3D, Cinema 4D and of course Nova Design's
Aladdin 4D. Some of these packages provide conversion tools for loading
in one or two other formats, while others provide none or just the
obligatory Sculpt 4D converter. We can at best hope to convert just the
actual object as procedural textures are most definitely off-limits
(although this can be worked around by generating a bitmapped brushmap
by executing the procedural texture code). This would prove complicated
enough as some packages model with splines and so on. Some formats such
as the TurboSilver/Imagine object format are openly documented, and so
with a little cooperation, a datatypes system can be developed and
integrated into 3D rendering software. We already hav e programs such
as "ShowObj" on the Aminet (although whether or not it is still under
development, I don't know) which parse and display LWOBs (Lightwave) and
TDDDs (Imagine). Again, we would require a new datatypes class, and the
overall advantages of such a system are similar to those detailed for 2D
structured images.
It is widely-known that the Amiga's
present implementation of printer.device has a colour resolution of only
12-bit. It is also considerably slower than it ought to be (which, among
other things, is down to the overhead resulting from clipping due to
images being rendered strip-by-strip, and also the lack of direct
support for scalable objects). There are commercial offerings that do
provide true 24-bit printing, and while their interface is a logical
extension of the current system, they are both limited (in that the
present printer.device can only be extended so far) and non-standard.
The net effect is that an application programmer wishing to provide
support for printing in 24-bit colour has to work with several different
APIs, and still get a very low performance. Now, as commercial products
do have a foothold in this market, it is obviously not a good idea to
rock them too much by selecting one system over another. Instead, if we
were to design a standard Amiga 24-bit printing system, then the printing
enhancement packages could still be used underneath for providing the
actual drivers and enhancing the dithering. The advantage to the
application programmer of course is that he only programs with one API.
As this API would be totally different from the present system, we could
start from scratch and implement all the important features, while
including enough extensibility to allow future upgrades. Existing
applications would still have to use the existing system, whereas those
under constant development would use the newer system (assuming it is
available on the user's machine), and fall back to the old
printer.device if it is not available for use. This unfortunately means
slightly more work for the applications programmer who already has
software on the market, but is a necessary step nonetheless. Think of it
as a form of CyberGFX or AHI for printers.