BitMap blues...

[Karlos]

Hi all,

I have been doing some gfx coding lately and bumped into an old problem I originally thought was my own fault at the time but now I'm not sure...

I need to allocate chunky BitMaps, in video ram using a pixel format of my choice.

According to the docs, this is easy. And indeed it is - except for the fact that the pixel data ends up in fast ram which is pointless for hw rendering (eg using Warp3D).

I have found that, irrespective of the BMF_DISPLAYABLE flag or other AllocBitMap() parameters, the only way I can ensure that the bitmap data is created in VRam is to make the BitMap a friend of an existing one that is already there, eg a screen, for example.

That, however, also forces my BitMap to have the same pixel representation as the screen (a requirement for hw blitting between the two).

What I want is to just create a BitMap in the 15/16/24/32 bit depth of my choice, render to it (using warp3d) and then copy the pixel data back to system memory for saving.

It only works if I open a screen in the desired format and go from there. I don't particularly want to open a screen for this code since its just for a small CLI tool to manipulate images quickly based on some CLI parameters.

Specifically it is for fast, filtered resizing, dithered colour depth conversion, chromatic effects etc., all of which W3D excells at.

Any ideas?

[Karlos]

*bump*

;-)

[Thomas]

Well, if Warp3D depends on special bitmap attributes, aren't there funcitons to allocate/deallocate such bitmaps in Warp3D ?

Bye,
Thomas
 

[bloodline]

can you just allocate the memory you need (where you work out the requirements)? Are there no flags that allow you to choose the Ram type?

[Karlos]

Hi,

Thomas - well, the only requirements warp3d has with regard the BitMap is that it is of a format supported by the 3D chip and that it is in video ram.

Since most people want to render to a display, the latter requriement is not an issue - a display bitmap has to be in video ram. As I said, making the BitMap a friend of the display's BitMap is the way to enforce this but that forces it to have the same pixel format as the display. Since I don't even want to have a display in this instance I'm stuck :-)

Matt - There aren't any malloc() type functions that operate in video ram. Exec's own allocators allow you to select chip ram, but that's no use here :-)

The only way to allocate video ram (that I know of) is to use a BitMap. However, that BitMap data can be in fast ram - the rtg software handles putting it into video ram when it needs to be. Once again, to get your BitMap data in video ram, it seems that you have to make it a friend of one that already is and that means you need a display and your choice of pixel format is overriden.

The BMF_DISPLAYABLE flag used with AllocBitMap() is supposed to allocate the data in a form useable by the display hardware but I always get it in fast ram...

To reiterate, I just want to be able to create a BitMap, in video ram, in a (compatible) pixel format of my choosing, without it having to be a friend of one already there.

This goes beyond warp3d, I need it for the Surface class in my C++ portability layer. This class is supposed to encapsulate a displayable surface that you can render to, blit etc.

So far, no joy, unless I open a display in my desired pixel format and use that, but that somewhat defeats the objective.

[Karlos]

Hi all,

Sorry for bumping this but I need to try and get this solved soonest ;-)