Short:        Fix Warp3D Texture Allocation
Author:       thomas.richter@alumni.tu-berlin.de (Thomas Richter)
Uploader:     thomas richter alumni tu-berlin de (Thomas Richter)
Type:         driver/video
Version:      1.0
Requires:     Warp3D-4.2a
Architecture: m68k-amigaos

This program adds a workaround for some Warp3D applications that cause
flicker or false colors on rendering, in particular on the CVisionPPC.

To apply the patch, open a Shell, unpack the archive and change the
directory to where you unpacked the archive. Then enter:

spatch -oram:W3D_Picasso96.library -pW3D_Picasso96.library.pch LIBS:Warp3D/GFXdrivers/W3D_Picasso96.library

This creates a new W3D_Picasso96.library in RAM. Keep a backup of the old
library, just in case, and copy the patched version back:

copy LIBS:Warp3D/GFXdrivers/W3D_Picasso96.library LIBS:Warp3D/GFXdrivers/W3D_Picasso96.library-old
copy ram:W3D_Picasso96.library LIBS:Warp3D/GFXdrivers/

___________________________________________________________________________

Background:


What is the issue?

Textures and shapes of some Warp3D applications show false colors, or flicker
terribly.


Why does that happen?

Warp3D allocates textures for the surfaces of these applications in the P96
RGB type "Planar". Planar bitmaps allocate in the little-endian mode, whereas
the applications expect them in 16-bit big-endian mode, e.g. with the pixel
type 16-bit hi-color big-endian. The two pixel types map into different
appertures, and the wrong apperture is picked by default.

This is *not* the fault of Warp3D nor P96. Warp3D expects applications to open
a screen or allocate a bitmap in the expected RGB pixel type, e.g. 16bit RGB
big endian, and pass this bitmap as "context" into the texture allocator
function. From there, the bitmap is passed as "friend" bitmap back into P96,
which then selects the right apperture for the texture.

Unfortunately, buggy applications simply provide a NULL pointer as context to
Warp3D. In this case, P96 falls back to the "default pixel type" given as another
argument to its bitmap allocator function, and Warp3D sets this default type to 0,
which is "planar". This makes of course no sense whatsoever as neither Warp3D nor
applications attempt to render into a planar bitmap.


What does this patch do?

It changes the default pixel type of the Warp3D allocator to 16-bit hi-color big-
endian. Thus, whenever an application allocates a texture from Warp3D without
giving a context, the texture is put into the big-endian 16-bit apperture. Apparently,
this is what the applications expect - without ever saying to Warp3D.


Ideally, such buggy applications should be fixed. The defect is really there, and
neither in Warp3D nor in P96, nor in its drivers. Everything works, "as expected",
except that these applications expect the wrong thing.

___________________________________________________________________________

Legalese:

SPatch, as included in the archive, is (c) 1992 SAS Institute, Inc.
All Rights Reserved. SPatch is freely distributable. See the SAS/C
Development System User's Guide, Volume 2, page 292.

The patch file W3D_Picasso96.library.pch is freely distributable under CC-0
conditions, "no rights reserved".

To find out more about CC-0, https://creativecommons.org/public-domain/cc0/.

___________________________________________________________________________

Thomas Richter,	August 2025