8.1.1.8 Final Notes
This section details future plans as well as problems or potential problems
with the MacOS/X, MacOS/X Server 1.0 (Rhapsody), OpenStep, and NextStep ports
of Crystal Space. Consult this section if you want to know what direction this
port is taking.
Future Plans
This is a list of items which are planned for future releases of this project:
-
Write an OpenGL canvas for the MacOS/X port.
-
Write a CoreGraphics canvas for the MacOS/X port.
-
Rewrite `next2d' canvas image sizing computation so that the image's
row-bytes value is always multiple of 16. This is necessary for best video
performance according to the NextStep 3.0 WindowServer Release Notes.
Currently, this condition is not enforced, and it is possible for the user to
specify window sizes (via the `--mode' switch) which break this
requirement. Furthermore, when dynamic canvas resizing is implemented, this
will be an absolute requirement.
-
In `next2d', consider respecting the `area' argument to
iGraphics2D::Print()
and flushing only part of the frame buffer to the
display rather than the entire frame buffer. However, this must be done
carefully in order to preserve all of the speed advantages of the current
technique of flushing the entire frame buffer via a single Mach message. The
way to do this is to create a second `NSBitmapImageRep' (or
`NXBitmapImageRep') using the same frame-buffer as the full-sized one, but
which has a smaller specified area and a much larger row-bytes value. This
second image representation will actually overlay the full-sized one but will
specify smaller dimensions. The row-bytes value must be computed in such a way
as to compensate for all of the image data outside of the secondary image's
bounds.
-
Support user-initiated canvas resizing in `next2d'.
-
Create native AppKit cursors for CSWS cursors.
-
Write an Apple/NeXT `line' canvas which utilizes `NSBezierPath' on
MacOS/X and MacOS/X Server 1.0 (Rhapsody), and which utilizes PostScript
primitives on OpenStep and NextStep.
-
Implement sound support.
Bugs
This is a list of known problems with the current release of this project:
-
It is not currently possible to launch the Crystal Space demonstration
applications by double-clicking on them in the Viewer application in MacOS/X
Server, or from the the Workspace Manager's File Viewer on OpenStep and
NextStep. This problem is a result of a limitation of Viewer and Workspace
Manager applications. When the Crystal Space demonstration applications are
launched, they expect to find the configuration files `scf.cfg' and
`vfs.cfg' in the current directory---which is generally the same
directory in which the Crystal Space applications reside. Unfortunately,
neither Viewer nor Workspace Manager provide the necessary information for
Crystal Space to locate these administrative files. Therefore, at this time,
all Crystal Space applications must be launched from the command-line.
The proper solution to this problem is to place each Crystal Space application
within its own application wrapper (`.app') at build time. Doing so,
however, will require a certain amount of re-work of the makefile system. It
is also not clear as to precisely which resources should be relocated into the
application wrapper.
-
One attempt to solve the problem of not being able to launch an application via
double-click (distinct from creating an application wrapper) was the
introduction of a default, `CrystalSpaceRoot', which tells the application
where the root of the Crystal Space resource hierarchy resides. This setting
does allow applications to be launched via a double-click in NextStep, however
it fails on OpenStep. It is suspected that the problem has to do with the fact
that the Workspace provides no path information whatsoever (not even in
argv[0]
). Although the application wrapper is ultimately a better
solution, it is still worthwhile to resolve this issue.
This document was generated
using texi2html