Developer Forum

ello,

Five years after their original release, two of my Star Fighter 3000
editor applications (SFcolours and SFskyedit) have recently undergone a
major overhaul. The main improvement is that both now support the
global clipboard and drag-and-drop protocols. In case you are wondering
why I bothered, have been using them as a test-bed for new library code
that will be required to implement SFeditor's objects map editing mode.

Recent changes to SFcolours:
- Selected colours now display their actual rather than logical colour
numbers.
- It is now possible to select logical colours by dragging a rubber
band box around them.
- It is now possible to copy colours by dragging them elsewhere in the
editing window, to the icon bar icon, or another window.
- Can also use clipboard 'copy' and 'paste' editing as an alternative
to drag and drop.
- Redesigned the hill colours window to resemble that for object
colours. This allows colours to be copied more easily between the two
kinds of file.
- You can now force exclusive selection by holding Ctrl whilst clicking
a selected colour.
- Major revisions to the manual text.

Recent changes to SFskyedit:
- Selected colour bands now display the associated colour numbers
instead of the indicies of those bands.
- Whilst the input focus is elsewhere, the current selection is faded
or the caret is removed.
- The Home and End keys now act on the caret rather than just scrolling
the editing window.
- You can now disband a selection and set the caret position by
clicking on it with the Ctrl key held down.
- Dragging selected colours to the SFskyedit icon on the icon bar will
now open a new editing window containing just those colours.
- Will now load colours dropped on the internal pane or furniture of an
editing window (by inserting them at the caret or replacing the
selection).
- Fixed a bug with the 'Trap caret' option; pressing PgDn or PgUp when
the window could scroll no further would move the caret anyway.
- It is now possible to insert new bands while a selection exists (the
selected bands are replaced).
- Colour bands are now selected at their destination, after having been
copied within a file by dragging with Shift held.
- The number and border of selected bands are now plotted using
absolute black or white, instead of relying on Wimp colours 0 and 7.
- Improved the implementation of smoothing so that it works on narrower
areas of contiguous colour.

Both applications:
- Added 'Web' buttons to the 'About this program' windows.
- Can now export selected colours in CSV and text format, if requested
by a recipient.
- The palette dialogue box now displays the current colour number,
which can be changed using the keyboard or adjuster arrows. The pointer
is now bounded whilst dragging to change the selected colour.
- Now support the global clipboard and drag-and-drop protocols, to
allow seamless interaction with each other and other applications.
- The input focus is not considered to be lost unless the
caret/selection entity is claimed by another application.
- If solid file drags are configured then selected colours will be
represented during a drag by a specially generated icon instead of a
cycling dashed box.
- Auto-scrolling of windows during a drag is now delegated to the
window manager, and hence requires RISC OS 4 or later. The configured
auto-scroll delay is used.

Thanks for reading. The latest versions of all my Star Fighter 300

I have made a few more changes to my Star Fighter 3000 editors since my
posting last month, which I summarise below:

SFColours and SFSkyEdit can now import colours in CSV (comma-separated
values) format. CSV is also the default export format, which manifests
most clearly when selected colours are dragged to a directory display.
I have abandoned the esoteric data format in which SFSkyEdit 1.40
exported colours (because CSV does just as well). In both applications,
imported colours are now selected after being dragged to the icon bar
icon. I also fixed a bug where a spurious 'your_ref' value was included
in outgoing DataSave messages if a drag had ever been claimed (even if
not saving to a drag claimant). I also corrected the input focus colour
of the 256 colour picker (it is transient, so the title should remain
grey).

I modified SFSkyEdit to avoid a bug in the DragAnObject module, which
manifests when an area overlapping the representation of a dragged
object is independently redrawn before the mouse has been moved. I also
fine-tuned the range of acceptable values for the render offset and
stars height. The dithering algorithm now produces results identical to
the original game files. The stars height is now modified as
appropriate when a new ground level is set in the preview window.

I fixed a small memory leak that had affected both FednetCmp and
SFToSpr.

SFToSpr can now decode and create sky colours files, which it deals
with as raw pixel data (unlike SFSkyEdit, which works at a higher
level). Output sprite files may now optionally include embedded
non-graphical data. Batch conversions rely on this embedded data being
present. The non-graphical data can also be saved separately, but CSV
is now used instead of the old esoteric text-based format for
animations data. You can now specify paint offsets when creating a sky
pictures file (were thought to be irrelevant). I also corrected a
pervasive mis-understanding of the purpose of the second copy of each
image in a sky pictures file (those produced by earlier versions of
SFToSpr caused jerky movement).

All game files are now checked for internal consistency upon being
loaded by SFToSpr, SFSkyEdit or SFColours.

Thanks for reading (if you got this far). As ever, the latest versions
of all my Star Fighter 3000 utilities are available from:

http://www.yqcomputer.com/

Cheers,
--
Chris Bazley