XaAES: support for texture cache
XaAES: texture cache
- Improve loading of bitmap (textures) by storing already converted .img files according to the current video mode
I'm using ARAnyM, I don't know how much this patch may be efficient on real hardware
How
- A new variable is added in
xaaes.cnf:textures_cache = <0|1> (boolean). When cache is disabled (0), no new code is executed at all. Obviously,texturesmust be enabled (non-zero) - A directory
/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
Requirements
- Long filenames, because files are named
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
The patch
No new files, 3 changed:
-
cnf_xaaes.candxa_types.h=> newcfg.textures_cache -
trnfm.c=> 2 new functions (get and put) + 1 change (load_image). -
Binaries: xaaes-20220718.zip
Internals
load_image()
| 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 |
image_cache_get()
- open file
/var/cache/xaaes/<dev><index><palette>.<depth>(if exists) - check size, date, time (attributes) (attributes of the source file are already known because we need them to create the filename)
- if details match, return data, else delete the wrong/outdated file
image_cache_put()
- write file to
/var/cache/xaaes/<dev><index><palette>.<depth>
file format
<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)
Notes
- Files in cache directory are not automatically deleted. If a lot of images generate files in the cache, and these images are deleted, the cache files will remain, i.e. there is no expiration date or quota on the cache folder
- The cache must also be cleared if you edit
xaaes.cnfto 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 inxaaes.cnf, there can be some trouble after loading a new palette withctrl-alt-shift-P. If a .img is loaded AFTER changing the palette, the cache filename will include the palette name fromxaaes.cnfbut the bitmap is remapped using the newly loaded palette.
