replace coloring code with coloring plugin - #347
Conversation
Yeah, I debugged into it, and indeed if HD scale is set, the frame size doesn't correspond to the data. I would consider this as a bug, and the scaling should be done after the colorization, if the colorizer doesn't already upscale it. Something like this: Would that make sense? |
|
Either there are a lot of paths missing or wrong in your graph or I just don´t get it. |
| public enum ColorizerMode | ||
| { | ||
| None = -1, | ||
| SimplePalette = 0, | ||
| Advanced128x32 = 1, | ||
| Advanced192x64 = 3, | ||
| Advanced256x64 = 4, | ||
| } |
There was a problem hiding this comment.
I'm testing SAM games (ACDC), and I can't get it to work. I'm posting this here and not on my PR, since it doesn't seem to work here, either. I think the problem is that there is no way of retrieving the palette changes from the plugin.
About the code above: Could you confirm (or correct me) that:
Nonemeans that no colorization files were found, thus nothing will be colored. There will be a way to forward frames to the plugin nevertheless (for frame dumping), but nothing is expected in return, i.e. the frame will be routed from the original source to the destinations, and not from the converter.SimplePalettemeans that we'll only get palette changes from the plugin, for example for ACDC with a patched ROM. Here, we would retrieve the new palette from the plugin and re-emit the original frame with that palette.Advanced128x32means that all frames are colored and returned by the plugin, at 128x32.Advanced192x64also means that all frames come from the plugin, at 192x64.Advanced256x64same as above, but at 256x64.
|
Simple Palette means a pal is found but no pac/vni/fsq for advanced coloring. It also returns the colorized frame in the same resolution as the source.
|
|
Right, so ACDC with only a .pal should return |
|
It is not a simple palette but multiple palettes with ROM based palette switching. I don't remember what it reports back but I think it should be simple palette.
|
|
You need to make sure the console data is forwarded to the plugin
|
Yes, so how about a
Yes, that's the case. |
I think that is not worth the time since there are only a hand full of smartdmd tables which will be converted anyway (e.g. Metallica) |
I don't understand.. There are already colored games, how do you want to support them otherwise? |
I updated your testing DLL in dropbox. It was reporting the wrong colorization type. |
|
Cool, now how do I get the new palettes? |
|
You get the colored RGB24Am 30.05.2023 um 11:49 schrieb freezy ***@***.***>:
Cool, now how do I get the new palettes?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
That sucks. What you're proposing is:
Instead of:
|
|
That is what we agreed on . My plugin returns colorized RGB24 frames. Am 30.05.2023 um 12:46 schrieb freezy ***@***.***>:
That sucks. What you're proposing is:
Your DLL converts a gray4-frame to RGB24 based on the current palette
dmdext extracts the palette from the RGB24 frame
dmdext creates a new colored frame with original frame data and the extracted palette
Instead of:
Your DLL just returns the palette
dmdext adds the palette to the frame
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Well, technically we agreed on not sending colored grayX-frames for pin2color-generated frames. Here, the palette changes are triggered by the ROM. I'm trying to understand your motivation for such a shitty solution, because I can't see any benefits for anyone. |
|
Technically those ARE colored gray X (4) frames generated by the pin2color plugin and therefore returned as RGB24.All colored frames returned by the plugin are RGB24 . That is the consent we have and that is how it is implemented in my pull request.Am 30.05.2023 um 14:46 schrieb freezy ***@***.***>:
Well, technically we agreed on not sending colored grayX-frames for pin2color-generated frames. Here, the palette changes are triggered by the ROM.
I'm trying to understand your motivation for such a shitty solution, because I can't see any benefits for anyone.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Apart from whatever you think the "consent" is, would you agree that it's a bad solution with no benefits for anybody involved? And if so, would you help improving the solution? And it not, could you elaborate the benefits you see? |
|
Intensive tests of my plugin solution have been made by the community and no drawback of any kind has been reported. |
But you've just changed the entire API. Nobody has ever tested what we're discussing here. This argument is nonsense.
Collaborator of the year ;) Look, I'm not particularly enjoying this either. But I'm trying to put my feelings away so we can find a good solution. A good solution would be to retrieve the palette, so we can simply apply it to the frame and be done with it, instead of looping through the byte array multiple times. |
Since may the 3rd the version which is for download on VPU and intensively tested is based on the latest code on my fork and IS using exactly the same API like you. |
That's what happens when using this PR with the pin2color.dll from VPU: Which makes sense, since yourself said:
So, it's a different API, which is fine, it's just not the one the community tested. Anyway, I'll be soon releasing a beta version to test, so more people can check for regressions. The pin2color.dll testing will be done when you're back from holidays, I guess. About alphanumeric colorizations: Is there anything I could test with? Do you have one yourself that you could test? |
| private static void processEvent() | ||
| { | ||
| if (_activePinUpOutput != null) { | ||
| uint eventID = ColorizeGetEvent(); | ||
| if (eventID != lastEventID) { | ||
| lastEventID = eventID; | ||
| _activePinUpOutput.SendTriggerID((ushort)eventID); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
AFAIK this is for an unreleased PinUp feature that was added to Serum recently. Did you just copy it blindly, or is there a way I can test this?

Hi Freezy,
as recommended from you here is the pull request with the code changes necessary to make the pin2dmd coloring plugin with pac support work. Also some fixes for pindmdV3 and alphanumeric devices integrated.