Hiya all.

Im trying to use a 16bit DDS image to store heightmaps.
Creating the image, and loading it as a BMAP is fine.

BUT, I cant get individual pixel data out of it using pixel_for_bmap and pixel_for_vec
because (according to manual) pixel_for_vec can only manage to handle
"...the pixel format: 88, 565, 888, 1555, 4444, or 8888". And it doesnt even complain
when I try to force it to use pixel format "16""12"...

Any ideas on how I can extract this info (on a pixel by pixel basis) anyone?

Thanks guys...

Have a look here:
http://www.conitec.net/beta/abmap_lock.htm

Sorry, but Im already doing that to get the pixel format of the image.

PS: Ive fixed a TYPO in my main post regarding the format number...

Assuming, that your dds contains texture data compressed with an algorithm, you´ve got hardware support for, the problem is, that the compressed data is never really decompressed. And to actually give you access o the pixels it would have to do this. So the best choice for you is probably just some tga file with losless compression, which is then anyway decompressed on loading.

No can do. I NEED a 16bit value per pixel.
And I cant get TGA to go 16bit. But Im no 'photoshop guru'...

256*b+g?

Your 12 bit DDS bmap is not normal
[EDIT]
I assume that you must read the pixel first with pixel_for_bmap before using pixel_for_vec

Joey: No good dude. I need the actual 16bit data as saved by 'photoshop'.

Bart: Re-read my top post regarding number of bits. I am actually working
with a 16bit float DDS file. The "12" in my top post is the "pixel type number"
that gamestudio returns from bmap_lock. Read the manual under bmap_lock and
check the type 12 entry. Thats me...

And yes I am using pixel_for_bmap first. I also tried looking at the raw
'pixel' data as stored in the var returned by pixel_for_bmp, BEFORE using it in
pixel_to_vec but could make no sense of it or use for it.

I wish I knew how to get inside GS's pixel format, because I suspect the 16bit
data IS being retrieved by pixel_for_bmap, its just that pixel_to_vect doesnt
know how to process it...

Do you use any compression? What pixel format are you saving with? It is a dds file? Is it loaded correctly? Can you display it in a panel or something? What exactly is supposed to be in the texture?

I think that gamestudio uses some directx function to load dds files, which should support many different formats, but the bmap functions only support a small number of formats, so if your texture is really uncompressed, it could be that you can´t really use gamestudios functions to get the pixels, but it should then at least be possible to directly access the texture data.

Its a 16bit float (one color channel) DDS, so I assume it to be compressed. All DDS files are I BELIEVE (noob to DDS).
I only went DDS cause it was one of the few formats that could carry a single 16bit 'color'.

GS DOES load the image, as I am able to display the image with DEBUG_BMAP.
It is a strange washed-out cyan color, but it is recognisably the image in question.

Its not a 'texture', its a heightmap. That I want to never 'display', but I want to
read through it on a pixel-by-pixel basis and save into a custom-structure data file.
This datafile is my (currently in proof-of-concept testing) way of storing the heightmap of 'the entire world'.
So as you can imagine, its BIG, really BIG, you wont believe how vastly, hugely, mind-bogglingly
big it is, you might think its a long way down the street to the chemist, but thats just peanuts to ....[REDUCTED]

So, with all this known, I feel IF I had some ideas how to start, I could access the texture via the
bmap.finalbits or even the bmap.d3dtex pointers.
But I dont where to start with 16bit floats... Floats are an unknown country to me...

I was HOPING for an easier way, but it looks like I may have no choise.
This is only a TOOL anyway, so speed is not so essential...