I'm using ARAnyM, I don't know how much this patch may be efficient on real hardware
xaaes.cnf
: textures_cache = <0|1> (boolean)
. When cache is disabled (0), no new code is executed at all. Obviously, textures
must be enabled (non-zero)/var/cache/xaaes/
must be manually created (if not, files are not added to the cache). No other subdirectory is required (in order to limit filesystem operations)Why not AES-home_path/widthheight.depth
? The user may switch from 1024x768x32 to 640x480x32 but the cache file will be the same
Why /var/cache/xaaes
? 1) It's more FHS
W
-compliant, 2) No need for a new variable to specify the path, 3) IMHO MiNT system dir is the wrong place to write this kind of file
xxxxyyyyyyyyppp.zzz
.To quickly create a filename, I use dev (int16)
and index (int32)
fields of XATTR
(extended attributes) because they both uniquely identify a file.
Thus, there is no need to store an index: the filename IS the index.
So, the length of the file name is at least 4 (xxxx) + 8 (yyyyyyyy) = 12 characters (without extension) ppp is the palette's name (without pathname). Unused if nplanes>8
Without this info, the result may be wrong in modes <= 256 colors. Example:
- set
palette=gem
- run, cache is filled with prerendered bitmap with palette 'gem'
- set
palette=nvdi
- run, cache returns prerendered bitmap with palette 'gem'
zzz is the number of planes in order to allow caching the same file for each color depth in the same directory
No new files, 3 changed:
cnf_xaaes.c
and xa_types.h
=> new cfg.textures_cache
trnfm.c
=> 2 new functions (get and put) + 1 change (load_image).
Binaries: xaaes-20220718.zip
Current implementation | Patched implementation |
---|---|
+ image_cache_get. If success, return. Else, continue | |
= depack file | = depack file |
= remap colors | = remap colors |
= change pixel format | = change pixel format |
+ image_cache_put |
/var/cache/xaaes/<dev><index><palette>.<depth>
(if exists) /var/cache/xaaes/<dev><index><palette>.<depth>
<XATTR><XAMFDB><DATA>
Inside XATTR, last access date and time are set to 'XC01' (XaAES Cache v0.1) as magic value
Why? access date/time may be updated but the file stays the same, this info should not be checked
A magic value allows further development (i.e. if future code checks XC02, image_cache_get will automatically delete all old XC01 and image_cache_put will create new XC02)
xaaes.cnf
to change the custom palette.
I tried to put the palette filename in the full cache filename but while it is working if the palette is set in xaaes.cnf
, there can be some trouble after loading a new palette with ctrl-alt-shift-P
.
If a .img is loaded AFTER changing the palette, the cache filename will include the palette name from xaaes.cnf
but the bitmap is remapped using the newly loaded palette.