Two minor things bug me a bit when writing Codea programs.
The vec2 class is really useful but when it comes to drawing, I have to decompose them back to coordinates. I’d like versions of the drawing functions that take vectors, not x and y coordinates.
Color components are in the range 0…255. I find that any code I write that calculates colors calculates 0…1 and then has to scale the results by 255. I’d really like color components to be in the range 0…1 by default.
The color class doesn’t have much useful behaviour. It would be great to have an HSVA color class with useful functions for doing color manipulation: lighten, darken, fade alpha up and down, rotate hue, etc.
These all sound like reasonable things for a wrapper library, ie. someone could just write them and share the library.
I’ll be honest - I’d rather see the devs spending their time on things we user-devs can’t do (bug fixes, or API additions) than stuff we can do ourselves.
One nice thing about lua is you can just override the API function with your own (save the names off so you can call them yourself, of course). So… Do it! I’d love to see a library that let us do color manipulation like that (it would have been handy for my font demos) - this sounds like an interesting project.
This is actually fairly easy and would be nice to have. We might be able to build in vec.xy on vec2 that unpacks the arguments. swfille(?) tried this without success. But it might work when added to the C library for vec2.
I actually prefer 0…1 as well, but in copying Processing’s model I also copied their 0…255 range. Perhaps that wasn’t a wise choice, but it can’t be changed now.
I think we will build on the color class over time, HSV is easy enough, as are the other methods you mention.