Bitmap problems

Started by
5 comments, last by Programmer16 18 years, 9 months ago
I've got code that I've written (actually, most of the loading code I've 'borrowed'), but I'm having problems. When I load a power of 2 texture, the code works perfectly. But when I try loading, say a 34x34 bitmap it goes haywire. None of my code works correctly. The only thing that gets close is my saving routine, but that still screws up the last line. I'm on a different computer than my code is on so I can't give the exact code, but it's mostly the same. All data is unsigned integers. I access the data using the algo (Y * WIDTH) + X All Y loops come first and are 0-(WIDTH - 1) All X loops come after y loops and are 0 - (HEIGHT - 1) All of my colors are 32 bit (except its loaded and saved as 24bit.) If you need me to post actual code, then I can (I just didn't want to waste my Grandpa's CDs.) These are just regular 24bit bitmaps Thanks! PS: I might not be able to get out here to post anything for a few hours since this is my Aunt's computer.
Advertisement
You have to explain beter what's going on. Yes, post the code.

cheers
Ok, I don't have any CD at the moment, but I can post it pretty much from memory:
class CBitmap{    uint* m_pData;    uint m_nWidth, m_nHeight;    SBmpInfoHeader m_InfoHeader; // Same as BITMAPINFOHEADER, extras    SBmpFileHeader m_FileHeader; // Same as BITMAPFILEHEADER, extraspublic:    CBitmap(uint nWidth, uint nHeight);    CBitmap(const char* pFileName);    bool Create(uint nWidth, uint nHeight);    bool CreateFromFile(const char* pFileName);    uint GetPixel(uint nX, uint nY) const;    void SetPixel(uint nX, uint nY, uint nColor);    uint GetWidth() const;    uint GetHeight() const;};

uint GetPixel(uint nX, uint nY){    return m_pData[(nY * m_nWidth) + nX];}void SetPixel(uint nX, uint nY, uint nColor){    m_pData[(nY * m_nWidth) + nX] = nColor;}uint GetWidth() const{    return m_nWidth;}uint GetHeight() const{    return m_nHeight;}

for(int iY = 0; iY < Bmp.GetHeight(); ++iY){    for(int iX = 0; iX < Bmp.GetWidth(); ++iX)    {        uint nR, nG, nB;        GetComponents(Bmp.GetPixel(iX, iY), nR, nG, nB);        SetPixel(Paint.hdc, iX, iY, RGB(nR, nG, nB));    }}


I'll direct you to this page for the loading code (mine is almost exactly the same, except I zero out the info/file header first.)

Edit: Ok, I tried a different picture and it looks like the data is being read wrong somewhere (the bitmap is on a slant:
|~~~~~~~||  //   || //    ||//     ||~~~~~~~|


The first / is supposed to be the right and the second is supposed to be the left (and they're suppossed to be straight.)

Edit 2: Ok, I don't understand how it can save almost perfectly, but when I try rendering it, it gets screwed up so badly. I'm using the same code to do both (pretty much.)

[Edited by - Programmer16 on July 26, 2005 2:26:45 PM]
Look up padding -
what happens is the data is padded with some extra bytes at the end of each line.
I don't have an immediate link for ya, but that's what it sounds like is going on. What it means is, you'll have to read in those extra bytes per line.

Hmm, I haven't read your code, but you also know to read the offsetbits flag and all that jazz, right? If not, you'll have more woe and trouble later on - you might eventually be better off using some image loading library...
Good luck - btw, dxsdk help has some info on padding, etc, if you have that around.

-Michael g.
I had posted about that and was told that I didn't have to worry about it because I wasn't working with data on the graphics card (or something like that.) And why would it work fine as power of 2s, but not for any other size?

IIRC the pitch is in memory and is card specific, so its not saved in the bitmap file.

Edit: Also, I'm using Win32 GDI to render this, not DirectX (although that is what it will ultimately be used for (and yes, I have planned for pitch.))

Thanks for the reply!
To tell you the truth, I never bothered with it, but it sure appeared to be a data padding issue to me. To check this with your data, save an image in a paint program, with all some color (like white - not black though) open the image in a hex editor and look for the ascii character 0's at the end of every
line (every width*3 bytes)

(just did this with ms paint and edit, it looks like the data is padded to be divisble by 4)

Have fun!
-Michael g.
Well, I guess I try padding it. That would also answer why it works for pow2 sizes.

Thanks!

This topic is closed to new replies.

Advertisement