06-11-2023, 09:41 AM
(This post was last modified: 06-11-2023, 09:46 AM by Kain Nobel.)
(Note to self: Install RPG Maker XP on this machine. Also, disclaimer; I'm going off of memory, everything I said below could be wrong.)
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.
(Correct me if I'm wrong^)
To do the math on the Tone, you could possibly normalize the values from 255 to a 1.0 based value, get the percentage, and adjust each pixel individually based on said percentage. Red at 50% (0.5) is like Red -128. Red at 150% (1.5) would be like Red 128. To do the Gray value from Tone, you'd need to convert RGB to HSV and get the value to modify S(aturation), then convert back to RGB 255. If a value is pushed outside the bounds of the -255 to 255 range, you'd need to clamp them.
Yes, iterating a "for x/y" is slower than using a shader but it's OK for simple operations on sprites that aren't giant. It's too bad RMXP didn't provide a faster iterator for draw functions, or allow shaders, but it is what it is. I know overtly, Shaders aren't used in RMXP, but internally they most likely do use them when adjusting any/all Sprite properties. I can't imagine the Blend Mode, Hue, Angle and other properties would be as quick as they are if the program wasn't internally using Shaders to perform the operations, you'd have more lag than you do.
Again, I could be wrong. To be fair, I've never violated the EULA to find out, nor do I ever plan to, but I would like to find out more about how they did everything. I kind of get an idea of how things work when viewing similar functionality as RMXP but from non-RPG Maker game projects and open source code, which is how I come to these conclusions such as "RMXP internally uses Shaders". They probably don't use them for fill_rect or set_pixel; they'd be used for Transforms such as Angle, Hue, Zoom. Or Graphics.transition.
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.
(Correct me if I'm wrong^)
To do the math on the Tone, you could possibly normalize the values from 255 to a 1.0 based value, get the percentage, and adjust each pixel individually based on said percentage. Red at 50% (0.5) is like Red -128. Red at 150% (1.5) would be like Red 128. To do the Gray value from Tone, you'd need to convert RGB to HSV and get the value to modify S(aturation), then convert back to RGB 255. If a value is pushed outside the bounds of the -255 to 255 range, you'd need to clamp them.
Yes, iterating a "for x/y" is slower than using a shader but it's OK for simple operations on sprites that aren't giant. It's too bad RMXP didn't provide a faster iterator for draw functions, or allow shaders, but it is what it is. I know overtly, Shaders aren't used in RMXP, but internally they most likely do use them when adjusting any/all Sprite properties. I can't imagine the Blend Mode, Hue, Angle and other properties would be as quick as they are if the program wasn't internally using Shaders to perform the operations, you'd have more lag than you do.
Again, I could be wrong. To be fair, I've never violated the EULA to find out, nor do I ever plan to, but I would like to find out more about how they did everything. I kind of get an idea of how things work when viewing similar functionality as RMXP but from non-RPG Maker game projects and open source code, which is how I come to these conclusions such as "RMXP internally uses Shaders". They probably don't use them for fill_rect or set_pixel; they'd be used for Transforms such as Angle, Hue, Zoom. Or Graphics.transition.