Neopaint uses only 24-bit modes but on most newer cards are the true color modes in 32-bits. I am affraid that it is also the case of Intel 945GM.
The only solution for you is to somehow run DOSBOX from DOS and run it this way.

Or, there might be a way to fake 24-bit modes on 32-bit only Intel iGPUs. I seem to recall there was a small .com file released which could do this (modify the VESA table for 32-bit vesa modes to report as 24-bit instead), but can't find it right now. Does anyone know of such a thing?

This should be the case. CHKVESA.COM reports 32 bits modes but no 24 bits. Does anyone know anything about this utility to report 32 bit modes as 24 bits?

zyzzle wrote on 2026-08-31, 20:19:

Or, there might be a way to fake 24-bit modes on 32-bit only Intel iGPUs. I seem to recall there was a small .com file released which could do this (modify the VESA table for 32-bit vesa modes to report as 24-bit instead), but can't find it right now. Does anyone know of such a thing?

Unfortunately it's not that easy. I mean it's easy to make a TSR that reports 32-bit VESA modes as 24-bit (and maybe for some rare VESA applications it's enough) but it's very hard to correct direct 24-bits/pixel (3-bytes) writes to video memory to be compatible with 32-bits/pixel video memory layout. Programs that use VESA modes usually writes either the banked VGA frame buffer or the linear frame buffer directly so a TSR has no chance to catch and correct these writes. And without such correction only the 1st pixel will be correct. Subsequent pixels will be wrong because of the wrong offsets. For banked VGA frame buffer writes (VESA 1.2 modes) in theory it is possible to emulate a 24-bpp shadow buffer then intercept VESA bank select operations and finally convert the modified portions into the actual 32-bpp mode. But this is rather hard to implement correctly.

I thought it wasn't a free lunch, and thanks for explanation, Falcosoft. Converting all raw 24-bit writes to 32-bit offsets in realtime would also be very slow, I would think.

However, why did the switch from 24-bit to 32-bit VESA occur? I've seen it mentioned that using 32-bit offsets for "true color" is actually much faster than 24-bit modes. Something about 4-byte values vs 3-byte values and these fitting "better" into memory chunks. 32-bit video modes also consume more memory, which is probably why they didn't exist much 25-30 years ago in memory-starved video cards.

zyzzle wrote on Yesterday, 20:38:

I thought it wasn't a free lunch, and thanks for explanation, Falcosoft. Converting all raw 24-bit writes to 32-bit offsets in realtime would also be very slow, I would think.

However, why did the switch from 24-bit to 32-bit VESA occur? I've seen it mentioned that using 32-bit offsets for "true color" is actually much faster than 24-bit modes. Something about 4-byte values vs 3-byte values and these fitting "better" into memory chunks. 32-bit video modes also consume more memory, which is probably why they didn't exist much 25-30 years ago in memory-starved video cards.

Reading and writing 32-bit DWORD values are more natural and faster from both hardware and software perspective than reading and writing 3-byte chunks. But yes, you are right that 32-bit modes are more wasteful. 32-bit VESA modes are actually 24-bit modes but the 24-bit RGB triplets are packaged in 32-bit 'containers' with the last byte left unused.

zyzzle wrote on Yesterday, 20:38:

32-bit video modes also consume more memory, which is probably why they didn't exist much 25-30 years ago in memory-starved video cards.

In 1996-2001, 32-bpp TrueColor was already common.

The era of 24-bpp TrueColor was early 90s:
- 640 x 480 already considered the minimum useful resolution
- cards with >1 MB still mad expensive
- 640 x 480 x 24 bit < 1 MB
- yes, it *was* slow!

Sometime around the shift to PCI, 2 MB cards became affordable, and the speedup from 32-bit-aligned video memory writes became more important than conserving the memory...