zyzzle wrote on 2026-09-11, 21:08:The attached contains neopaint unpacked, and it still runs.
The unpacked version runs fine. I was able to register the program using the serial.
zyzzle wrote on 2026-09-11, 21:08: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.
Yep, this one runs perfectly and it is somewhat bigger than the one I got when I used UnPKd.exe to get the unpacked version. Can I ask what unpacker you used to get this?
The main code parts related to VESA modes enumeration and validation are the same but I could not find the relevant 24-bit only drawing routines in either one...
Most likely the drawing routines are really in the Borland Pascal style overlay file.
OK, I have found the drawing routines in the overlay file. The funny thing is there are already implemented 32bpp drawing routines besides the 8,16 and 24bpp routines 😀 So instead of rewriting the drawing routines I simply redirected the callings from the main executable to the 32-bit ones in the overlay. This way I got a working canvas with good shapes and colors but all interface elements became garbled. Also the PXC saving cannot produce proper PCX files anymore... So it seems this is a harder job than we hoped.
Falcosoft wrote on Yesterday, 11:54:Yep, this one runs perfectly and it is somewhat bigger than the one I got when I used UnPKd.exe to get the unpacked version. Can I ask what unpacker you used to get this?
CUP386.EXE /7 NEOPAINT.EXE
Falcosoft wrote on Yesterday, 15:54:OK, I have found the drawing routines in the overlay file. The funny thing is there are already implemented 32bpp drawing routines besides the 8,16 and 24bpp routines 😀 So instead of rewriting the drawing routines I simply redirected the callings from the main executable to the 32-bit ones in the overlay. This way I got a working canvas with good shapes and colors but all interface elements became garbled. Also the PXC saving cannot produce proper PCX files anymore... So it seems this is a harder job than we hoped.
Very, very strange the 32bpp modes were apparently coded but not implemented?! There's got to be a reason why. The strange misalignment of the interface in your redirected 32bit mode seems to point to some kind of hard-coded memory offsets being used for the interface icons, etc. A very kludgy way of coding. As the program is a flat 16-bit Borland Pascal .exe (I think), there may be a good reason for it, but I can't seem to figure it.
zyzzle wrote on Yesterday, 20:32:Falcosoft wrote on Yesterday, 15:54:OK, I have found the drawing routines in the overlay file. The funny thing is there are already implemented 32bpp drawing routines besides the 8,16 and 24bpp routines 😀 So instead of rewriting the drawing routines I simply redirected the callings from the main executable to the 32-bit ones in the overlay. This way I got a working canvas with good shapes and colors but all interface elements became garbled. Also the PXC saving cannot produce proper PCX files anymore... So it seems this is a harder job than we hoped.
Very, very strange the 32bpp modes were apparently coded but not implemented?! There's got to be a reason why. The strange misalignment of the interface in your redirected 32bit mode seems to point to some kind of hard-coded memory offsets being used for the interface icons, etc. A very kludgy way of coding. As the program is a flat 16-bit Borland Pascal .exe (I think), there may be a good reason for it, but I can't seem to figure it.
It seems I found some helper routines that calculate the coordinate geometry for 32-bit. It fixed the GUI element position problems but also caused the mouse cursor to draw random colored trails. And the 'colored' GUI icons are still drawn in 24bpp. It's rather frustrating 😀
Falcosoft wrote on Yesterday, 22:27:It seems I found some helper routines that calculate the coordinate geometry for 32-bit. It fixed the GUI element position problems but also caused the mouse cursor to draw random colored trails. And the 'colored' GUI icons are still drawn in 24bpp. It's rather frustrating 😀
Wow, that's real progress. As I understand you, 32-bpp images will load OK with full 16.7M colors now, but there are those strange "color" trails which corrupt the image when the mouse pointer is rolled over them. May you further illustrate with a screenshot of a truecolor image loaded into the program (something like a color wheel or something showing the full palette)?
Still, if it's now working in 32-bpp VESA modes and / or Intel vBIOSes with your mods, that pretty much makes it "usable" on modern systems, I'd say. But frustrating there are always snags, now something with the mouse routines corrupting the memory somehow?
