Maniacs Patch - SetPicturePixel Command + GetPictureInfo Update

[jetrotal]

Another one that must come in pairs:

SetPicturePixel Command

Implements the CommandManiacSetPicturePixel function to allow direct pixel manipulation of game pictures via event commands. Handles bitmap uniqueness, format conversion, and window picture detachment to ensure safe editing. Updates command dispatch logic and header declaration.

---

Update - GetPictureInfo (pixel data extraction)

Adds support for extracting raw pixel data from pictures, including window-type pictures with forced refresh. Optimizes out-of-bounds handling to preserve variable values and ensures only 32-bit bitmaps are processed. Existing logic for info types 0, 1, and 2 remains unchanged.

---

TODO:

• Save persistence
• Few Quirks that I could not figure out, e.g.:
  I assumed some opacity changes between maniacs and easyRPG were due to out of bounds color picking. But I was wrong, someone smarter than me could help me with that.

Map0003.zip

[jetrotal]

Also supporting game Info pixels, test map:
Map0003.zip

[Ghabry]

Imo that's a good base but (while testing) I will try to optimize this for max performance.

I read discussions in various RPG Maker chatrooms about the performance of these pixel operations in Maniacs so lets make this fast.

---

You cannot know this but the function uint32_to_rgba performs surprisingly bad (during benchmarking) and I don't really know why as in the end it does the same as a bit shift (I have an improved version locally and it still runs worse for reasons unknown)

Should be faster to convert the entire relevant picture area in one go via Pixman to the format the Var Array wants and then memcpy it from/to the Variable array. But will also have to bench this :).

[Ghabry]

There is one edge-case I probably cannot fix: Reading from transparent pixel.

E.g. Actor1 has a green background which becomes transparent.

When reading now such a transparent pixel:

• Maniac: The value read is this green color
• EasyRPG: The value is (0,0,0,0) because we use premultiplied alpha

Premultiplied alpha is pretty standard when doing graphic processing so most libraries use it (including pixman).

[Ghabry]

rebased this on #3498 because some code is shared.

Okay this feature is actually pretty cool :)

@jetrotal once the build is finished could you test this a bit? (or better ask around if anybody knows games that use all this pixel reading/writing stuff so we can find bugs in the implementation).

[Ghabry]

To the surprise of noone there was no feedback from the community or the examples were such a brainfck that they needed 10 other features we dont support yet.

So the only two options we have are:

• Keep this in limbo forever
• yolo merge and then wait for people complaining in a few days because they found a bug in the feature

[Mimigris]

To the surprise of noone there was no feedback from the community or the examples were such a brainfck that they needed 10 other features we dont support yet.

So the only two options we have are:

* Keep this in limbo forever

* yolo merge and then wait for people complaining in a few days because they found a bug in the feature

I could try to find time during the week to test the commands if needed, once I'm done working on some other stuffs.

Is the SetPicturePixel command the one called Edit Picture(Tile) in the editor, or is it another? As I'm not entirely up to date with the recent Maniac versions, that the vocabulary is sometimes not consistent and that some commands are locked behind TPC which forces looking for documentation, I'm not really familiar with that.

---

About lacking feedback from the community on such pull requests, I think there are several things:

• More specific to this case, but due to being a Maniac patch feature, it can be hard to even understand how the command can be set and can be used (see my previous comment as an example).
• Just opening a pull request for a feature on GitHub does not attract a lot of people, as the only people that will become aware of this pull request are 1) people on Matrix or Discord, active or not, when backreading or reading messages, 2) people on IRC, if they are currently active when the pull request is created or updated, 3) people randomly browsing the pull requests of the GitHub, and 4) people that are subscribed to changes made to the EasyRPG Player repo. All of these options are limited, as only active people in the community will find it, and if there was a request for testers that was listed inside the pull request, it goes unseen unless you manually open the page.
• The fact you can test the pull requests is hard to see for a random user not familiar with GitHub, as you need to click on the "All checks have passed" button to reveal a list of platforms that the pull request was built for, and it is the only indication of that. This excludes de facto everyone not familiar enough with GitHub and with how the EasyRPG Player repository builds its versions for that.
• Lastly, even if a pull request is opened and is ready, it can be hard to really know if it is in a ready for testers state: there are a lot of different pull requests on the repository these days, all opened not set to WIP, some still requiring reviews for the idea if valid and some not, some made by AI that are sometimes held by glue meaning you do not even know if it is a pull request that will survive the basic review phase, making it harder for someone that wants to test to know if it is worth the effort or not.

If I had suggestions on what could be done to improve that, I think calls for testers could potentially be done:

• In the EasyRPG chat, when a feature is ready for testing; perhaps having a "wanted board" channel to list that users could be wanted for testing selected pull requests or features
• In nearby related Discord servers, such as the easyrpg channel of the RPG Maker 2003 Discord server or in the Maniac patch server (for the latter, if it is for a Maniac patch feature and that they see no issue with doing that over there)
• On our social networks (Bluesky, Fediverse, Twitter); as this last option aims at a broader audience, though, it may be more limited in scope (e.g. lot of Android users which may only be able to use the Player but not the editor), so it may only be doable for global changes that are more accessible for random users (doing tests this way would also require telling players where feedback can be given)

Perhaps having a tag for pull requests looking for testers could also be a thing, if it can help.