You can always define your own physics shape, adding the lines one by one - that way you could store the data. It might be worth adapting that data though, as vector rotation isn't really something you'd want to mess with if you don't have to. I mean, the physics shape could be stored as angles and radius rather than 2D X and Y, and that would make it real easy to calculate positions for rotated or scaled sprites. When you define your own physics shape, there is no hard limit on the number of lines/points you can add. I have used this in a game that relied on line to line intersection for collisions, works pretty well but really you need some sort of editor to do it properly.
To then draw the shape, you'd plot lines on a memblock and flood fill from the centre. This means that all your sprites would need to be convex, which is typically the case anyway. Sadly, flood fill routines are notoriously difficult to explain, to learn it, it's better to experiment and make your own - but if you just need it working then I'm sure I can knock up a line and fill memblock example for you. By doing it this way, you'd be able to control alpha levels, add a little anti-aliasing, stuff that might be tricky with other methods. You could use the shape data for the collision and physics, and use the same data to draw the shape in solid colour.
Remember though, you can just colour a sprite black and a bit transparent (like 0,0,0,128) and it'll be a shadow - all the pixels would be black with 50% alpha transparency. This is a good, cheap way to make a shadow version of a sprite. If you use pixelated sprites and filtered shadow versions it does look cool, tried this in an old project and it ended up looking far better than I expected.
The code is dark and full of errors
