|
| |
| | |
ELMER'S ATARI ST MAP EDITOR (EDMAP) VERSION 1.10
VERY CRYPTIC INSTRUCTIONS
1.0 WHAT YOU GET FOR YOUR MONEY
This editor is designed for creating maps of up to
256x256 blocks, from a set of 256 blocks, each block 16x16
pixels. Most of the code for this editor has come straight
from the sprite editor (EDSPR) and thus this program looks
and 'feels' very similar to that editor, and I will only
point out the differences from it in these instructions.
Blocks are created and edited on the 'GRID', which is
4x4 blocks in size, and then moved into the block store. A
map can then be created from these blocks on the seperate map
editing screen.
2.0 HAVE A DRAG
See EDSPR documentation.
3.0 SCREEN LAYOUT - EDITOR
See EDSPR documentation.
3.1 SCREEN LAYOUT - MAP MODE
The map editor screen is layed out in the following fashion
...
0000000000000000000000 0 - map display
0000000000000000000000 1 - map position
0000000000000000000000 2 - map controls
0000000000000000000000 3 - map pointers
0000000000000000000000 4 - global controls
0000000000000000000000 5 - block position
0000000000000000000000 6 - block controls
7 - block pointers
1111 2222 3333333 4444 8 - block display
4444 9 - text messages
55 666666 7777777 4444
8888888888888888888888
9999999999999999999999
Here are further details of what each area of the screen is
used for.
0 - This area shows the area of the map currently being
worked upon. If the map size is smaller than this area
then the map is displayed in the bottom left hand corner
of the area.
1 - This shows the current position of the bottom left-hand
corner of the map.
2 - These are the icons for moving around the map.
3 - These are the two map position pointers, corresponding
in use to the workspace pointers in the sprite/block
editor.
4 - These are the icons for functions to do with editing
the map.
5 - This shows the current position in block store.
6 - These are the icons for moving around block store.
7 - And if you hadn't guessed, these are the block position
pointers carried over from the block editing screen.
8 - The block display. To put blocks on to the map, click
on a block in this area and then click on the places on
the map display where you want to put it; to quit
plotting click the right mouse button.
9 - This area holds the editor name/version, help messages,
and the size of the map. The figures displayed here,
and those used when defining the map size on the editor
screen are -1, i.e. 0-255 corresponds to sizes of 1-256.
4.0 DRAGGING IMAGES
See EDSPR documentation.
5.0 ICON FUNCTIONS
See EDSPR documentation (ha-ha!).
6.0 FILE FORMATS
*.BLK -
The file consists of a 128 byte header followed by a
number of 128 byte blocks.
The header is constructed as follows ...
(All entries are of word length unless specified.)
+00 2 character string denoting the file version number,
currently '01'.
+02 16 word colour palette in XBIOS SET_PALETTE format.
+34 Palette flag, 0=all 4 bit-planes, 1=clear plane 0, etc.
+36 Current foreground ink
+38 Current background ink
+40 Reserved - 0
+42 Block position pointer #0
+44 Block position pointer #1
+46 Block position pointer #2 (first frame of sequence)
+48 Block position pointer #3 (last frame of sequence)
+50 Current block position
+52 Fat pixel mode flag, 0=off, 1=on
+54 Cursor style (0,2,4,6), a dot cursor or a cross-hair
cursor with or without outline.
+56 Reserved - 0
+58 Reserved - 0
+60 Reserved - 0
+62 Number of blocks saved in the file (blank blocks at the
end of the 256 block store are not saved in the file)
+64 Reserved - 64 bytes of 0
There then follows the data for the blocks, each stored
as 16 lines from the top to the bottom, each line stored in
the same format as the ST's lo-res screen.
*.MAP -
The file consists of a 128 byte header followed by the
map data.
The header is constructed as follows ...
(All entries are of word length unless specified.)
+00 2 character string denoting the file version number,
currently '01'.
+02 Map X size in blocks (1-256)
+04 Map Y size in blocks (1-256)
+06 Map position pointer #0 X
+08 Map position pointer #0 Y
+10 Map position pointer #1 X
+12 Map position pointer #1 Y
+14 Current map position X
+16 Current map position Y
+18 Reserved - 110 bytes of 0
The map is stored as lines of bytes from the left to the
right, from the bottom line to the top line.
7.0 REVISION HISTORY
1.0 First 'release' version.
1.1 Line and circle draw function added.
1.2 Bug when map size >32k fixed.
1.3 Ability to copy map to back-screen and also save the
back-screen to disk. Insert and delete block function
made to change the map data accordingly.
1.4 Ability to replace all occurances of a block in the map
and also the use of a new front-panel screen.
1.5 Version number skipped to keep pace with EDSPR.
1.6 Ability to re-colour files into the current colour set.
1.7 Fat pixel mode at last.
1.8 Map re-size is now non-destructive.
1.9 File delete and default file extensions.
1.10 Format disc function added.
----
ELMER'S ATARI ST SPRITE EDITOR (EDSPR) VERSION 2.1
CRYPTIC INSTRUCTIONS
1.0 WHAT YOU GET FOR YOUR MONEY
This editor is designed for creating animated sequences
of sprites of up to 64x64 pixels in the ST's low resolution
16-colour mode. Limited support for sprites up to 192x192 is
available by chaining together a number of individual 64x64
images. The grabber supports sprites of up to 320x200 when
grabbing from an ST screen.
Sprites are created and edited as images on the 'GRID'
and then stored in the 'WORKSPACE'. This workspace holds up
to 64 images. A sprite grabber is provided to take the
finished animation sequences and put them into a more usable
form for the programmer. The grabber allows a table of up to
255 sprites to be created, with each individual sprite having
its own width and height, the option of masking data, and
from 1 to 4 bit-planes.
Suggestions for additional functions and/or changes to
the way the current ones work are welcome, provided that ...
a) they are written (without too much expletive),
b) they are not given to me on a Monday,
c) they are co-signed by the Pope or James Anderton.
2.0 HAVE A DRAG
The rubber-box and drag-box routines used in this
program work slightly differently to either GEM or the OCP
Art Studio. In this program you click the left or right
button to start off one of these functions and then click the
left button to confirm the operation, or the right button to
abort it. For example, in copying an area of a sprite you
use the rubber-box function to define the area. You firstly
click on a starting point, then move the mouse to define the
box size. If you press the right button after selecting a
starting point, you will be allowed to define a different
starting point, or by clicking the right button again, quit
the copy function totally.
3.0 SCREEN LAYOUT - EDITOR
The workspace editor screen is layed out in the following
fashion ...
222222222222 3333 4444 0 - text messages
222222222222 3333 4444 1 - foreground colour's RGB
222222222222 3333 4444 2 - edit grid x3 magnification
222222222222 3333 4444 3 - edit grid x1 magnification
222222222222 4 - global control icons
222222222222 555555555 5 - edit grid control icons
222222222222 555555555 6 - colour palette
222222222222 7 - workspace pointers
222222222222 666666666 8 - workspace position
222222222222 9 - workspace control icons
222222222222 777777777 A - image in workspace
222222222222 B - image in workspace
222222222222 88 999999
222222222222
222222222222 AAAA BBBB
222222222222 AAAA BBBB
AAAA BBBB
000000000 11 AAAA BBBB
Here are further details of what each area of the screen is
used for.
0 - This area normally holds the editor name and version
number. When the GEM file selector box is on the screen
during loading/saving this area will show what operation
the program thinks you want, i.e. LOAD WORKSPACE.
1 - This gives the red, green and blue content of the
currently selected foreground colour.
2 - This is the magnified image of the editing grid. All of
the actual drawing/filling/etc is done with the cursor
in this area.
3 - This is the normal-sized image of the editing grid. The
dragging of sprites to and from workspace uses this
image and not the magnified one.
4 - These are the icons for functions to do with loading and
saving and other manipulations of workspace.
5 - These are the icons for functions to do with the editing
grid and colour palette.
6 - This is the colour palette itself. The small bar above
the palette indicates the currently selected foreground
colour; and the one below, the currently selected
background colour.
7 - These are the four pointers into workspace; they allow
you to move quickly to previously selected positions in
the workspace. The last two (joined) pointers are also
used to mark the start and end positions for animation
and block operations.
8 - This is the number of the current position in workspace.
9 - These are the icons for moving the current position in
workspace.
A - This is the image stored at the current position.
B - And this is the next image. A blank image is stored
after the end of the workspace, so that when the current
position is the end of workspace, shown at 'A', then
this area will always show a blank.
3.1 SCREEN LAYOUT - GRABBER
The sprite grabber screen is layed out in the following
fashion ...
222222222222 3333 4444 0 - text messages
222222222222 3333 4444 1 - sprite table size
222222222222 3333 4444 2 - grab grid x3 magnification
222222222222 3333 4444 3 - grab grid x1 magnification
222222222222 4444 4 - global control icons
222222222222 5555 4444 5 - orgin movement icons
222222222222 6 - grab box position and size
222222222222 666666666 7 - colour palette
222222222222 8 - sprite control icons
222222222222 777777777 9 - workspace pointers
222222222222 A - sprite position
222222222222 8888 9999 B - workspace position
222222222222 88 C - workspace control icons
222222222222 A 88 B CC D - sprite
222222222222 E - workspace
222222222222 DDDD EEEE
222222222222 DDDD EEEE
DDDD EEEE
00000000 111 DDDD EEEE
Here are further details of what each area of the screen is
used for.
0 - This area normally holds the editor name and version
number. When the GEM file selector box is on the screen
during loading/saving this area will show what operation
the program thinks you want, i.e. LOAD WORKSPACE.
1 - This gives the current size of the sprite table in
bytes.
2 - This is the magnified image of the grabbing grid. What
is shown here is the current workspace image modified by
the current setting of the 'KILL COLOR BIT' option.
Sprites are grabbed off here and stored as 3 or 4 bit-
planes depending upon the setting of that control.
3 - This is the normal-sized image of the grabbing grid.
4 - These are the icons for functions to do with editing
that still apply in the grabber.
5 - These are the icons for moving the 'ORIGIN'. The origin
is provided so that when saving parts of an image, or
whole sequences of images, a common reference point can
be set up to help the programmer work out where to plot
these sprites in a game. These icons are also active
during the 'ANIMATE' function.
6 - This area displays either the current setting of the
origin, or the position and size of the grabbing box
relative to that origin, depending upon what the program
thinks you are trying to do.
7 - This is the colour palette, modified by the current
setting of the 'KILL COLOR BIT' option.
8 - These are the controls for moving around and deleting
sprites from the sprite store.
9 - These are the current settings of the animation sequence
pointers. They are for reference only and cannot be
modified in the grabber.
A - This is your position in the sprite store.
B - This is your position in the workspace.
C - These are the icons for moving around the workspace.
D - This is the sprite stored at the current position in the
sprite store.
E - This is the image stored at the current position in the
workspace.
4.0 DRAGGING IMAGES
Images are moved between the edit grid and workspace by
'dragging' them. This is done by clicking the left or right
mouse button on the sprite you wish to move, (at which point
a box will appear around the sprite) and then moving the
mouse to where you want the image to go, (with the box
automatically following) and then clicking the mouse button
again. In this way images can be moved between screen
sections 3, A, and B. The workspace pointers can also be
used as either the source or destination of such a move, with
the image going to/coming from the workspace position as
displayed by that pointer. The workspace pointers themselves
are altered by dragging the current position pointer (screen
section 8) to one of them; similarly the current position
pointer can be altered by dragging one of the workspace
pointers to it.
5.0 ICON FUNCTIONS
These functions are all labelled and explained, albeit
tersely by the on-screen help facility.
6.0 FILE FORMATS
*.WRK -
There are two different versions of the '.WRK' file
format. In both versions the file consists of a 128 byte
HEADER followed by a number of 2048 byte IMAGES; the only
difference between the versions is in the header.
The HEADER is constructed as follows ...
(All entries are of word length unless specified.)
Version 1 ...
+00 2 character string denoting the version number '01'.
+02 16 word colour palette in XBIOS SET_PALETTE format.
+34 Palette flag, 0=all 4 bit-planes, 1=clear plane 0, etc.
+36 Current foreground ink
+38 Current background ink
+40 Animation speed (delay count actually)
+42 Workspace position pointer #0
+44 Workspace position pointer #1
+46 Workspace position pointer #2 (first frame of sequence)
+48 Workspace position pointer #3 (last frame of sequence)
+50 Current workspace position
+52 X origin offset (0-63)
+54 Y origin offset (0-63)
+56 Fat pixel mode flag, 0=off, 1=on
+58 Cursor style (0,2,4,6), a dot cursor or a cross-hair
cursor with or without outline.
+60 Reserved - 0
+62 Reserved - 0
+64 64 byte bitmap, 1 bit for each of 512 possible workspace
images (the current editor only recognizes the first 64
entries). The bit is set if that image is stored in the
file, with byte 0 bit 7 representing workspace position
0, onwards to byte 7 bit 0 representing workspace
position 63.
Version 2 ...
+00 2 character string denoting version number '02'.
+02 16 word colour palette in XBIOS SET_PALETTE format.
+34 Palette flags (2 bytes), the current settings for the
flags to be stored in the sprite data (see version 3
'.SPR' file format below).
+36 Current foreground ink
+38 Current background ink
+40 Animation speed (delay count actually)
+42 Workspace position pointer #0
+44 Workspace position pointer #1
+46 Workspace position pointer #2 (first frame of sequence)
+48 Workspace position pointer #3 (last frame of sequence)
+50 Current workspace position
+52 X origin offset (0-63)
+54 Y origin offset (0-63)
+56 Fat pixel mode flag, 0=off, 1=on
+58 Cursor style (0,2,4,6), a dot cursor or a cross-hair
cursor with or without outline.
+60 Reserved - 0
+62 Reserved - 0
+64 32 byte bitmap, 1 bit for each of 256 possible workspace
images (the current editor only recognizes the first 64
entries). The bit is set if that image is stored in the
file, with byte 0 bit 7 representing workspace position
0, onwards to byte 7 bit 0 representing workspace
position 63.
+96 ???
The IMAGES are stored as follows ...
The data for each of the images stored in the file (i.e.
the 1 bits in the bitmap) are stored contiguously. Each
image is stored as 64 lines from the top to the bottom, with
each line stored in the same format as the ST's lo-res
screen.
*.SPR -
There are three different versions of the '.SPR' format
files. In versions '01' and '02' the format was designed for
use particularly with the ST, with version '02' being only a
rearrangement of version '01' in order to keep the users of
Ocean's in-house development system happy. Version 3 is the
current version, designed to be applicable across many
different computers.
The file consists of a HEADER, followed by an INDEX
TABLE with an entry for each sprite saved, followed by the
DATA BLOCK containing the actual data for the sprites.
The HEADER is constructed as follows ...
(All entries are of word length unless specified.)
Version 1 ...
There is an 8 byte header.
+00 2 character string denoting the file version number,
'01'.
+02 Number of sprites saved (0=none).
+04 Data size (total file size - header size). (LONG)
Version 2 ...
There is an 8 byte header.
+00 2 character string denoting the file version number,
'02'.
+02 Data size (total file size - header size). (LONG)
+06 Number of sprites saved (0=none).
Version 3 ...
There is an 8 byte header.
+00 1 character denoting the machine type; currently defined
types are '0' for the ST, and '1' for the Amiga. (BYTE)
+01 1 character denoting the version number, '3'. (BYTE)
+02 Data size (total file size - header size). (LONG)
+06 Number of sprites saved (0=none).
The INDEX TABLE is constructed as follows ...
Versions 1 and 2 ...
For each sprite saved there is an 8 byte entry.
+00 Palette flag, 0 if 4 bit-planes are saved, or 1-4 if
bit-plane 0-3 is missing.
+02 Stored X size - 1. (BYTE)
+03 Stored Y size - 1. (BYTE)
+04 Offset from start of sprite data to this sprite's data.
(LONG)
Version 3 ...
For each sprite saved there is an 8 byte entry.
+00 Extra flags. Bit 7 is set to indicate that masking
information is stored in the data. Bit 6 is set to
indicate that a blank extra word is stored at the end of
each line of the mask/data in order to facilitate the
generation of pre-shifted sprites. Bit 0 is the high bit
of the X size, allowing sprites of up to 512 pixels
wide. Bits 1-5 are reserved for future use. (BYTE)
+01 Bit-plane flags, bits 0-7 represent whether the
corresponding bit-plane appears in the data. (BYTE)
+02 Stored X size - 1. (BYTE)
+03 Stored Y size - 1. (BYTE)
+04 Offset from start of sprite data to this sprite's data.
(LONG)
The DATA BLOCK is constructed as follows ...
Versions 1 and 2 ...
The data block contains the data for each sprite,
arranged contiguously; i.e. the data for sprite 1 follows on
directly after the data for sprite 0. The data for each
sprite image is stored in rows, from the bottom of the sprite
to the top. Each row of the sprite is stored from left to
right. The pixels in each row are stored in blocks of 16
pixels like the ST's low-res screen, with each block starting
with a mask word, and followed by 3 or 4 words of data (as
given by the palette flag). Where the sprite is not a
multiple of 16 pixels wide, the data is padded out to the end
of the word. The mask word contains a '0' bit for each pixel
of valid data.
Version 3 ...
The format of the data block depends upon the machine
type given in the file header.
In type '0' files (for the ST) the data is arranged the
same as for version 0 files.
In type '1' files (for the Amiga) the data for each
sprite is arranged as seperate bit-planes, with all of the
data for a single mask or data bit-plane stored contiguously,
followed by all the data for the next bit-plane. The mask
plane contains a '1' bit for each pixel of valid data.
7.0 REVISION HISTORY
1.0 First 'release'.
1.1 Grabber altered to blank out parts of a sprite that have
been grabbed.
1.2 Magnify source image during a COPY AREA from the
workspace.
1.3 Line and circle draw functions added to the editor.
1.4 Ability to copy workspace to back screen and also save
the back-screen to disk.
1.5 Minor re-arrangement to .SPR file header (version '01')
and use of a new front-panel screen compatible with both
EDSPR and EDMAP.
1.6 Ability to re-colour files into the current colour set.
1.7 Sprite grabber can grab large sprites from the back
screen.
1.8 File delete and default file extensions added.
1.9 Grabber delete sprite bug found and fixed.
1.10 Format disc function added.
2.0 First major revision. Minor changes to the operation
and layout of the icons. Major changes in editing
flexibility.
2.1 More minor changes. Ability to read 16 colour IFF files.
----
ELMER'S ATARI ST MAP PROCESSOR (COMPUTE) VERSION 1.3
UNBELIEVABLY CRYPTIC INSTRUCTIONS
1.0 WHAT YOU GET FOR YOUR MONEY
This program has been designed to take a map file that
has been produced by 'EDMAP' and scan through it to determine
which blocks appear next to each other (for use in shifted-
block scrolling). As well as the processed map and block
list that are written to disk, the program can optionally
produce print-outs of the block list in a variety of useful
formats.
2.0 FILE FORMATS
*.MAP -
The file consists of a 128 byte header followed by the
map data.
The header is constructed as follows ...
(All entries are of word length unless specified.)
+00 2 character string denoting the file version number,
currently '01'.
+02 Map X size in blocks (1-256)
+04 Map Y size in blocks (1-256)
+06 Map position pointer #0 X
+08 Map position pointer #0 Y
+10 Map position pointer #1 X
+12 Map position pointer #1 Y
+14 Current map position X
+16 Current map position Y
+18 Reserved - 110 bytes of 0
The map is stored as lines of bytes from the left to the
right, from the bottom line to the top line.
*.DAT -
The file consists of a 10 byte header followed by two
variably sized blocks of data.
The header is constructed as follows ...
(All entries are of word length unless specified.)
+0 Long-word header of $00000000 if 8-bit map data, or
$FFFFFFFF if 16-bit map data.
+4 Number of shifted blocks
+6 Map width in blocks
+8 Map height in blocks
Then follows the processed copy of the original map
using the new shifted-block numbers. If the WRAP option is
set then the map will wrap correctly otherwise the last block
on each line is just a repeat of the previous block. The map
can be saved using either byte or word entries.
+A Map data
Then follows the shifted block list. Each entry in the
list is comprised of the original block numbers of the LHS
and RHS blocks, 1 byte each. The shifted blocks are
numerically sorted into ascending order, to facilitate
collision detection.
+n Shifted block list
|
| | |
Ocean Software's internal sprite editor written for Atari ST development system. Includes EDWRK / EDSPR sprite-editor, EDMAP map-editor and in later releases COMPUTE map processor. Release 3.0 is the last known version with a title EDWRK.
It was used at least for WEC LeMans (ZX Spectrum), Chase HQ (ZX Spectrum, Amstrad CPC), Batman The Movie, Operation Wolf, Rambo III (16-bits) and others.
If you look at the Ocean games disks with unpacked file extensions SPR, WRK, BLK and MAP you can actually load up and edit sprite and gamemap data with this editor.
|
| | | | |