Well, the thought process here is reducing the decompression time during the load. I'm on an embedded platform so it's a fairly underpowered cpu with low memory constraints. I want fast load times, as well as fast blitting, and reasonable on disk size.
For loading PNG or JPG, it essentially decodes them into surface with the proper display format, and then I rle the surface. I'm trying to cut out a step of the loading.
Though the internal sdl rle encoding is optimized for fast blitting, I've found that for most images, the data size is smaller than the raw data. In some cases, it's larger, but not by much.
Rather than having to decode and then rle, I'd like to be able to load (or memory map) the rle data directly. The idea here is that the rle is smaller than just the raw data (most of the time), it's already optimized for blitting, and the loaded images also uses less memory.
Yes, JPG or PNG would take up less space, but I'm trying to find the happy medium between disk size, memory usage, loading, as well as fast blitting.
On Tue, Oct 21, 2008 at 10:42 AM, David Olofson <david@xxxxxxxxxxx>
On Tuesday 21 October 2008, Frank Grime wrote:[...]
> I've been playing around with this idea of saving and loading the
> internal sdl rle internal format, in order to improve load time, as
> well as keeping on disk size down...
> Does this make any kind of sense?
Not really... RLE (Run-Length Encoding) can indeed be used for data
compression, but the internal SDL RLE encoding is designed for fast
rendering (no per pixel transparency checking required for colorkey
and alpha blits) rather than data size.
You're probably much better off using PNG, or (in some cases) JPG.
PNG features effective non-destructive compression, and supports an
alpha channel for translucency effects and antialiazing. Just save
with maximum compression for minimal size. (Some applications use a
lower degree of compression by default, probably because it can take
quite a while to compress a high resolution digital photo with the
JPG is destructive, but for some types of images (typically "normal"
photos and similar material), it tends to generate much smaller files
than PNG or similar. Just try it and see if you can compress enough
without unacceptable artifacts. (Any serious image editing software
should have a preview feature that gives you the final result and the
file size as you adjust the compression settings.)
The downside of JPG is that it doesn't support an alpha channel, and
due to the compression method, it doesn't really work with
colorkeying either - so in games, it's kind of hard to use for
anything but tiles, background images and the like.
You might get away with saving the alpha channel out as a separate PNG
(should compress really well, as it's mostly fully opaque or fully
transparent, except around antialiazed edges), and then merging it
back with the color channels from the JPG into an RGBA surface at
load time. I suppose that's basically what JNG
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
SDL mailing list
SDL mailing list