home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / os2 / programm / 7855 < prev    next >
Encoding:
Text File  |  1993-01-21  |  2.6 KB  |  65 lines
  1. Newsgroups: comp.os.os2.programmer
  2. Path: sparky!uunet!pipex!doc.ic.ac.uk!agate!usenet.ins.cwru.edu!gatech!news.ans.net!cmcl2!panix!os2man
  3. From: os2man@panix.com (Larry Salomon Jr.)
  4. Subject: Re: Problem: Nasty Bitmaps
  5. Message-ID: <C17not.Cpq@panix.com>
  6. Organization: PANIX Public Access Unix, NYC
  7. References: <1993Jan21.083211.3396@neptune.inf.ethz.ch>
  8. Date: Thu, 21 Jan 1993 15:43:41 GMT
  9. Lines: 54
  10.  
  11. In <1993Jan21.083211.3396@neptune.inf.ethz.ch> rofische@iiic.ethz.ch (Roman Fischer) writes:
  12.  
  13. >we are currently writting a game running under PM. The basic idea consists of
  14. >two players simutaneiously fighting against a set of evil monsters. So we need
  15. >lots (~20) of small bitmaps that move around the screen (window).
  16. >The bitmaps were created with IconEdit and are loaded with GpiLoadBitmap. Since
  17. >we need 4 versions of every monster (looking to the left, right, up and down),
  18. >we need to "turn" the bitmaps. Because we don't want to change 4 bitmaps if
  19. >we decide to change the look of a ghost, we decided to turn them "by software"
  20. >at program-startup. So far no problem.
  21.  
  22. I want a copy when you're done!!!  :)
  23.  
  24. > <stuff deleted>
  25. >The original size of the bitmaps is 20x20 pixels. When loading, we resize them
  26. >to 36x36 pixels. Now, when reading the data into the buffer, the x-dimension
  27. >is 40 !!!!
  28.  
  29. >This means: a. GpiQueryBitmapInfo returns a cx value of 36 (as expected).
  30. >               But a short look at the data received from GpiQueryBitmapBits
  31. >               shows, that every scan-line consists of 40 pixels (20 bytes).
  32. >               
  33. >            b. You cannot use cx to calculate the offset of a pixel.
  34. >               To calculate the correct offset, you need to know the number
  35. >               of bytes per scan-line.
  36.  
  37. >            c. If you don't know the original size of the bitmap, you cannot
  38. >               tell the correct way to address a pixel within that bitmap !!
  39.  
  40. >Now:
  41. >a. Did we miss an important part in any doc ? 
  42.  
  43. Yes, you did.  Bitmap bits are padded right to the next double-word boundary.
  44.  
  45. >b. Number of bytes per scan-line, any idea?
  46.  
  47. Use this formula (from the documentation) to calculate the number of bytes
  48. per scanline needed:
  49.  
  50. HBITMAP hbmImage;
  51. BITMAPINFOHEADER bihInfo;  /* Use BITMAPINFOHEADER2 if 32-bit app */
  52. ULONG ulSzBuf;
  53.  
  54. GpiQueryBitmapParameters(hbmImage,&bihInfo);
  55. ulSzBuf=(((bihInfo.cBitCount*bihInfo.cx)+31L)/32L)*4L*bihInfo.cPlanes;
  56.  
  57. If you have any questions, send me email.
  58.  
  59. Cheers,
  60. Q
  61. -- 
  62. "If you choose not to decide, you  | "My other body is in the shop" - seen
  63.  still have made a choice" - Rush  |  on a T-shirt
  64. ------------------------------------------------------------------------
  65.