I'm a great big ol' fan of the PNG format (check out http://www.libpng.org/pub/png). Better compression than GIF, no lossiness... loads fast, loads nice. ( =

Edit: Sorry 'bout that. I asked a question you answered in that third paragraph. I shouldn't be awake right now.

What kind of problems are you having?

[edited by - RavenEris on August 15, 2002 8:02:24 AM]

So you''re using FindResource() and LoadResource()? Just checking.

What kind of problems are you having? I prefer using fopen() myself... does the library you have not let you load from memory? Only from disk? Most do.

If the textures are photorealistic then you''re probably better off using JPEGs... but if it''s not, you might be able to finagle better compression out of PNG... I haven''t needed to play around with the compression settings myself, though.

Seems like the main problem is that both of these libraries ask for files, not for memory spaces... Maybe if you did a LockResource() and wrote the image to disk temporarily? Using a call to SizeResource() perhaps? Check out GetTempFileName()... maybe you could do that...

Also, you may want to think about putting these images in their own files on disk anyway, since they''re huge when loaded... that''s a pretty big memory footprint.

These are all just ideas and babble, no criticisms. ( =

Well, the libpng allows you actually to use a custom read function, so you you can load the bitmap from memory (and so from a resource).

Yeah PNG is a really nice format... best I''ve ever seen actually. It can be told to compress with no quality loss (compressed color maps and RLE, etc.) or compress like JPEGs, etc. They can also have tranparent colors and (I think) be animated. (??)

However, they are a bit more difficult to load than other images... athough only marginally. Depending on your needs though, you could use TGA. It only has RLE compression, but it can be of any color format as well. Depending on your image, RLE might even end up being the best compression there is.

So TGA might work, and it is very easy to load... but if not, PNG is a really nice format too. Both can also have Alpha channels and can be loaded as textures if you ever feel like moving to DX Graphics.

I hope you aren''t assuming that you can load a compressed format onto a surface and use it as is. Most video cards don''t support a variety of compressed formats. The blitter may convert the format for you to a compatable format on the fly (doubtly though), but this is VERY slow.

For instance, I attempted to load DDS files onto a TNT2. Worked fine, and I was ever able to use them with without converting them myself, but it was slower than molasses.

Fortunately, I found some code that could enumerate the surface formats and choose a format that was compatable with the compressed image. This is a great idea since you don''t know what formats the hardware supports upfront.

storing images in a dll resource is a bad idea. create your own simple pack file format or use straight images. its easier in the long run, and less windows overhead (ie the whole mapping the dll to memory space, etc). while its nice and easy to use windows functions for dealing with images its not the best option. use a jpeg library or png library. libpng allows you to override the read/write/open/close function so you can use memory to mimic a file if you wish. same iwth teh standard jpg library from the jpeg group. png would be best fro anything that required keeping the image exact (ie for masks, sprites with masks, etc). jpg is better suited for full screen images. they can be quite good quaulity assuming teh image manipulator you use allows you to set the quality to 100 instead the default of ussualy 75. this quality of 0-100 determines how much compression is done. the number dont translate directly to savings (at least i dont think, i have not looked into the jpeg algo and how the number is used in depth). its more a rough estimate and osme images can use a lower quality setting without noticing a difference.

using d3d functions is bad. that is a roundabout way of handling things and will lead to problems.

qriting a resource in a dll to disk for reading by a library is VERY bad. i dont want some game writing temp files for resources which could have just as easily been stored seperatly since that is how they are being loaded.

win98 and higher support loading images directly form resources using LoadImage() (pretty sure). you could do that and neglect win95 users who are left. i would not, but thats your desciion.

personally i think you should spend the time to learn to use libpng and the jpeg group library. you should also go ahead and create your own resource format. this will allow better control and ease of use compared to the limited dll resource approach. for instance your not at the whim of windows in how mcuh of the dll gets loading into memory when dealing with the resources. though you could just use seperate image files for things.

if you even think about syaing you are attempting to protect the artwork please realize its less then trivial to read the resources from a dll by anyone who want the artwork (plenty of such utilities exist, you even use one of them).