> Since Kyzrati stated he won't go UTF-32, and instead is thinking about sprite sheets, then you should use my 4 x uint8_t instead of the uint32_t, and then merge your read operations.
Yes, I think I'll try and see if I can do that. That would cut down immensely on the number of reads. As for the possible future capability of XP to index arbitrarily-sized spritesheets, I think it's best to build the library to support what XP can actually do now, as opposed to what it may do later. Particularly if that allows code simplification.
> Your REXSpeeder library also has a buffer overflow if the width and heights are maliciously set for each layer.
I'm not worried about security for REXSpeeder until the need arises. Feel free to convince me otherwise. But if this particular vulnerability can be fixed with just an at() then I might as well fix it. thanks.
Yes, I think I'll try and see if I can do that. That would cut down immensely on the number of reads. As for the possible future capability of XP to index arbitrarily-sized spritesheets, I think it's best to build the library to support what XP can actually do now, as opposed to what it may do later. Particularly if that allows code simplification.
> Your REXSpeeder library also has a buffer overflow if the width and heights are maliciously set for each layer.
I'm not worried about security for REXSpeeder until the need arises. Feel free to convince me otherwise. But if this particular vulnerability can be fixed with just an at() then I might as well fix it. thanks.