1.How do you load bitmaps. Via windows functions or Dx7 sdk helper library.I just wondered is it worth of trying own Bmp loader class. 2.I look at wotsit´s documents and saw line "BMP files are stored bottom-up, that means that the first scan line is the bottom line. " is that true.HEH.It sounds so weird

look through the ddraw sdk samples, theres a header called "DDUtil.h" with a DDLoadBitmap func.

the rest should be a breeze

There''s been an article written on it by kieron_j look around this site.

>>How do you load bitmaps. Via windows functions or Dx7 sdk
>>helper library.I just wondered is it worth of trying own Bmp
>>loader class.

Try every method and use what works best for what you need.You should at least try to write your own loader, the info comes in handy (if you ever plan to use different formats).

>>I look at wotsit´s documents and saw line "BMP files are
>>stored bottom-up, that means that the first scan line is the
>>bottom line. " is that true.HEH.It sounds so weird

Yep.





----------
meh

Not all bmps are stored bottom up. I can''t remember exactly how but I''m sure there was some way of finding out if it''s flipped or not.

/CMN

Why are bitmaps stored upside down in the first place? They''re certainly
not displayed like that. And I see nothing in terms of speed or performance.
Is this is feature that was lost a long time ago and now not used?

To CMN:
You can check wether a bitmap is flipped or not by looking at its height value. If it is negative (e.g. -512) then it is flipped.

Yeah, that''s what I thought.

But isn''t a DWORD unsigned? At least MSVC++ tells me that each time I try to compare an int with a DWORD.

/CMN

I use unsigned int instead of DWORD and its unsigned i think

Edited by - jaxks on June 29, 2000 4:14:24 AM

"Why are bitmaps stored upside down in the first place? They''re certainly
not displayed like that. And I see nothing in terms of speed or performance.
Is this is feature that was lost a long time ago and now not used?"

This is because OS/2''s coordinate system started like the Cartesian coordinate system - bottom left corner. You see, OS/2 was the origin of DIBs.

Actually, I''ve been having some trouble myself. I want to access directly the bits on a possibly 16-bit surface with a COLORREF, but I haven''t been able to figure out how to encode the 24-bit value into a 16-bit one, even with Charles Petzold''s explanation.

CMN: I''m confident that biHeight is not an unsigned integer, but then I could be wrong.

Also, a top-down DIB is not desirable because when you want to access its bits directly - 0,0 no longer maps correctly to the first byte of the last row.

About kieron_j''s article: He mentions Windows doing the work of matching the palette. It may not always be the best idea, especially if there is no active palette - then Windows only shows 20 colors of the DIB - those that map to the static colors always in the palette manager.