We've all screwed around with the rgb() proc once in a while, and sometimes we find a pretty good use for it. The only problem with it is that no matter how to try to do it, its always going to be CPU-intensive; therefore underused and less appreciated.
So, whats the point of using rgb() if its just going to drain sources and cause considerable lag?
This brings me to a post a made a while ago when talking about dynamically changing the color of text box windows in game. The best solution was to draw the sprites before hand in separate colors, limiting the selection of colors as opposed to allowing the user full control over the color itself. Regardless of how CPU intensive it is, it won't sway me from using it; however, I feel as though it will only subtract from the players value of the game when they see even a half-of-a-second lag.
Therefore, I pose a question: Is it possible to create the same effect without using as many resources and without having to draw the sprites separately, or are we doomed to the existence of an inefficient procedure?
Apr 16 2009, 8:11 pm