Universal DOS/Windows game engine.
Project aims at providing portable library to write universal DOS/Windows applications, including games. So it's similar to SDL or Allegro. But! The biggest difference - you don't even need to recompile your code to run it on other platform! Binaries themselves are portable! What it means? If your code works on Windows - it will also work on DOS. It's great feature for debugging. You can debug your code via using modern comfortable Windows tools, not obsoleted DOS ones. All extremely hard zero-debugging code writing is already done for you by me. Great? Yeah!
Demos:
License:
Software can be used for free for personal non-commercial purpose only. Any purpose, that involves explicit or implicit revenue, including indirect one (in case of budget or government organizations, educational purposes, etc.) - is allowed only after buying commercial license.
Any form of reverse-engineering is forbidden, including but not limited to debugging, decompiling, disassembling.
License philosophy:
Programmers should be professionals, not just enthusiasts, who have to provide unrelated services in order to earn money. If one uses my work to earn money - then he should share part of his revenue with me. If you earn money via clogging nails, then why do you think hammer should be free for you? Buy it! I've put my effort into making tool for you to earn money. And it's like law of energy conservation. Every drop of sweat should pay off. It's not fair, if some tool is used to earn billions of dollars, while it's author should be enthusiast, who can count on sporadic donations only. This includes new threat - AI. For now it isn't well regulated. Free projects can be used for AI training, that can be treated as commercial educational purposes, as goal of such training - is to earn profits then, while devaluing initial author's effort.
Warranty disclaimer:
You use this software at your own risk. It's provided "as is" without any express or implied warranty of any kind, including warranties of merchantability or fitness for any particular purpose. Author isn't liable for any direct, indirect, incidental, special, exemplary, or consequential damage, caused by using this software.
Please note! If you want to launch game's exe directly - then copy Data directory to exe's directory. Please remember, that Game.exe doesn't contain HX stub! You should install HXLDR32.EXE as TSR before trying to run Game.exe.
System requirements:
DOS: Same as for HX, i386, DOS 5.0.
If you don't have extended memory - use SET DPMILDR=2 environment varaible.
Warning! If you want to complie your application as GUI one, you need modified version of DPMILD32.exe - one compiled with ?NOGUIAPPS=0 and ?ALLOWGUIAPPS=0 options.
Windows: Any Win32, including Windows 3.x + Win32s installed and Windows NT 3.x, Windows 9x/NT 4.x are recommended.
For now only GDI is supported.
Warning! Since SP4 WinNT 3.51 has bug: some sort of race condition while initializing Kernel32.dll. Game.exe crashes with error 0xc000142 in Kernel32.dll.
Possible workarounds:
- Don't use Launcher.exe. Copy Data directory to Bin32 and launch Game.exe directly.
- Try to change command line length via adding arbitrary string to it's end.
Game.exe controls:
- Arrow keys - move bitmap.
- WASD - move bitmap mask.
- R - reset bitmap mask.
- B - toggle text background: transparent, extent (red), width (blue).
- C - toggle per-pixel copy testing.
- Mouse - cursor and mouse buttons state.
Global options:
Mode filtering:
First matching mode is picked. Mode conflicts can possibly happen, when modes are listed by external routines (like in case of SVGA). But video driver should have extra options to solve such conflics.
- Width, pixels, 0 - unspecified, any value match
- Height, pixels, 0 - unspecified, any value match
- Frequency, Hz, 0 - unspecified, any value match
- Pixel format, exact value matched first, meta format matched then. Meta formats make life easier. They allow matching bpp only, i.e. picking video-card specific modes like 4bppV or 4bppE via simply specifying 4bpp. Please note. While some drivers allow some sort of "better modes lised first" priority, others don't, like SVGA one for example.
- Compatibility. Safety measure, that filters out modes, that can be potentially dangerous to use. Set higher values at your own risk! Set lower values, if you have problems.
Mode options:
- VSync, exact value, fails if unsupported
- SwapEffect, exact value, fails if unsupported. Flip must be supported by hardware. In all other cases support depends on amount of video and system memory availiable. Falls back to SM variants, if not enough video memory available. There are just two possible cases from game's point of view: copy and flip. Game's rendering behavior is different depending on which one is chosen. It recommended to support both.
- Buffering, falls back to corresponding lower value, if unsupported. Used in modes, where direct rendering to video buffer can cause glitches or can even be unsupported. Overall logic - higer value = better quality, but slower rendering. As swap effect is transparent for video driver (i.e. swap effects aren't hardcoded), it can't determine, if some buffering mode is more effective than other. It's up to user to do it. Buffered variants are only available, if video card has enough video memory.
Modes supported:
DOS:
For all modes: VSync, NoDoubleBuffer, Copy, Swap, TripleBufferSwap, SMCopy, SMSwap and SMTripleBufferSwap are supported, if opposite isn't stated explicitly.
Please note!: Dynamic - mode, for which mode info is calculated on fly. If mode matches standard one - it's unmodified and marked as Standard. All modes support VSync, but Flip and TripleBufferFlip support can be specific to every mode. If there are duplicate modes, like 320x200x70x8 and 320x200x70x8X, that both can be picked via demanding unmodified 8bpp format - first one always has priority. Second one is picked only if first one is filtered out by some other parameters. So 1bpp CGA mode can only be choosen via specifying 1C format explicity. Only "fullsceen" modes are supported. While any mode down to 8x1 is actually possible, if mode timings don't match standard ones - only part of screen is occupied, that is pointless feature.
Dual display support: Engine can't render to both adapters at the same time now. But dual display setup is supported to some degree. Adapter is detected, no matter if it's active or not. But it most likely wouldn't operate properly, if it wouldn't be made active. Enigne itself doesn't do it now. So for now it's recommended to make adapter active manually before starting any application, that uses Engine.
MDA.drv
- 160x25x50x1M
- 160x25x50xMM
VSync is unsupported.
HGC.drv
- 160x25x50x1M
- 160x25x50xMM
- 720x348x50x1H, Flip is supported
Use ModeConfig option to control, whether half or full mode is used. Full mode can't be used, if color video card is installed due to memory address conflict. Following modes are supported:
- Detect. Use half mode, if color video card is present, use full otherwise.
- Force half mode. Use, if color video card isn't autodetected correctly.
- Force full mode. Use, if no other video card is present or if it doesn't work in text mode.
CGA.drv
- 640x200x60x1C
- 320x200x60x1C
- 4T, Dynamic, 80x25..160x100
Horizontal resolutions 320 and 640 are supported with divisor 4. Vertial resolution 200 is supported with divisors 2..8. Values are rounded down to closest integers. Please note: only 2, 4 and 8 divisors use Standard timings - others require Compatiblity to be set to Experimental!
EGA.drv
- 1P, Dynamic, 280x6..720x350
- 1C, Dynamic, 280x200..720x350, restricted by CGA's limitations (see below)
- 1H, Dynamic, 280x200..720x350, restricted by HGC's limitations (see below)
- 1EW, Dynamic, 280x6..720x350
- 1M, Dynamic, 70x6..180x350, if enough video memory (MDA only), affected by Mono limitations (see below)
- 1T, Dynamic, 70x6..180x350, if enough video memory
- MP, Dynamic, 280x6..720x350
- ME, Dynamic, 280x6..720x350
- MC, Dynamic, 280x200..720x350, restricted by CGA's limitations (see below)
- MH, Dynamic, 280x200..720x350, restricted by HGC's limitations (see below)
- MEW, Dynamic, 280x6..720x350
- MM, Dynamic, 70x6..180x350, affected by Mono limitations (see below)
- MT, Dynamic, 70x6..160x350, if enough video memory
- 2P, Dynamic, 280x6..720x350
- 2E, Dynamic, 280x6..720x350
- 2C, Dynamic, 280x200..720x350, restricted by CGA's limitations (see below)
- 2H, Dynamic, 280x200..720x350, restricted by HGC's limitations (see below)
- 2EW, Dynamic, 280x6..720x350
- 2M, Dynamic, 70x6..180x350, if enough video memory, affected by Mono limitations (see below)
- 2T, Dynamic, 70x6..180x350, if enough video memory
- 4E, Dynamic, 280x6..720x350
- 4T, Dynamic, 70x6..180x350, if enough video memory
Testing needed!!! Non standard modes' setting are based on several guesses due to lack of enough mode examples in EGA's VMT. These guesses should be verified. How testing should be performed: 1) Select standard video mode with corresponding resolution - 640/320 for 560/280 in case of EGA 350 modes and 640/320 for 720/360 in case of CGA 200/MDA 350 modes. 2) Note picture position. 3) Select non-standard video mode. 4) Is picture garbled? 5) Is there >4 offset to the left/right? 6) Make screenshots/videos.
Please note!!! Video capture equipment and EGA->VGA converters may not be suitable for such tests due to possibility of ignoring sync signals and locking to picture instead! Proper syncing tests are required and therefore using real CRT monitor is recommended!
Resolutions listed above represent minimal and maximal possible horizontal and vertical resolutions. Not all resolution combinations are available! Availability of specific resolution combinations depends on monitor type. Horizontal resolutions 560, 640 and 720 are supported with divisors 1, 2, 4. Vertical resolutions 200 and 350 with divisors 1..32 in EGA graphic modes, 200 with divisors 1..32 in CGA graphic modes, only 350 in MDA graphic modes, 200 and 350 with divisors 1..14/31 in EGA text modes, 200 with divisors 1..8/31 for CGA in text modes and 350 with divisors 1..14/31 for MDA in text modes (depends on CharGenLoadMode setting: enabled - 31, disabled - 14/8, depends on HeightRoundMode). Limited to 31 in text modes due to underline. Only way to hide it - to set it's position to 32. Thus fonts can't have 32 rows. Only 31.
Different amounts of video memory are supported. Amount of memory affects number of pages avilialbe. Modes, that require more than 64Kb VRAM (640x350 for example) are special case. If video card has only 64Kb VRAM installed - these modes can be no more than 2bpp only.
CGA and HGC modes are special case. Only divisor 2 is available for both horizontal and vertical resolutions. Vertcal resolution is limited by three factors: max bank size, max number of banks, max number of lines per bank. Max bank size is always 8Kb. For CGA max number of banks is 2, for HGC - is 4. If CGALineLimit mode is enabled, only 128 lines per bank are avalable. Vertial resolution is affected by HeightRoundMode. If HeightRoundMode is round down, then Height = Height - (Height mod Banks). For example it would mean 348 lines instead of 350 in case of HGC mode. MemoryRemapMode doesn't affect resolutions - only number of pages available.
Mono text modes require Mono attribute support in Attribute Controller. According to information from Internet, it isn't always implemented. Some documentation claims, that it has never been implemented. But some, like Cirrus Logic one, claims opposite. If it isn't implemented, some attributes can be treated wrong way. For example 78h should have "dark" foreground. But if this attribute is treated as color one instead, foreground becomes "light". It isn't so noticeable in MM mode, but colors looks like they're reversed in 2M mode. Another question - if supported, do Mono attributes bypass Attribute Controller and/or DAC palettes? DAC palette shouldn't be bypassed. It's just impossible. But we can't be so sure about Attribute Controller's one. At least BIOS loads proper palette into Attribute Controller, that looks like only bits 0 and 3 are used. As always, we try to load universal palette, that would work in any case - even if all bits would be used.
VGA.drv
- 1P, Dynamic, 160x5..720x480
- 1C, Dynamic, 320x200..720x480, restricted by CGA's limitations (see below)
- 1H, Dynamic, 320x200..720x480, restricted by HGC's limitations (see below)
- 1EW, Dynamic, 320x5..720x480
- 1VD, Dynamic, 320x5..720x480
- 1M, Dynamic, 80x5..180x480, if enough video memory, affected by Mono limitations (see below)
- 1T, Dynamic, 80x5..180x480, if enough video memory
- MP, Dynamic, 80x5..180x480, if enough video memory
- MV, Dynamic, 320x5..720x480
- ME, Dynamic, 320x5..720x480
- MC, Dynamic, 320x200..720x480, restricted by CGA's limitations (see below)
- MH, Dynamic, 320x200..720x480, restricted by HGC's limitations (see below)
- MVW, Dynamic, 320x5..720x480
- MEW, Dynamic, 320x5..720x480
- MVD, Dynamic, 320x5..720x480
- MM, Dynamic, 80x5..180x480, if enough video memory (Mono only), affected by Mono limitations (see below)
- MT, Dynamic, 80x5..180x480, if enough video memory
- 2P, Dynamic, 80x5..180x480, if enough video memory
- 2V, Dynamic, 320x5..720x480
- 2E, Dynamic, 320x5..720x480
- 2C, Dynamic, 320x200..720x480, restricted by CGA's limitations (see below)
- 2H, Dynamic, 320x200..720x480, restricted by HGC's limitations (see below)
- 2VW, Dynamic, 320x5..720x480
- 2EW, Dynamic, 320x5..720x480
- 2VW, Dynamic, 320x5..720x480
- 2M, Dynamic, 80x5..180x480, if enough video memory, affected by Mono limitations (see below)
- 2T, Dynamic, 80x5..180x480, if enough video memory
- 4V, Dynamic, 320x5..720x480
- 4E, Dynamic, 320x5..720x480
- 4H, Dynamic, 320x200..720x480, restricted by HGC's limitations (see below)
- 4W, Dynamic, 320x5..720x480
- 4T, Dynamic, 80x5..180x480, if enough video memory
- 4P, Dynamic, 320x5..720x480, if enough video memory
- 8P, Dynamic, 160x5..360x480, if enough video memory
- 8D, Dynamic, 160x5..360x480, if enough video memory
- 8R, Dynamic, 160x5..360x480, if enough video memory
- 8X, Dynamic, 160x5..360x480
- 8XD, Dynamic, 160x5..360x480
- 8XR, Dynamic, 160x5..360x480
- 8H, Dynamic, 160x200..360x480, restricted by HGC's limitations (see below)
- 8HD, Dynamic, 160x200..360x480, restricted by HGC's limitations (see below)
- 8HR, Dynamic, 160x200..360x480, restricted by HGC's limitations (see below)
Horizontal resolutions 320, 640, 360, 720 are supported with divisors 1, 2, 4. Vertical resoutions 350, 400, 480 are supported with divisors 1..64 (even values only, if >32) in graphic modes and 1..8/14/16/62 in text modes (depends on CharGenLoadMode setting: enabled - 62, disabled - 8/14/16, depends on CharGenFontMode/CharGenMonoMode, depends on HeightRoundMode). Limited to 31 in text modes due to underline. Only way to hide it - to set it's position to 32. Thus fonts can't have 32 rows. Only 31. ScanLineDouble bit, that is used by CRTC for CGA emulation, can double this value. Thus, max divisor is 62 in text modes. Don't forget to set Compatiblity to Experimental for 360/720 modes!
CGA and HGC modes are special case. Only divisor 2 is available for both horizontal and vertical resolutions. Vertcal resolution is limited by three factors: max bank size, max number of banks, max number of lines per bank. Max bank size is always 8Kb. For CGA max number of banks is 2, for HGC - is 4. If CGALineLimit mode is enabled, only 128 lines per bank are avalable. Vertial resolution is affected by HeightRoundMode. If HeightRoundMode is round down, then Height = Height - (Height mod Banks). For example it would mean 348 lines instead of 350 in case of HGC mode. MemoryRemapMode doesn't affect resolutions - only number of pages available.
Mono text modes require Mono attribute support in Attribute Controller. According to information from Internet, it isn't always implemented. Some documentation claims, that it has never been implemented. But some, like Cirrus Logic one, claims opposite. If it isn't implemented, some attributes can be treated wrong way. For example 78h should have "dark" foreground. But if this attribute is treated as color one instead, foreground becomes "light". It isn't so noticeable in MM mode, but colors looks like they're reversed in 2M mode. Another question - if supported, do Mono attributes bypass Attribute Controller and/or DAC palettes? DAC palette shouldn't be bypassed. It's just impossible. But we can't be so sure about Attribute Controller's one. At least BIOS loads proper palette into Attribute Controller, that looks like only bits 0 and 3 are used. As always, we try to load universal palette, that would work in any case - even if all bits would be used.
Mono monitor support doesn't require any special actions - it's supported by BIOS internally.
Mono modes are handled differently. There are 3 possible variants:
- Single - all modes listed above are supported, Mx modes are emulated due to collision between color and mono implementations.
- Dual color - Mx modes are emulated, MM modes are unsupported.
- Dual mono - only Mx and MM modes are supported.
EGAVGA.drv shared options:
CharGenLoadMode option:
- Enabled only if necessary (>8/14/16 lines)
- Force enabled (even for standard modes) - use in case of problems with default character generator
- Force disabled (disables modes, that require it) - use in case of compatibility problems with character generator load code
HeightRoundMode option:
- Round up, preserves vertical resolution, but last line may be cut
- Round down, vertical resolution may decrease, but all lines have the same height
MemoryRemapMode option:
- Disabled - default mode is used
- Force 128Kb, no dual monitor
- Force 64Kb color
- Force 32Kb mono
- Force 32Kb color
Plase note. Default mode is chosen according to base video mode. And base video mode is chosen to achieve necessary target video mode via minimal amount of reprogramming. This is needed for compatibility purposes. Non-standard video cards can use non-standard settings, we may not know anything about. It's better to set the most appropriate base mode and tweak it then. As side effect - 8bpp CGA/HGC modes no longer use 32Kb color mapping by default. They use 64Kb color one. Other ones use standard BIOS settings.
Special note about 128Kb mode. VRAM size >64Kb can be achieved via plane merging only. Therefore this mode requires at least Odd/Even (aka Chain2) video mode. I'm not sure about Chain4, but we can guess, that it should work too. According to IBM EGA Manual, it also requires >64Kb VRAM. It's self-obvious requirement anyway, as 64Kb VRAM would never exceed 64Kb address window. Therefore - this mode is useless in case of 4bpp planar modes (and also "emulated" 1bpp, Mono and 2bpp planar modes). It only works in text, 2bpp CGA/HGC and (theoretically) 8bpp packed pixel (including 4bpp packed pixel) modes.
CGALineLimit option:
- Enabled - 128 lines per bank max, compatible with standard CGA modes
- Disabled - not limited, any number, that would fit into 8Kb bank, allows some modes, like CGA 320x400 1bpp (200 lines per bank)
CharGenFontMode option: Controls, what text modes are considered to be base stanard ones to be modified. It's important, because this setting affects CharGenLoadMode and Compatibility settings. Choosing wrong settign may cause garbled picture or wrong mode selection. Certain font height can be: assumed, forced, detected. Unless you'd change font height purposely, it's safe to assume it to be 8x16 to avoid unnecessary API calls. VGA info only detection method is unreliable on IBM VGA, because IBM VGA uses 8x8 font bit only as temporary storage when color->mono mode switching. It's value can be lost in case of mono->color mode switch. It's unused, if secondary adapter is present, as color<->mono mode switches are impossible in this case. It's reliable in single adapter mode only and only if color modes are used. But it can be reliable in later BIOSes and emulators, that assume wrongly documented behavior.
CharGenMonoMode option: IBM VGA-specific option. IBM VGA has very specific behavior, when performing color<->mono switches. 8x14 font is forced in mono modes, if 8x16 font isn't choosen. Problem is - video card can be in color mode, when font height is detected via CharGenFontMode. Therefore we should fall back to 8x14, if 8x8 is selected or detected, but mode selected is mono one. Later BIOSes may allow 8x8 in mono modes. Especially emulators. Simply because this behavior isn't documented well enough.
CharGenRestoreMode: Font height is global settings. It isn't restored automatically, that can cause other programs to operate wrongly. Use this setting to control, how font height setting is restored, when VGA driver is uninited. You can: do nothing, force certain height, restore previously detected value. Unless you'd change font height purposely, it's better to use "Don't restore" option in order to avoid unnecessary API calls.
SVGA
Following options are common for all SVGA drivers:
If no direct color info is provided by BIOS, following options can be useful:
- Force15bpp: Non-standard modes only. Some old BIOSes may support 15bpp modes only, but report them as 16bpp. For example VBE 1.2 standard states, that VBE 1.0-1.1 BIOSes do it. Set this option to Enabled in this case.
- Force32bpp: Standard modes only. Standard VESA modes should be 24bpp, as stated in VBE standard. But some old video cards may support 32bpp instead. Set this option to Enabled in this case. As scanline lenght is most like different for 24bpp and 32bpp modes, Guess option can be used to try to guess supported format.
- ForceBGR: Both standard and non-standard modes. Even rarer case. Not sure, if such video cards exist. Video card supports BGR formats instead of RGB. Set this option to Enabled in this case.
Compatibility options:
- DisableVGAIO: Disable features, that require direct access to VGA IO ports - planar modes, VSync.
- DisableVGABIOS: Disable features, that require VGA BIOS calls - set palette, set blink in text modes.
- DisableVGATTY: Disable features, that require VGA TTY calls - hide cursor in text modes.
- DisableDirectBankSwitch: Don't use bank switch procedure, provided by 4F01h - force BIOS calls.
- PagesAvailable: 0 is default - it's the best option. Falls back to other values, if some information isn't available. Change it in case of problems - if BIOS provides faulty information about total video memory size, number of planes or number of pages.
Flip requires VBE 1.1. Extended mode info is mandatory since VBE 1.2. Buffering has effect in planar modes only. Fastest buffering can be used if SwapEffect is flip. Buffered variants require Window B to be available. Some performance optimizations are possible, but they aren't implemented yet. Therefore some video modes are slower, than they could be.
SVGA1.drv
All modes are dynamic, i.e. support and parameters of any specific mode is reported by BIOS.
Graphic modes supported: 1bpp, 2bpp, 4bpp, 4bppV, 4bppE, 8bpp, 8bpp direct color, 8bppX, 8bppX direct color, 15bpp, 16bpp, 24bpp and 32bpp RGB/BGR modes are supported.
Text modes supported: 1bppM, MbppM, 1bppT, MbppT, 2bppT, 4bppT.
Please note! VBE 1.x implies VGA-compatible video card, as it doesn't provide way to detect VGA-incompatibility. Following features require some degree of VGA compatibility: VSync, some VGA modes, text modes, 4bpp plane modes, 8bpp modes, unchained 8bpp modes. In the worst case scenario only >=15bpp direct color modes with VSync disabled may be available.
SVGA2Bnk.drv/SVGA2LFB.drv
All modes are dynamic, i.e. support and parameters of any specific mode is reported by BIOS.
Graphic modes supported: 1bpp, 2bpp, 4bpp, 4bppV, 4bppE, 8bpp, 8bpp direct color, 8bppX, 8bppX direct color, 15bpp, 16bpp, 24bpp and 32bpp RGB/BGR modes are supported.
Text modes supported: 1bppM, MbppM, 1bppT, MbppT, 2bppT, 4bppT.
Differences vs SVGA1.drv:
- Unnecessary code is removed
- Extended mode info is always available
- Standard modes aren't supported (non-direct color ones are still supported though)
- Force32bpp is unsupported
- Palette control is supported - 8bpp modes aren't disabled by DisableVGABIOS
- VGA-incompatible cards are supported. It's related to IO ports and standard memory addresses only. BIOS calls shouldn't be affected. Use DisableVGABIOS in case of problems. But, as I understand, planar and banked modes can't even be VGA-incompatible. But we can never be 100% sure. So, they're guarded now.
Compatibility options:
- DisablePM32: Disable VBE 2.0 32bit protected mode interface, as it can be problematic (especially in case of page flipping). Fall back to BIOS calls or direct bank switching, if supported.
- DisableVSync: Disable VBE 2.0 VSync support, as it isn't guaranteed to work properly for all swap effectis (only for flipping). Fall back to VGAIO, if supported.
Windows:
Windows-specific options, that are shared between all Windows drivers:
Please note!: Default settings provide the best possible performance in all situtaions. Mapping algorithms are designed specifically to avoid any hardcoded behaviors. For example arbirtary DIB, system and static palette sizes are supported, not just ordinal 256 colors. Not all option combinations are functional though.
- PaletteMode. Should palette be enabled? Auto is recommended. Forcing palette off for palette device would cause fallback to default palette. Forcing palette on for RGB device would cause perofmance penalty and depending on Windows version certain features may not even function as expected.
- RGBPaletteMode. What logical palette should be loaded for RGB video modes, such as 16/24/32bpp modes?
- DIBPaletteMode. DIB to logical palette mapping. Explicit - we perform mapping ourselves. Implicit - palette manager performs mapping for us. Explicit is quicker, as mapping can be pre-computed, but it requires relying on certain palette manager behavior, so it's less compatible. Even explicit mapping is performed by palette manager itself. Palette manager has several limitations, that can cause wrong results in some cases.
- LogPaletteMode. Logical to system palette mapping. Explicit - we perform mapping ourselves. Implicit - palette manager performs mapping for us. Explicit is quicker, as mapping can be pre-computed, but it requires relying on certain palette manager behavior, so it's less compatible.
- IdentityPaletteMode. Identity logical to system palette mapping - is when mapping is like 1, 2, ..,254, 255. Palette manager should skip mapping in this case -> better performance. By default non-identity palette uses "map all entries" color reduction mode, if DIB palette doesn't fit into system one. This can reduce quality for some colors at the end of palette.
- StaticColorsMode. Static colors limit palette size and prevent identity mapping in some cases. Disabling static colors can affect other applications, but as we always use fullscreen rendering, it shouldn't be problem.
- ColorReductionMode. What to do if DIB palette doesn't fit into system palette? This can happen in case of using direct color modes, that require full 256 colors palette size. What we do - is try to remap DIB palette to smaller logical palette, that would fit into system palette, or predefined identity palettes, provided by system.
- StaticSourceMode. From where should we gather static colors for implicit color mapping? System palette may not be available in all cases. For example if static colors are disable or in case of RGB device. Switch to default palette in this case.
- ClearPaletteMode. For some unknown reason palette manager prefers palette entries, that have never been used before. This can mess our indetity mapping up. Therefore we should "clear" palette via marking all entries as already used. In theory it should be enough to clear palette only once. But option to clear it after every switch to other application is also provided.
For all modes: VSync controls if WM_PAINT or direct rendering is performed, Copy and Swap are supported, NoDoubleBuffer is ignored
GDI.drv
- 1bpp
- Mono, emulated
- 2bpp, emulated
- 4bpp
- 8bpp
- 8bpp Direct color RGB
- 8bpp Direct color BGR
- 15bpp (Except Win3x)
- 16bpp (Except Win3x)
- 24bpp
- 32bpp (Except Win3x)
Please note! Format support depends on Windows version, specific driver implementation and currently selected video mode. You'll get blank screen, if format is unsupported, garbled colors or distorted image, if it's supported partially. Testing has shown, that some drivers can even support undocumented formats. For example 15/16/32 bit formats can be partially supported by Win3x drivers, despite being officially unsupported by GDI. They aren't implemented in GDI driver now. I'm not sure, if they should be implemented. And if yes - then how they should be implemented, because they're purely GDI specific.
Please note! Emulated mode if unsupported by GDI, requires software processing and therefore can be ~2x slower.
OS support:
Global settings:
- Enable/disable mouse option allows switching mouse handling off to prevent unnecessary performance penalty
DOS:
- Timer settings: RTC or PIT, more precision - bigger perofrmance penalty
- Mouse settings: use normal mouse handling or alternative
Windows 3.x/NT 3.x:
No options available for now
Windows 9x/NT 4.x:
- Async timer for smoother controls, but can slow game down
- Async rendering for smoother FPS
- Switching both off essentially turns driver into Windows 3.x+Win32s/NT 3.x one
- Priorities allow better tuning for single-core CPU scenario
All systems:
- Video driver setting