In the early days if you were going to present photographic images (.BMP or .JPG files) I recommended
using 16 bit 65535 RGB color modes, even if you had successfully managed to scan
them into 8 bit 256 color bitmaps however these days (2018) almost all displays
are going to be 24 bit RGB display modes and most all of this first topic's
points are moot. The reason being that the windows GDI palette manager is going to get it's hands on those 256 colors and squeeze them into either 254 or, worse, 236 colors (I never bothered to figure out the interaction between DirectX and GDI w.r.t. palette management, 16 bit color is too easy to use). If you really need the speed of 256 color mode (65535 is not all that much slower on old cards and 256 color mode is actually slower on some of the new cards) or, more to the point, your graphics card does not have enough memory to handle 65535 colors (in which case I recommend you go and buy one that does have enough memory to handle 65535 colors) and you must have photographic images then to avoid the GDI palette manager's distortion you will have to find a way to make the image leave free (or include) the 20 colors that windows usually reserves for it's use -- maybe PhotoShop can do this, I don't know, I doubt whether the Graphics Workshop can do it.
To make matters worse, if you are using 256 colors and you wish to present more than one image per item you will have to go to some considerable effort to make sure that those images use the same colors, in fact, they should have identical palettes. This is because the palette manipulation schemes used in DMTG are no longer possible in DMDX. With a 256 color mode display if I could figure out how to get GDI to change the palette the palette would be changed when that image was loaded, before the item is displayed, in effect all images displayed will be displayed with the palette used for the last bitmap displayed. As DMDX stands right now whatever palette happens to be in use before DMDX is run is the palette that is used for everything. So if you change the desktop background you can dramatically alter the way photographic images are rendered when using an 8 bit, 256 color display. On the other hand in 65535 color mode you just load 'em up and display 'em, no worries, the worst that happens is that Red and Blue color depth are halved (and if that's a problem then make the images in 24 bit colors and display them in 65535 colors and if that still doesn't do it, you can buy an 8Meg video card and use 24 bit color displays too -- but all of these points are splitting hairs, really fine ones).
All this does not mean that you can't use 256 color images to save disk space and display them with 65535 colors, this works quite nicely as long as the image looked OK in 256 colors it will be almost unaltered displayed in 65535 colors (and one third the size of 24 bit images, the next jump up from 8 bit, at least as far as files are concerned, for some reason 16 bit .BMP files either don't exist or the programs I have don't support them, or if they do I haven't found out how they do). Of course with DMDX now supporting the Independent JPEG Group's JPEG compression routines using a .JPG file will be much more economical than any .BMP file.
A rather cool thing is the ability to make the background of a bitmap transparent using a feature of DirectX called Color Keying. A graphic frame with the <ColorKey> switch set will examine the color of the top left pixel of the bitmap and when adding that graphic to the displayed frame all pixels of that color will not be copied. Especially handy if you have changed the background color or your bitmaps do not have a white background.
If you are importing large numbers of .IMG files from DMTG using IMG2BMP.EXE you will not need to stretch the images using some other image manipulation program, DMDX can do it with the <DefaultBMPMultipliers> switch, typical values for stretching EGA images being <dbm 1.0,1.371>.
Stretch Blt modes.
For the longest time whenever you wanted to scale a
bitmap smaller with the bitmap multipliers you could get some fairly ugly
artifacts until I stumbled across the win32
and nowadays you put something like
<dbm 1 HALFTONE> in your item
file and down scaled bitmaps are just fine. Up scaled bitmaps have always
been more or less fine (beyond the obvious fuzziness issues that are inherent in
magnifying data). Why is this important? If you want to build an
item file that runs on a number of machines that uses bitmaps and you want a
fairly consistent experience from one machine to the next you'll want to provide
higher resolution bitmaps that you scale down using a fraction of the screen's
dimensions otherwise depending on the screen resolution on the machine the sizes
of the bitmaps will change (assuming you're using
<vm desktop> and these days you
really should be using it, the days of being able to run everything at a fixed
display resolution are all but past).
Speaking of making an item file running on multiple machines
with scaling bitmaps you'd probably also want to know the aspect ratio of the
screen your item file is running. Maybe you can get away with assuming a
16:9 widescreen device regardless of it's resolution and scale those bitmaps
down to a fraction of the screen width nicely but if not in the past you'd have
been stymied pretty good, however these days you can actually detect the aspect
ratio using the expression tokens VideoModeX
and VideoModeY (see the
help). You've got two choices here, one (as long as the aspect ratio of
all your images is the same, if not see the second option) is to detect the aspect
ratio like the
<Instruction> help does and then passing one of two macros (one
for 4:3 screens and another for 16:9) to
all your <bmp> keywords that determines the
upper left and lower right corners for your bitmaps. The other option
involves knowing the size of each bitmap which is perhaps more labor intensive
(unless of course they're all the same) but is less prone to accidentally
distorting an image as it involves using the
bitmap multipliers that carefully
preserve image aspect ratios. Here you'd have to use two items per
presentation, one to set up a macro that has the scaling factor for that that
image and one to display it using the macro in a <bm>
keyword. Actually to handle images that are smaller than the intended
display area you'll need two macros as DMDX counters are all integers, no
floating point stuff available so we'll fudge it with with 4 digit fixed point
calculations). In the following example the bitmap being displayed is 2048
pixels high and we're aiming to display it as half the screen height:
~1 <set c1 = (videomodey * 10000 / 2048) / 2>
<macro set u = c1 / 10000> <macro set f = c1 % 10000>;
+101 <bm ~u.~f
halftone> <bmp> "image" * ;
Another cool thing is the ability to alpha blend two (or more) frames together
-- although this looks busted these days and is explicitly unavailable when
using the Direct3D renderer. An alpha blend adds two frames together as transparencies, a succession of frames with alpha values changing from 1.0 to 0.0 in small increments will fade from one frame to the next. As with all DMDX color things a 16 bpp (bit per pixel, 65535) color mode is nearly essential. It works with all types of frames with the likely exception of Digital Video frames regardless of how many colors or what was used to make the frame. It is fairly CPU intensive to prepare (I have not written a very efficient algorithm, it does however work with everything), check your preparation times if you intend to use REQSHED or the D parameter. To blend from the word "first" to the word "second" in 6 steps the following item would be used:
0 "first" <as> / <ab .8> "second" / <ab .6> "second" / <ab .4> "second" / <ab .2> "second" / "second";
The first frame's switch <as> (or <AlphaSource> if you like) causes it to be stored as the alpha source for all following blends in that item, after that it is discarded, you can't blend across items. The next four frames will be a combination of the words first and second and the last frame is only the word second, <ab 0> being equivalent to no blending. Each frame is generated in the normal fashion and then blended with the surface that was stored with the most recent <as> switch -- they are not blended with the previous frame (and if you put non-erase switches in very odd things would happen). An interesting thing to note with only four steps in the blend is that this could be displayed by a 256 color display as the default windows palette contains four shades of gray -- however four steps is a pretty crude blend, a much better instance that requires a 16 bpp display is:
0 "first" <as> / <ab .95> "second" / <ab .9> "second" / <ab .85> "second" / <ab .8> "second" / <ab .75> "second" / <ab .7> "second" / <ab .65> "second" / <ab .6> "second" / <ab .55> "second" / <ab .5> "second" / <ab .45> "second" / <ab .4> "second" / <ab .35> "second" / <ab .3> "second" / <ab .25> "second" / <ab .2> "second" / <ab .15> "second" / <ab .1> "second" / <ab .05> "second" / "second";
An interesting thing to note is that you can store a new alpha source in any frame leading to the ability to blend a bit to one word and then change to a new word (whether anyone would ever want to do this is another thing).
Image Loading time issues.
If people require the fastest possible loading of bitmap displays for low ISIs (usually because they are using continuous running with an FMRI image sequence) they should convert their bitmaps to 256 color .BMP files, however they should still use a 16 bit display, or possibly a 24 bit display. Because the image is displayed on an RGB surface the fact that it's encoded as a 256 color
palletized surface doesn't matter, no changing of colors to match a system palette occurs (some changing does occur as a 16 bit surface is 5 bits of red, 6 of green and 5 of blue whereas a 256 color palette has 6 of everything but that's trivial or if it does matter use a 24 bit display mode) and because each image is encoded separately the palette for the image can be super fudged by the conversion program to match the colors in the image and it's impressive what a bit of dithering will achieve. 800x600 8 bit .BMPs load in 50ms on my test bed (preparation A times) vs. 150ms for 24 bit .BMPs vs. 300ms to 600ms for .JPGs. All have a preparation B time of about 40ms (the time to make a DMDX frame out of them once loaded into memory).