Quite bad graphics corruption in DPAINT HAM MODE

[ral-clan]

As mentioned before in other threads, I use WinUAE to run graphics and sound applications rather than games. So maybe I am pushing the emulation in ways that show up certain bugs gamers aren't encountering. I have another thread on this forum about graphics corruption in TV-PAINT, for instance.

I've discovered quite bad graphics corruption in DPAINT IV and DPAINT V when used in any HAM mode. These are the only version of DPAINT that can use HAM mode. They both exhibit quite bad corruption. This is most evident when drawing large solid areas like circles or blocks of a single colour. I have found it only occurs when drawing with palette colour 2 - the same colour as that used by the menu bar. I've marked the colour in this DPAINT V screenshot with a red arrow.


(click to enlarge)

In DPAINT IV, not only does this corruption occur, but when using the pallette mixing tool (which is a HAM mode section of the screen) the corruption is also evident on the colour swatches.



Note: This graphics corruption does NOT occur in either version when using a NON-HAM mode screen - EXCEPT when showing the pallete mixer in DPAINT IV, where once again the colour swatches are corrupted. It should be noted that the palette mixing display is actually a tiny HAM section of the screen.

Another important thing to note: corrupted images when saved RETAIN the corruption in the saved file - even when loaded into other programs.

Also note: when using other HAM graphics programs - i.e. BRILLIANCE there is no apparent graphics corruption. DPaint, however, is THE quintessential Amiga graphics program, so I'm sure there are many users that would like to know why this corruption occurs.

I am using WinUAE 2.4.1 under Windows XP SP3.
AmigaOS 3.9
Emulating an 040 based Amiga 4000.

Links to config and log files:
http://www3.sympatico.ca/clarke-santin/misc/config.uae
http://www3.sympatico.ca/clarke-sant.../winuaelog.txt

[Toni Wilen]

I don't think this anything to do with emulation. It is normal HAM corruption when something changes base colors.

DPaint is not that system friendly as it looks.

- Even Picasso96 enabled without using Picasso96 modes can cause problems.
- Any system patch can cause problems
- Even "too new" AmigaOS version can cause problems.

What is the exact version and date of DPaint? AFAIK there are multiple revisions.

[ral-clan]

DPaint V is version 5.2
DPaint IV is version 4.6

I will try running these programs under a stock (emulated) A500 with plain installed WB3.1 and see if HAM problems still are present.

[Thorham]

Originally Posted by Toni Wilen

I don't think this anything to do with emulation. It is normal HAM corruption when something changes base colors.

What you see here is not HAM corruption, just look at the palette editor in the second picture. This is certainly another problem, because HAM just doesn't cause these effects.

[Toni Wilen]

Oops, I checked them quickly, saw repeating pattern and didn't bother to think because I decided (DPaint = can't be trusted. Ever.) before checking the images that it can't have anything to do with emulation.

Perhaps it is caused by some force bitplanes to fast ram patch or something.

btw, those images are really really too small.

[ral-clan]

Originally Posted by Toni Wilen

btw, those images are really really too small.

Toni, did you click on the images to enlarge them?
When you click on them it shows them in their native true resolution.

[Toni Wilen]

Originally Posted by ral-clan

Toni, did you click on the images to enlarge them?
When you click on them it shows them in their native true resolution.

Of course and nothing happens. (Tried Chrome and IE)

[lilalurl]

Feel free to edit/delete the post at will if the images are a problem after you have checked them (links worked fine on FF 3.6.28)

[ral-clan]

Here are direct links to the images in original resolution:

http://s14.postimage.org/t14umqfw1/DPAINTV_fail01.png

http://s14.postimage.org/ofdbs4jqp/DPAINTIV_fail01.png

[ral-clan]

UPDATE:

I have tested Deluxe Paint 4 and 5 on a stock/plain Amiga WinUAE setup and the HAM corruption does not occur.

Then I started up my more advanced/RTG/OS3.9 WinUAE configuration while holding down the right mouse button (disalbes startup programs?). That fixed the problem with DPAINT HAM corruption in my advanced configuration. I think it kills Picasso96 - maybe that's what was causing the problem.

Thanks for the suggestions Toni. So definitely not an emulation problem. Thanks.

[LocalH]

My guess is something within DPaint is conflicting with P96 or some other software, and causing it to write the wrong bit patterns to chip RAM. I'm pretty sure the palette screen is always in HAM mode even if not necessary, in order for the palette mixer on the right to function. It doesn't appear to use the same base palette as the document screen (I remember back in the day that even when editing an image in a "normal" screenmode, the palette screen would still show HAM fringing).

[Ami_GFX]

It definitely seems to be an issue with DPaint and Picasso 96. I recently replaced the Picasso II I had in my A4000 with a Cybervision 64. I have three bootable partitions, one with OS 3.1 and Picasso 96, one with OS 3.1 and Cybergraphics 4 and one with OS 3.9 and Picasso 96. The OS3.1/Picasso 96 system started to crash and reboot when I started DPaint 5.2. DPaint worked in the other 2 and it's always worked much better in Cybergraphics--I can use it in Cybergraphics modes up to 1024x768. I replaced the RTG library in the OS3.1/Picasso 96 system with the latest version and I could run Dpaint but I got the exact same issues I get in Winuae with Picasso 96: Pixels randomly the wrong color in Ham and 256 color AGA modes. No such problem in these modes under CyberGraphics.

Not an emulation issue at all. The same sort of incompatiblity exists in a real A4000 with Dpaint V and Picasso 96