Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Tooon

Support for 16 and 32 bpp prob...

This topic is 6696 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all! I''m in the middle of creating a Graphic-library (with support for DirectX), like PTC. It will support 16 and 32 bpp, but I need help deciding how to handle that. In the surfaceclass i have a blit function (blitting from a surface to another, not directX surfaces - just own defined surfaces in System RAM) - wich supports AlphaBlending, saturation, colorkeeying etc etc.. I''ve seen lots of articles describing how to blit pixels independent of wich mode you in (16, 32 etc). These articles describes a function (compilePixel) wich plots a pixel using the bitmasks recieved from lpPrimarySurface->GetPixelFormat. But is this fast enough? Isn''t faster to handle these effects sepperatly, than compiling each and every pixel? Especially in time-critical effects like Alpha, Saturation etc. This is I have it structured now: void ASurface::Blit (ASurface *other, dword flags .....) { switch (bpp) { case 32: .... code for 32 bpp case 16: ... code for 16 bpp } } This will generate lots of more code, but will most certain be faster than compile each pixel and skip having sepperat functions (or parts) for 16 and 32, or? Wow, long post, Sorry if it seem messy, but any idea about how I should support both these bitdepths would be very appreciated... Need this before I start implementing all these blit-functions... / Tooon

Share this post


Link to post
Share on other sites
Advertisement
There are many different ways to do this.
You have to ask yourself some questions though.
Are you trying to build for Speed?
Easier future enhancements?
OO vs. non OO?

You could have one function that detects what the current setting is, like you have done.

You could have a virtual base screen class with a virtual drawing function. Then have two different screen classes derived from the base(16 & 32) that have the explicit (non-virtual) drawing funtions.

You could also (non-OO method) have both of the functions exist, but have a pointer to a funtion that is always set to the proper funtion. (change modes, change the function pointer!)

Share this post


Link to post
Share on other sites
quote:
Original post by Gorky

You could also (non-OO method) have both of the functions exist, but have a pointer to a funtion that is always set to the proper funtion. (change modes, change the function pointer!)



How is that any different (peformance-wise) than virtual functions?

If you look closely, people spend more time trying to work around OOP with their "optimizations" than they spend writing actual working code. Structured programming is simply a very loose (and poor) OOP mechanism. People never think according to functions; they always think in terms of objects. OOP is faster (both development time and run-time) than structured code, when both are properly coded.


I think the original poster was talking about converting each pixel to the proper format. I don't normally do this, but I don't see how it would slow performance if the surfaces are (logically) in the correct format. For example, if you are in 32-bit color mode, don't create all your sprites and such in 16-bit mode and convert every time you need to blit... Color conversion of surfaces is just a glorified pixel-plotting/memory copying algorithm anyway.

If I'm not mistaken, here's what you are talking about:


    1. convert the pixel to 32-bit format and operate on it
    2. convert the pixel back to 16-bit format (if necessary) and plot it





- null_pointer
Sabre Multimedia


Edited by - null_pointer on 4/20/00 8:33:51 AM

Share this post


Link to post
Share on other sites
What I really needed to know was how to quickly
change BPP format when the user wants it int runtime(like in Unreal,
when you just have to change a setting in the menu).
Do they code everything internally and just convert
at the end of each frame??
Or do they somehow, rebuild their surfaces in the correct
format before continuing.
Always worked in 32bpp before, feels like a newbie again

/ Tooon

Share this post


Link to post
Share on other sites
I doubt they do any conversion at the moment of plotting. Usually, a user expects a framerate boost when lowering the bit depth. That probably means that all surfaces are converted and then used as is from that point forward.

On a related note-- none of my imaging software lets me save bitmaps in 16bpp format. Is saving 16bpp .bmp files possible?
Sounds like a dumb question, and yes-- I am embarassed to ask.

[MG]Kaewan

The Mage Guild

Share this post


Link to post
Share on other sites
Don''t be embarassed. 16bpp format is hard to find support for. Most paint software supports 8bpp and 24bpp, but search around, im sure someone has a paint program that can support 16bpp.

Mike Barela
mbarela@earthlink.net

Share this post


Link to post
Share on other sites
null_pointer, I was not trying to help him "work around oop", but instead giving him a fairly fast alternative just in case he didn''t know C++.
Not all C programmers know or care to use C++.
(And some programmers, like myself are forced to work on a mainframe that does not have C++, just strait c. It does not stop a few of us from using OO like coding techniques!)

Share this post


Link to post
Share on other sites
Actually, it might be just as easy to use 24 bit images. Once you have your 16 bit pixel generator function/macro working, you can load in the values straight from a 24 bit file (they are stored 1 byte per color) and then just run your pixel generator on them to get the 16 bit value.

------------------------------
Jonathan Little
invader@hushmail.com
http://www.crosswinds.net/~uselessknowledge

Share this post


Link to post
Share on other sites
Is there any editing software out there that can save a .bmp in 16-bit format? Even a simple program that can convert and save (but not edit) would be handy.

[MG]Kaewan

The Mage Guild

Share this post


Link to post
Share on other sites
quote:
Original post by [MG]Kaewan

Is there any editing software out there that can save a .bmp in 16-bit format? Even a simple program that can convert and save (but not edit) would be handy.

[MG]Kaewan

The Mage Guild


There is no point to saving 16-bbp bitmaps.

Saving in 16-bit format isn''t a valid format because there is no standard as to what that extra bit of info will be used for.

Example: there is no standard for 16-bit, there are about 5 different formats for 16bbp images on a videocard. (5 red, 5 blue, 5 green, 1 alpha (or before all three), also: 5 red 5 green and 6 blue, also: 4 alpha, 4 red, 4 green, 4 blue).
Thus is why no one ever writes a 16bbp bitmap file because it wouldn''t load on another computer who had a different 16bbp scheme.

There is, however, a standard for 24-bbp bitmaps, 8 bits for red, 8 bits for blue, 8 bits for green. 24bbp bitmaps can then be easily converted for 8 bit mode, 16 bit mode, 24 bit mode (duh), and even 32bit mode. Thus this is the format of choice.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!