Well, if you have access to the pixel data, then resizing becomes a lot more feasible, and I'm not talking about resizing by doubling, tripling, etc. the size.
If you're interested, you can try to use this code
and fit it to the use of your own pixel format.
Nice MIDP 2.0 code schmoove! Thanks for sharing that with everyone!
The biggest drawback with your method though, is that you can't have any transparent pixels because Image.createImage(int,int) creates a fully opaque Image to begin with.
That's a good point. Since my current game uses rectangular sprites, I'd forgotten all about mutable images being opaque.
The only way around this problem would be to write a png encoder so that you can take your format and transform it into a png that does support transparency.
Not to fear! There is another way! :-) What is needed is a "sliver" engine. The idea would be to scan the longest dimension into individual lines of pixels. By trimming the transparent area off of each line and saving the offset, you can draw the complete image on screen by looping through each sliver image. The method could be further optimized by grouping slivers that have the same length and offset.
Believe it or not, there is some precedent for such a design. Raycasting engines ala Wolf3D and Duke Nukem 3D make use of "scaled slivers" to produce 3D effects. The design is really an advanced form of 2D scaling for 3D effects that had been in use since the days of Pole Position. The primary difference in Raycasting was the addition of true spatial calculations (somewhat costly trig).
If you are using a midp1 device that doesn't check the adler or crc32 checksums on png files, you could use a png that has an uncompressed zlib stream inside it, and Image.createImage(byte...).
You would then effectively have per-pixel access, the only cost would be a native mem copy during createImage(byte...)
Abuse, I've often heard talk of this method, but I'm curious if you've ever actually seen someone use it? I tried stripping down a PNG encoder about a year ago, and I was not pleased with the results. The encoder itself can easily take up as much space as an entire game, and is rather tricky to code and test.