3

6/4/14

I need to (if possible) create a surface in SDL 1.2 where the bpp = 1. bpp is Bits Per Pixel.

I'm working in 100% black and white, the 'surface' size is so ridiculously large my physical memory is bottle-necking me. I have 4GB of ram, and the program needs to run on budget machines, meaning 2-4 gigs. I've been using a color depth of 8; I imagine I'm wasting about 3/4 of my memory realistically? I'm saving the surface as a .bmp file, which is supposed to support a black/white format where bpp = 1.

Is there any way to lower the bpp in SDL or should I look for an alternative?

6/5/14

I hit a bottle-neck on my machine at about 39000x39000 pixels at a color depth of 8 bits. Because SDL stores surfaces in physical memory, I'm running out of RAM. Processing power is not an issue as I'm rendering a still image. I'm hoping to double that resolution, but I'll take what I can get. Yes I can potentially split the image into multiple files, but because it will be high-res laser printed at a later date, it will have to be open as a single file then anyways. The goal is to package the program as a single unit, not requiring additional steps to stitch and convert the images later in another program.

SDL and c++ in general don't seem to have support for single bit variables (bool not included), so assigning a color value to a 1 bpp pixel using SDL is beyond me.

Rivin
  • 27
  • 3
  • Your issue seems odd. While it is good to choose the proper file format and not waste memory what size is your image data that creates a bottle-neck on 2-4 GB machines? And where is the bottle-neck, write IO, CPU, etc? – Samuel Jun 05 '14 at 06:37
  • "I'm saving the surface as a .bmp file." `.bmp` is trash, don't use it if you can avoid it (especially on 'budget machines'). Use PNG instead; afaik it also supports 1bpp images, and will actually compress them. – Colonel Thirty Two Jun 05 '14 at 18:27
  • 2
    @ColonelThirtyTwo: While PNG will save disk space, it will not help with memory use when the surface is loaded. SDL surfaces store uncompressed image data. – Jon Purdy Jun 05 '14 at 18:29
  • Can you elaborate on what you are doing? It looks like you should split those images into sensible chunks. Otherwise disk I/O will be your next problem. – Piotr Praszmo Jun 05 '14 at 18:30
  • Thank you very much for the input!Is there maybe a library that can handle the small variable sizes I need to manipulate the pixel data? It seams modern architecture is far beyond manipulating bits and bytes individually. – Rivin Jun 06 '14 at 01:36
  • I have worked with 1-bit surfaces in SDL--not gigantic sized, though. In my experience I ran into a few bugs in the implementation where it was clearly not tested in 1-bit mode. Good luck to you, but you may find that SDL is not a good fit for your situation. – StilesCrisis Jun 06 '14 at 01:44
  • @StilesCrisis: I tried it and I think I know what you mean by bugs. Its like it cant even recognize the surface even though it declares it correctly. Very hard to work with. Did you end up using another library instead? – Rivin Jun 06 '14 at 01:55
  • In my case, 1 bit was a small part of a large project so I kept SDL but worked around the bugs on a case by case basis. – StilesCrisis Jun 06 '14 at 05:08

0 Answers0