http://www.appleoldies.ca/bmp2dhr/sprites/
Here's some excerpts...
The DHR (Double Hi-Res Raster) Image Format
The Sprites (and optional black and white Sprite Masks) produced by Bmp2DHR
are in my XPACK program's DHR format, but XPACK only produces Full Screen
DHGR images so this is something new.
The Sprites produced by Bmp2DHR have an extension of DHR. (Sprite masks have
an extension of DHM.) Like A2FC and AUX, BIN file pairs, they are stored on
an Apple II Disk as ProDOS FileType $06 with an Auxiliary Type of $2000 or
$4000 by default. On a DOS 3.3 disk they are stored with header information
required by DOS 3.3. Use command option "DOS" if you need these DOS 3.3
headers pre-pended to your DHGR output file(s).
The Header of a DHR (or a DHM) is in two parts;
3 bytes of ID data with the letters 'D', 'H', 'R' (or 'D','H','M') in
upper-case.
1 byte - width in bytes (multiples of 4 bytes - 7 pixels)
1 byte - height in rasters
The DHR is a raster based image with scan-lines of raw DHGR data alternating
between auxiliary and main memory. Therefore a BASIC program cannot load
these any easier than in a C program, since the DHGR screen is interleaved
the same way that the HGR screen is interleaved and not linear, so a
considerable amount of supporting code is required. Bank switching between
auxiliary and main memory banks 0 (main board) and 1 (language card) is also
no easier in a BASIC program than in a C program.
For a full-screen DHR, there are 192 pairs of linear rasters, each of 40
bytes of auxiliary memory data followed by 40 bytes of main memory data.
Splitting the rasters into pairs keeps bank switching to a minimum while
still allowing for linear reading and display from disk or buffer. Because
of the way DHGR's interleaf works, there is no faster way to load a screen
fragment.
The full screen DHR loads raster by raster and displays as quickly as a
buffered read can display on the Apple II. At 15365 bytes per screen this
format provides a modest disk space saving over the 16384 bytes of the A2FC
or AUX, BIN equivalent.
As mentioned earlier, a caveat for any file in DHR raster format is the 4
byte / 7 pixel pattern of the DHGR display. The width descriptor in the
header is given in byte width rather than pixel width. Image fragments in
DHGR must necessarily be aligned on 4 byte boundaries to display properly.
Bmp2DHR pads DHR formats as required in an optional background color if
desired.
By comparison, HGR image fragments (in my RAG format and not currently
produced by Bmp2DHR) are aligned on 2 byte boundaries for proper display but
they are still somewhat recognizable if not aligned properly. If DHGR image
fragments are not aligned on 4 byte boundaries they are a mess.
Including Load Position in the ProDOS Filing System
If a programmer wanted to load these according to a specific position on the
DHGR display, it would be possible to give the starting scan-line and
starting byte to the desired position on the screen, and store that as the
Auxiliary Type instead of the load Address of 0x2000 or 0x4000 which is
meaningless for an image fragment:
The program would read the header and perform a file integrity check to
ensure that the file size was as expected.
Part of the verification would also be to determine if the Auxiliary Type
fell within the DHGR visible screen boundaries and if the file itself would
fit.
Having satisfied this requirement the image fragment could be positioned at
that point by the program.
Doing so would save disk-space and load time when constructing a pre-planned
screen in a DHGR program, since full-screens are larger by comparison to
creating full-screens from fragments especially if blank screen space is
plentiful.
Background Color - Command Option "B"
Image Fragments can be used for continuous tone input files like digital
photos and complex images, or for "hand-made" pixel art like Sprites for
game programming and animation. Of course this is a generalization of sorts.
However, if animating a Sprite over some kind of background is "your thing"
then you will likely want to provide Bmp2DHR with a background color (a
transparent color). The default background color in Bmp2DHR is black. This
can be changed to any of the other 14 or 15 DHGR colors using command option
"B" followed by a DHGR color name or number.
The color numbers in Bmp2DHR follow the "Lo-Res Color Order", just like
Beagle Graphics used in their DHGR Patterns image, shown displayed below in
Sheldon Simms tohgr DHGR NTSC color conversion palette, which is also
Bmp2DHR's default palette (P5). The only output from Bmp2DHR that does not
follow the Lo-Res color order is VBMP output. I also follow the Lo-Res color
order in my cc65 demo programs, and everything else that I have written for
DHGR.
Regards,
Bill