WritePixelArray VS Warp3d textures ?

[Karlos]

I guess you are using a voodoo 3000 (or similar)? If this is the case, you are out of luck for true colour textures. They will be converted to 16-bits per pixel by the fastest means possible.

Score 1 to the Permedia2 which renders 32-bit textures perfectly well on 15/16/32-bit targets.

[Karlos]

You could try hinting to the driver to use "nicer" texture quality. However, I don't know if the voodoo3000 actually supports 32-bit texel data at all.

[Karlos]

The later cards definately support 32-bit rendering, both for target surfaces and for texel data.

I think the voodoo3000 might have been the last of the 16-bit only chips.

The last generation voodoos to appear were both surprisingly powerful rasterizers, had decent render quality as well as some features not seen elsewhere at that time. They also supported multiple GPU rendering. However, nobody really wanted to spend a fortune on a 6-GPU card by then when it was clear that existing CPUs couldn't keep them fed fast enough. By this point NVidia and ATI were making T&L hardware that simply removed that existing bottleneck, giving much better overall performance.

[Karlos]

@Cymric

WritePixelArray() is a function provided by CyberGraphX (IIRC, it isn't provided by the OS) that takes a pointer to some chunky pixel data (in a typical ARGB32, RGB24 or 256-colour "CLUT") format and writes it to a RastPort.

The hardware pixel format of the underlying BitMap is understandably device specific, so WritePixelArray() does conversion of the data where needed. Unfortunately (as I discovered a long time ago) this function (as well as BlitBitMap between different pixel formats) are rather slow.

What kas1e is trying to do instead is to take his 32-bit source data and use it as a warp3d texture map instead.

The reason for this is that 3D hardware can generally take colour conversion in its stride, mapping a 32-bit source texture to a polygon on any supported 15/16 bit screen, dithering it, processing transparancy, shading it (in a variety of ways), scaling it, filtering all with total hardware acceleration that leaves the equivalent OS/CyberGraphX/P96 routines (where they even exist) eating dust.

Unfortunately, it seems the voodoo3000 only wants to use 16-bit texel data, so kas1e's 32-bit source data is being pre-converted by the driver.

[Karlos]

You should all bow to the superiority of the Permedia2

/ducks

[Karlos]

Just use the vertex colours to perform the fade.

Let's assume you can get a nice RGB565 format texture made in an art package and properly dithered to that depth.

Use that texture on a white polygon with W3D_MODUALTE as your texture environment. The vertex colour is then multiplied by the texture colour. Since the vertex colour is white, you get your original texture colour unmodified.

However, the vertex alpha colour is also included in the process if you have W3D_BLENDING enabled. For basic alpha blending, set the blend mode source and destination factors to W3D_SOURCE_ALPHA, W3D_ONE_MINUS_SOURCE_ALPHA respectively.

Now, you can render your rectangle each frame and progressively increase the alpha component to make your image more and more opaque.

[Karlos]

Alternatively, to make a simple fade to any colour from the picture:

Draw the picture with the OS routines to get it on screen. To fade the image out, you can render a 75% transparent (using the vertex alpha again) polygon on top (no texture needed this time, just the vertex colour).

In this case, you don't clear the frame each time, just put another almost transparent layer of colour on it each time and over successive frames they will completely replace the image.

[Karlos]

The fade I was talking about in the second post was fading from the image to a colour (so yes, a fade out).

For creating your images there are a few ways. One of them is to simply view your image in multiview with the maximum dithering and stuff turned on for a 16-bit screen and then simply grab the window with cybergrab or something. Make sure you save your grab as iff or png (something lossless) and then load it into any old 24-bit package, crop as needed (if needed) and save it off. Of course it will be saved directly as 24-bit data even though there are only 16 meaningful bits for each pixel.

Another way is to use PaintShop Pro (or whatever) on the PC which has the option to dither from 32/24-bit to 15 or 16 bit colour. It will still save as 24-bit in the same way.

Ideally you should write a small tool to then convert this 24-bit data to raw 16-bit data for your application (dropping the extra unused bits) but even if you load the data as 24 bit and it gets converted to 16-bits again, it only contained 16-bit colour resolution anyway; it's just a bit less efficient than being able to load the 16-bit data directly as a source for your texture.

[Karlos]

kas1e wrote:


Btw, maybe here is any way for emulate by warp3d library unsupported blend_modes states ? I mean use hardware drivers, use all states which can be doit by hardware driver, and for unsupported states use software driver ?

Not easy and likely a very big performance hit.

[Karlos]

Permedia2 only offers normal alpha blending (W3D_SRC_ALPHA, W3D_ONE_MINUS_SRC_ALPHA). There is another blending mode based on some apple model, sort of an additive blend but it doesn't actually conform to any GL ones and ergo is not really supported.

[Karlos]

@Kas1e

Only do that it if it makes sense for your application, of course. This mode gives you basic alpha channel based transparency. However it is also about the lowest common denominator - pretty much all supported cards on W3D offer it.

If this is not whant you need, you might find you can change your texture data in some way to achieve the effect you are after.

[Karlos]

For the BVision:

Dont use MIP maps at all when you allocate the texture objects. It shouldn't hurt but it doesnt do anything anyway.

Make sure that your vertex colours are set up correctly too.

As for textures, it definately supports A8R8G8B8 (and A4R4G4B4), it's the voodoo3000 that has to convert this into A4R4G4B4.

Ensure that all your blending modes etc are set up in advance of any rendering too. Make sure you aren't blending your texture with a black polygon too (for W3D_MODULATE)!

If you want me to examine your code, email it to me and I'll try to check the problem out.

[Karlos]

kas1e wrote:
Ok, time to up warp3d talks Thanks to karlos for lot of help, but i have new question: have warp3d4.2 somethink like 'color-key' in old directx ? I mean i want do somethink like this: i draw texture, but all color which i setup by somethink warp3d fuction just do not draw. For example i have black background with sprite. And want draw all, except black color.
it is possible by w3d 4.2 ?

See the docs / W3D_SetChromaTestBounds(W3D_Context* context, W3D_Texture* texture, ULONG lower, ULONG upper, ULONG mode)

This function allows you to set a range of colours (both defined as 32-bit ARGB values). If you set the lower range as 0x00010101 and the upper limit as 0xFFFFFFFF and the mode to W3D_CHROMATEST_INCLUSIVE, then any texel that isn't black will be rendered.

Of course, unless you are doing something complex already with alpha, the simplest thing to do would be to use the alpha channel of the texture to dictate which parts of your sprite are opaque.