Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / DBC Get Image 16bit Format: is it RGB565 or RGB555 ?

Author
Message
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 2nd May 2007 09:11
Link
When you use the Get Image command and then Make Memblock From Image, if the display mode is set to a 16bit depth, what is the RGB format of the pixel WORD? 565 or 555 ?

Enjoy your day.
Back to top
Profile PM
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 2nd May 2007 15:16
Link
It's video card dependant, you can can force the pixel format of the back buffer in DirectX, but then you're going against the grain. (rendering in one format and then down/up sampling for viewing)

A simply test is to draw green pixel on a image, make a mem block, or grab a pointer and peek it back.

From memory Green will come back as

$07e0 = 565 format -easily the most common
$03e0 = 555 format - pretty rare
$00f0 = 444 format - which should be long be obsolete today anyway. However it's still a supported texture format, so you never know.


PlayBasic.com Presents - Ballistic Blasters - Opening May 2007 - Fear Optional!
Back to top
Profile PM Website
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 2nd May 2007 19:32 Edited at: 2nd May 2007 23:52
Link
Thanks Kevin! You're always loaded with knowledge!

[Edit] Found answers to other questions...

If there could be multiple formats for different cards, waht's the best way to handle it? Is there a generic function that can be used?

In an Alpha Blending routine, the 16bit implementation has been giving me trouble. In the following psuedo code, I'm attempting to extract the primary color values from a memblock. Assuming RGB565 format and extracting a WORD from a memblock of pixel data into a variable named pixel:



and doing the same for a second memblock for the other pixel to blend with, and using:



as the blending method. Are there any problems with this approach?

Thanks!

Enjoy your day.
Back to top
Profile PM
Phaelax
DBPro Master
23
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 2nd May 2007 23:00 Edited at: 2nd May 2007 23:02
Link
Your interpolation looks correct, but I think you can simplify it.

c1 + ((c2 - c1) * K#)


I'd say create several functions to handle each format.





Although, since you're pulling the pixel information from a memblock, I think its safe to assume that DB already handles the format and I believe it's ARRRRRGGGGGBBBBB.




Edit:
@Latch, did you remove a post? I tried to answer your questions and when I finally posted, your questions are nowhere to be found.


Back to top
Profile PM Email Website
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 2nd May 2007 23:27 Edited at: 2nd May 2007 23:41
Link
@Phaelax

Sorry About that! I thought I had gotten to it before anyone posted a response. I was editing the message to indicate that I had figured out some of the answers I was looking for!

I'll repost the questions so the thread isn't disjointed...

Your optimization will come in handy. Thank you!

I tested the DBC memblock by looking at green like Kevein Picone suggested and on my machine the format came back as

RRRRRGGGGGGBBBBB.

Quote: "I'd say create several functions to handle each format."


I agree - probably the best way to handle it, though I do want to eliminate the overhead of having to test a green pixel. And since I'm using DBC, I have no "peek" to check it without first putting it in a memblock.

I've gotten the 16bit to work since I posted the last message, (sorry about erasing the question) but it's sooooo slow it makes my skull hurt. I'm gonna convert it to a DLL.

Enjoy your day.
Back to top
Profile PM
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 3rd May 2007 15:13
Link
Quote: "
I agree - probably the best way to handle it, though I do want to eliminate the overhead of having to test a green pixel. And since I'm using DBC, I have no "peek" to check it without first putting it in a memblock.
"


You don't need to calc the pixel format every time to access the Image / Mem blocks, just make some function that will calc the format, then call it right after the display depth has been initialized when the app starts. Then embed the your drawing/translations etc functions with render routines for the various formats.

It's often useful to have functions to read/write strips of pixel data to common 32bit buffers. The read /write function can do any required translation. So the code above it can be more generic. Also you can set up a mask/ shifts table. It's a lot of bogus overhead on top of the read/write though.


PlayBasic.com Presents - Ballistic Blasters - Opening May 2007 - Fear Optional!
Back to top
Profile PM Website
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 3rd May 2007 17:51
Link
Quote: "You don't need to calc the pixel format every time to access the Image / Mem blocks"


I wasn't planning on testing the format every access to the memblock, I was just hoping I could do the test with numbers without having to create an image or memblock at all to see how green was converted.

Quote: "It's often useful to have functions to read/write strips of pixel data to common 32bit buffers"


Thanks, that makes sense. It sounds like I could, for example, read in two 16bit pixels at a time into one dword then AND them against another dword that's set up with two 16bit masks in a similar fashion. Almost seems like that alone could cut processing in half if handled properly.

Enjoy your day.
Back to top
Profile PM
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 3rd May 2007 21:45 Edited at: 3rd May 2007 21:47
Link
You can probably just Draw a pixel with dot and use point to read it back. DB will sync, but if the app has just started nobody should notice it.


If you draw colour $00ff00 at 0,0, then ThisRGB=point(0,0) & $00ff00.

You should be able to detect the various 16bit pixel formats like this.

if G= $00Fc00 then 565
if G= $00F800 then 555
if G= $00F000 then 444 (not worth it really)

$00FF00 = either 24 or 32bit



Moreover, If you're just masking the pixels, then yeah you can pull a pair pixels into a long, mask it and drop it back. If you're familiar with MMX you can expand the pipeline to 4 pixels at once.


PlayBasic.com Presents - Ballistic Blasters - Opening May 2007 - Fear Optional!
Back to top
Profile PM Website
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 3rd May 2007 22:34
Link
Quote: "just Draw a pixel with dot and use point to read it back"


Wow! I've avoided using point() so often in favor of alternatives(because of it's slowness) that I completely forgot about it as a command! In this situation, it should work nicely. Thanks again!

Quote: "It's often useful to have functions to read/write strips of pixel data to common 32bit buffers"


I think I may have misunderstood what you were saying. Do you mean each pixel (say in a 32 pixel strip) would be repesented by an on or off bit in the strip?

Quote: "If you're familiar with MMX you can expand the pipeline to 4 pixels at once"

When it comes to C, I can get around ok with a couple of manuals open in front of me, but MMX might be a bit meaty for me to manage effectivly at this stage.

Enjoy your day.
Back to top
Profile PM
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 4th May 2007 02:41
Link
Well, point() doesn't really work. I think it's converted inside of DBC so that it's consistant with 255,255,255 in rgb. In 16 bit I get FE00 (high byte = 254 7 upper bits flagged) and in 32 bit FF00 (high byte = 255 all 8 bits flagged). I included a download of the point and the memblock output that shows 1,1 size 16 bit depth and one green pixel that 6bit. Guess I'll have to use the memblock test.

Enjoy your day.
Back to top
Profile PM
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 4th May 2007 11:02
Link
That's a pain about point.

Quote: " I think I may have misunderstood what you were saying. Do you mean each pixel (say in a 32 pixel strip) would be repesented by an on or off bit in the strip? "


For image processing it can be handy to have functions to the pull strips of pixels from the various buffers (whatever their format and location) into a pixel cache of sorts. Pixels in the cache would be default quality of the library. So then they'd be 32bit pixels.

ie. pseudo code



It's certainly not the fastest approach but it's a more generic approach, as it allows us to just write one version of our core image processing routine (ie a 32bit version), rather than bunch of customized versions for every available pixel format. Which gets old real fast !


PlayBasic.com Presents - Ballistic Blasters - Opening May 2007 - Fear Optional!
Back to top
Profile PM Website
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th May 2007 03:27
Link
Thanks for your help. I'll try out your suggestions and see what I can come up with.

Enjoy your day.
Back to top
Profile PM
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 20th May 2007 02:02
Link
I've been too busy to really work on anything the last couple of weeks so I haven't updated anything; but now I've managed to create a DLL that does a pretty good job of crossfading (Alpha Blending) in 16,24, and 32 bits that works with DBC. I ended up only testing for two 16 bit formats - 555 and 565. I use a separate function for each. Maybe I'll expand it to include other configurations, but most likely not. The memblock test creates a little overhead, but only once at initialization. The problems I was experiencing came from not paying close enough attention to my C code's data types so the blend in 16 bit was skipping every other pixel.

Thanks for all the help!

Enjoy your day.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2026-07-08 10:17:19
Your offset time is: 2026-07-08 10:17:19