When loading a bmp file, if the code guesses a palette size LARGER than the bpp would allow, it still loads it all as a palette. Shouldn't it truncate?
Date: 24 Mar 2011 14:32
Number of posts: 6
RSS: New posts
Also too much stack space reserved in ZLib stuff… in some situations it fails badly
- In deflate encoding, maxLen should be recalculated in case it is already == bits.
- Somewhere in the encoding when a bestMatch is found, there is a nasty little memory leak or something that eventually accumulates…
- Should not use STL in code. One example scenario:
Using MSVC, have a project set up that uses precompiled headers. Precompiled headers include STL stuff, and define _SECURE_SCL in some way or another. Also, project includes LIL files or statically links a LIL library, but _SECURE_STL doesn't match. Linker links some code to STL as if _SECURE_SCL is one way, and also links other code as if it is the other way. These 2 ways get mixed up in a single process. Explosion. Days debugging with no clue what the problem is.
Lesson to take home from this? Don't use STL in library code unless it is ONLY dynamically linked. Urgh.
LilIoPngWrite only writes 1 correct (large!) chunk. It is all wrong.
PNG preview in windows explorer is complete garbage even though the library itself reads them fine. The header flags in the zlib stream (not deflate stream!) are wrong! Lib is indicating a window size of 256, when it should be 32k!