Way back in 1998 when I first started fiddling with Star Fighter 3000, I managed to work out the file format of the ground maps used by the game. I thought that it would be fun to write a map editor for the game.
The result - SFMapEdit - is 70KB of BASIC with some impressive features. However it only edits the maps used to specify the layout of the ground tiles: In other words, only purely cosmetic alterations to the game are possible. SFMapEdit was never publicly released, though work-in-progress screen shots appeared on my web site.
I soon realised that to allow other game elements to be edited (ground objects, fighters, flight paths, hills), a much more sophisticated program would be required. This was to be not only a map editor, but a full mission editor - and so the idea of 'SFeditor' was born.
The many types of data files that SFeditor is designed to edit can be categorised by two high-level concepts - Base maps and Missions. Base maps have data for a ground map, hills and static objects - this basic scenery may appear in various missions. Missions include patch data to amend the base map, a text briefing, map animations, fighters, flight paths, targets etc...
Rather than dealing with individual data files, SFeditor will only allow whole maps and missions to be edited. This has the big advantage that the complex relationships between data files are automatically managed.
Unlike its predecessor, SFeditor is being written in C as a Toolbox application. Building on code and experience gained through writing simpler editors like SFColours and SFSkyEdit, the multi-document aspect was designed into the program at an early stage. To make such a multi-featured editor usable, a number of editing modes will be available for different game elements.
The general idea is that due to the modular nature of the project, it will be possible to release SFeditor in stages: Once the basic structure of the program is ready, new editing modes can be released as they are completed. This will mean that something usable will be available to play with before completion of the monolithic application.
Serious post-holiday work got under way today. Here are some new icons that have been designed today, in addition to roughly 50 that already exist (most of which are for tool buttons):
|
|
|
I have approximately 334 KB of source code and the working skeleton of the application. However, a lot of code has been written that won't be integrated for some weeks or months.
After a lot of optimisation work, SFeditor's redraw of ground maps is finally looking slick and polished. Here we can see views of various maps, demonstrating both the multi-document flexibility and the different zoom levels available (with detail increasing as the map enlarges). At ×1 magnification there are only 4×4 pixels per tile, so a lookup table of average tile colours is used to improve visual appearance.
SFeditor achieves its fast redraw by using a cache created on
the fly for each redraw rectangle, into which hand-optimised
ARM code
routines throw map tiles at high speed. This cache can then
be plotted to the screen using a single
OS_SpriteOp call to perform colour translation and
scaling for the current screen mode.
Early versions (including SFMapEdit)
had been using an OS_SpriteOp call to plot every
individual map tile. Bearing in mind that a window at
×1 magnification may show the entire map of
256×256 tiles (65536 in total!), you can see that a
better method had to be found.
New screenshot showing use of the circle tool, and the newly completed map tiles palette. Note how the palette tiles are grouped by type (the same groups used by the smoothing wand, in fact). Note also the tile inversion map (EOR effect) used to allow accurate positioning of geometric shapes. This is also used to allow Filer-like toggle selection of individual tiles, as well as the more usual exclusive selection using a drag box.
The snakes tool and smoothing wand are both now working (see screen shots), so the only exotic map editing facility yet to be implemented is the stamps tool.
Progress on SFeditor has been intermittent and indeed non-existent for long periods of time, including the last year or so. For anybody patiently awaiting the first public release this must have come as something of a let down, for which I apologise.
All I can say in my defence is that lot of things have happened since I started this project; A-levels, university, dissertation, finals, leaving home, and not least two major releases of Star Fighter 3000. Inevitably these other activities often took priority over development of SFeditor. More recently, I have just started a full time job and have had other commitments in the RISC OS market.
For what it's worth, SFeditor is currently only second on my list of self-indulgent things to do (after watching Renée Zellweger films and before my pet project for the BBC Microcomputer).
Latest development screen shot. As you can see the user interface has undergone some changes and there is now a full menu tree (much of which is functional). The optional grid (colour configurable) and status bar are both recent additions. The latter is reformatted according to the width of the map window. Map animations may now be edited, deleted, copied etc.
First public release version is now available for download but with very little documentation and (for the moment) no source code. Ground map editing mode is mostly complete - the other two modes are not. Although some code has been written for them and elements of the user interface exist they are unfortunately not usable.
Today something incredible happened - I opened the source code for SFeditor in StrongED. It was a short year, wasn't it? At least this time I won't be plagued by Toolbox sub-menu problems and I have support from a much more powerful version of CBLibrary.
I really need to finish this application before there are no RISC OS users left to use it.
I have finally cracked the problem of rendering the polygonal graphics, as shown in the screen shot below. This shows the Training Academy map being edited in SFeditor's objects mode, with grid overlay enabled. The game itself generates specially-tailored ARM code to render polygonal graphics, whenever a new graphics set is loaded. I used the more commonplace methods available in the C programming language. This opens the door to a fully WYSIWYG objects editing mode, as well as 3 dimensional views of selected ground objects and space ships.
I haven't had so much time for programming recently, because
of the demands of my new job at Picsel
Technologies. However, I have done the considerable
abstraction work required to allow the palette window to be
reused for the objects editing mode (previously it was used
only for snakes, transfers and map tiles - by means of a lot
of nasty switch statements and hard-wired
values).
It's still not finished, it doesn't support undo/redo, it hasn't been optimized, but it's definitely not vapourware!
The second public release version is now available for download, still with very little documentation, but this time with full source code. Positioning of ground objects, trigger actions, hills and clouds is now complete, but editing of ships, flightpaths and mission briefings is not.
This is probably much slower than the first release because it was further developed on a Raspberry Pi and hasn't been optimised yet.
Despite my day job instrumenting a graphics driver, the arrival of my baby daughter, and my sincere (but probably futile) attempt to improve the C programming language, I made time to implement editing of mission briefings and target information points. The latter can be cut, copied, pasted, dragged and dropped just like static objects. Consequently, the third public release version is now available for download.
The fourth public release version is now available for download:
You can now browse the source code on GitHub.
|
All material relating to Star Fighter 3000 is © Fednet Software, 1994, 1995. Email the webmaster. |
|