Deluxe Paint IV (or III ... and 5)

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser Please create an account and log in to see all content by default. This is a limitation of the forum software.
Don't Panic. Please wash hands.
  • Hello everyone,


    I wanted to log a bug that has been known to exist at least as long ago as 2002 (in terms of what I can find on the internet) and I'm sure older than that, probably going back to the mid-to-late 1990s.


    If one uses some RTG cards with P96 drivers, Deluxe Paint breaks and glitches badly. This is true for cards dating back to the Picasso IV, as well as brand new modern cards like the mntmn ZZ9000.


    However, "junk" graphics cards like the Merlin, if running Cybergraphx drivers, work just fine with Deluxe Paint programs.


    It would be insanely glorious if the P96 libraries could be updated to support this old painting software.


    Examples of the bugs:

    If you use the clone tool (brush tool) and move your cursor over the canvas, whatever you copy to the clipboard can't refresh and your whole screen will fill with pixelated garbage.

    If you click any of the tools in the tool bar, that tool icon will simply vanish as the screen won't refresh to show the new state. If I start to draw, just moving the mouse over the art makes it impossible to do anything.


    This behavior has been seen in both Deluxe Paint 3 and 4, 4.0, 4.1.

    With Deluxe Paint 5, the Workbench menus from the top glitch badly as well.


    If my friends (who have all seen and verified the same behavior) are correct, the finger might be pointing at the P96 monitor file. Their current hack is to create an environment variable to deactivate the monitor driver via startup sequence. Surely there must be a better way?


    Best,

    Eric

  • AmigaLove

    Changed the title of the thread from “Deluxe Paint IV (or III)” to “Deluxe Paint IV (or III ... and 5)”.
  • This sounds like the bug that was fixed in V2.4.3, where BltMaskBitMapRastPort() was fixed. That caused copying/moving of gfx to be corrupt in certain cases. Are you sure the bug is still there since last October's update?

  • I bought the software for the first time on 24.04.2020 (order# 74994). I'm not sure how to check the version number to be honest but I would have downloaded the latest version in April of this year.


    My friends also have the latest version and see the same behavior. If you happen to have a copy of DPaint - really any version - you should be able to see the issues I describe. Lukas Hartmann has also verified the issues with me if that's helpful.


    Good to hear from you, Jens. Hope you're doing well.

  • There has been one update after you've bought - just go to your order history page and download again, you always get the latest version there.


    Lukas of course has the latest version, so I assume that we're talking about a different bug from the one that was fixed recently.


    I personally do hardware development and don't even have a setup with GFX card at the moment. I do trust that this is easily reproducable.

  • Just talked to Thomas Richter, and he told me that a) this won't ever work, as DPaint is not using the OS for all it's operations. Namely, it modifies bitplane pointers in it's own code, and it launches the blitter by directly talking to the hardware, not going through any library. As a result, he believes that CGX has the same problems.


    The bitplane pointers have a totally different meaning for P96, and the Blitter will of course never work for GFX card memory.


    One thing might work within limits: Launch DPaint with a planar RTG mode. This will put the bit planes into chip ram, where the blitter can really work on them. P96 will then just copy from chip ram to the RTG card's mem. However, Thor's further suggestion was to use PPaint instead of DPaint, as that should work much smoother.