Thing is, the only trig you'd need is SIN and COS - which should be blisteringly fast. I think trig get's to be a bottleneck when you have to convert back and forth, like work out angles and distance.
I think though, it depends on how old-school you are - there are ways you can make things really quick. For example, pre-storing SIN in an array, and using that instead of sin() - if the engine can deal with the loss of accuracy, then things like that can really improve performance. Also, using SQRT to find distance, if you make a 2D array, you can pre-calculate that as well. I haven't done a lot of this stuff recently, as most of the time it's pointless, giving processor speeds. But if your checking hundreds of distances per loop, then this stuff can really help.
Scaling and rotation though, is the real reason why I suggested storing angle and rad. When I did this, I only used bytes, so instead of 360 degrees, I used 0-239 - so multiplying by 1.5 to get the real angle. This gives a snap of course, but it allows for exact 45 degrees, and is not too far from 360. The extra 240-255 values I used to signify the end of line loops etc. The radius was stored as 0-255 too, which got factored in the actual size of the sprite. So, with 2 bytes I was able to store a point that could adapt to scale and rotation quite easily and quickly. I made a little editor to let me trace the lines around sprites and save the data - storing the angle and radius of each point. One other benefit, is that you can store a collision set, and use it each time for each matching sprite - rather than rotating actual data, you might just have a big list of coordinates, which is filled from the angle and radius data, maybe keeping track of which line belongs to what sprite. This is a good way to avoid floating point problems, because the line data itself would be generated from angle and rad data - I can imagine that it would be quite hard to get an angle to exactly 0.0 with residual data.
Health, Ammo, and bacon and eggs!
