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 2026-09-01, 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 2026-09-01, 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...

Falcosoft wrote on 2026-09-01, 13:33:

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)

So, is there any utility that can report 32 bit as 24 bit modes to check if NeoPaint works in this mode?

ntalaec wrote on 2026-09-03, 09:57:

Falcosoft wrote on 2026-09-01, 13:33:

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)

So, is there any utility that can report 32 bit as 24 bit modes to check if NeoPaint works in this mode?

NeoPaint is not that kind of program. After unpacking and disassembling it (it's PKLITE packed) this is obvious:
It has a fixed internal VESA modes table. And e.g. It searches for a 640 × 480 × 16m color mode that has BytesPerScanLine = 1920. (640 x 3 = 1920). In case of a 16m color but 32-bit mode BytesPerScanLine = 2560 (640 x 4 = 2560).
This is a strong evidence that NeoPaint really uses genuinely packed 3-byte-per-pixel framebuffer.

Bad luck for owners of Intel graphics then. Many thanks for checking.

ntalaec wrote on 2026-09-03, 11:16:

Bad luck for owners of Intel graphics then. Many thanks for checking.

You can test the result yourself. I have written a small TSR that sets the BytesPerScanLine and BitsPerPixel fields so that NeoPaint can enumerate the corresponding 16m color VESA modes.

But then you get this (800x600x16m):

Just as expected from a VESA program that really expects a packed 3-byte-per-pixel framebuffer and writes 3-bytes directly.
BTW, all more modern NVIDIA and AMD cards are also affected. The last VGA I met and supported 24bpp VESA modes natively was an integrated ATI Radeon Xpress 1100 on a HP-Compaq NX 6325 notebook.

@Edit:
According to the Readme you have to use special switches in order higher resolutions with higher bit depths to work.
On Intel GFX I had to use Neopaint.exe /C7,-1,4096 for higher resolutions (the 4096 at the end of the command line means 4MB video memory).

Falcosoft wrote on 2026-09-03, 12:22:

But then you get this (800x600x16m):

The attachment neopaint_24bpp.png is no longer available

On real hardware it looks like that. At least on screen. I took a screenshot using PCXDUMP and the image was OK.

This also happens in DOSBox 0.74-3, but Links LS can do 24 bits without problems:

NeoPaint should work in a different manner.

ntalaec wrote on 2026-09-04, 09:44:

Falcosoft wrote on 2026-09-03, 12:22:

But then you get this (800x600x16m):

The attachment neopaint_24bpp.png is no longer available

On real hardware it looks like that. At least on screen. I took a screenshot using PCXDUMP and the image was OK.
...

It's because PCXDUMP reads 3-bytes per pixel from video memory as suggested by the fake VESA mode attributes and saves a 24-bits/3-bytes per pixel bitmap/PCX file.

As I said earlier in theory it is possible to emulate a 24-bpp shadow buffer and then intercept VESA bank select operations. Such method could work since according to VESA specification even the address of the banked frame buffer is not hard coded. WinASegment is 0xA000 in all hardware implementations I have met so far but this address is not necessary. So I have made some experiments but it seems NeoPaint ignores the modified WinASegment value of the selected VESA mode and always uses 0xA000 instead. So even this shadow buffer method cannot work with NeoPaint unfortunately. It seems we have to accept that NeoPaint cannot be fixed by a TSR to use 16M colors with 32bpp modes...

It might be possible to patch NeoPaint...
There must be a "multiply by 3" instruction somewhere, that can be replaced by "multiply by 4"...

Then, it should also require modify NEOPAINT.EXE to use WinASegment? Or, apart from being too complicated, it's not possible?

ntalaec wrote on 2026-09-06, 10:24:

Then, it should also require modify NEOPAINT.EXE to use WinASegment?

That shouldn't be necessary - 32bpp modes also use segment A000.

The problem may be that there's too many "multiply by 3" and "divide by 3" instructions to properly catch them all.

Grzyb wrote on 2026-09-06, 10:53:

ntalaec wrote on 2026-09-06, 10:24:

Then, it should also require modify NEOPAINT.EXE to use WinASegment?

That shouldn't be necessary - 32bpp modes also use segment A000.

The problem may be that there's too many "multiply by 3" and "divide by 3" instructions to properly catch them all.

The main problem with patching NeoPaint is that it seems it tries to defend itself against patching (I think it's because of the registration related routines).
It's PKLITE packed. You can unpack it and then the disassembled code is clearly valid but the unpacked exe cannot be started anymore. Most likely some kind of CRC check but I could not find exactly where it is.

Falcosoft wrote on 2026-09-06, 11:56:

The main problem with patching NeoPaint is that it seems it tries to defend itself against patching (I think it's because of the registration related routines).
It's PKLITE packed. You can unpack it and then the disassembled code is clearly valid but the unpacked exe cannot be started anymore. Most likely some kind of CRC check but I could not find exactly where it is.

The attached contains neopaint unpacked, and it still runs. But you also need the neopaint.ovr file. It starts just fine, and can be modified.

I'm not sure which offsets in the raw uncompressed binary to attempt to patch in order to get rid of the multiply-by-3 and divide-by-3 code. Perhaps the modifications needed to get 32-bit VESA modes propery displayed are not in the .exe but in the overlay file.