The FindPNG module fails catastrophically on Mac OS because it searches
for the library and header independently, and ends up pulling a
completely unrelated header from a random framework.
The musl getopt does not swap arguments and requires every option to
precede every non-option. Do that in the CMake functions generate_g1a()
and generate_g3a().
* Use [find] for sources since it's used for dependency files...
* Get fxconv parameters from fxconv-metadata.txt
* Approximate dependencies: every asset depends on every metadata file
* Update location of example image
* Add the CMake build system
* Use CMake as the default for new projects
* Change [fxsdk new] but continue supporting the previous signature
* Automatically configure in [fxsdk build-fx] and [fxsdk build-cg]
* Improve help screen
The internal name is required to exist and have a certain format for the
add-in to appear in the main menu; this should be enforced at the lowest
possible level to avoid unpleasant surprises.
This change defaults the internal name to essentially @INTERNAL, where
the letters of INTERNAL are the upper-case variables of every letter
found in the standard name (up to 7).
The fxSDK will no longer specify the final values for these parameters,
leaving them to the user in CMakeLists.txt or project.cfg, as reasonable
defaults are good enough.
This change adds a new way for fxconv to discover metadata for file
conversions. This complements the existing mechanism of passing
parameters on the command-line.
The new mechanism activates when fxconv is called without a type
argument. Type information and metadata are searched in an
fxconv-metadata.txt file in the same folder as the resource. The
metadata file lists parameters, with some additional flexibility enabled
by the use of wildcards.
This way of declaring will replace command-line argument passing, which
currently read parameters from the unreadable and not-so-maitainable
project.cfg file. Both the GNU make and CMake build systems should use
it in the future. The current way is still supported only for older
projects and one-shot conversions outside of projects.
ObjectData is a stream-like object that accepts bytes, bytearrays,
references to external variables and references to other bundled data to
create structures with pointers without having to write assembly.
Internally ObjectData unfolds into static data and an assembly
instruction. Existing assembly support remains fully compatible.
* Added an ObjectData interface to ease reference generation
* Ported topti to ObjectData (instead of assembly)
* Ported libimg_fx and libimg_cg to ObjectData (idem)
Custom conversions can be used by:
* Providing a converters.py in the main directory with a convert()
function
* Specifying --custom on the fxconv command-line or using a subfolder or
assets-{fx,cg} unused by standard fxconv