Possible means to speed up Bitmap TONE code?

[DerVVulfman]

Nonetheless, your benchmarks, whether hypothetical or not, would be worrisome for a method that only needs to keep track of a single color. I wonder why that'd be quite slow here.

Oh, it's not keeping track of a single color. This method takes the values supplied, goes through every pixel, alters the color of each individual pixel, and reapplies based on the values provided.

Unfortunately, I expect it would be just as slow with your invert scriptette since it too needs to go through every pixel, acquire the pixel color, and reapply with set_pixel with an altered color.

I believe Tone is a read-only Sprite property with Viewport having ownership of the Tone object in question. In other words, I don't think any of the Sprite objects holds a unique Tone, I believe it all goes back to Viewport. When referencing sprite.tone, I believe you're receiving sprite.viewport.tone. If you were adjust the "sprite's tone", you'd be adjusting the global tone used for all sprites, hence why they don't have sprite.adjust_tone.

Nope. Both the Sprite class and the Viewport class have 'tone' properties that may be applied. So you can change the tone of a viewport and make it deep red, and apply a deep green to a few select sprites as well. SCREWED UP TONE ATTACK, HOOOO!

Insofar as the math, you would assume colors are 0-255. But to reduce the brightness, you apply a negative version. So the actual adjustment range is from -255 to 255.

And colors range initially from 0-255. Now if the image is quite white, you would need to reduce one (or more) of the three color values down to -255 to make black or near black. No rounding values to percentages... gotta be specific to the individual units.

Ahem... could be food for thought to include such additions in C++ code for ReGaL and/or Hidden Chest to permit such commands.

So no one would have knowledge of any means to use DirectDraw or applicable functions in place?