Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/th02/sprites/sparks.h

6 lines
120 B
C
Raw Normal View History

[Maintenance] Decide how to handle pre-shifted sprites in C land Ideally, the future sprite compiler should automatically pre-shift such sprites, and correctly place the shifted variants in memory, by merely parsing the C header. On disk, you'd then only have a .BMP with each individual cel at x=0. And that's why we need macros and consistent naming: To express these semantics, without having to duplicate the sprite declaration in some other format. sSPARKS[8][8][8] wouldn't help anyone 😛 Now, we could go even further there by defining a separate type (`preshifted_dots8_t`), and maybe get rid of the _W macro by replacing it with a method on that type. However, • that would be inconsistent, since we'll need the _H macro anyway, for both the actual rendering code and the sprite compiler • we couldn't directly call such a method on a 2D or 3D array, and have to go down to a single element to do so (`sSPARKS[0][0][0].w()`) • making it a static method instead duplicates the type all over the code • and any variables of that type would no longer be scalar-type values that can be stored in registers, requiring weird workarounds in those places. As we've already seen with subpixels. Part of P0085, funded by -Tom-.
2020-03-25 14:22:51 +00:00
#define SPARK_W 8
#define SPARK_H 8
#define SPARK_CELS 8
extern const dots16_t sSPARKS[PRESHIFT][SPARK_CELS][SPARK_H];