Skip to content

replace coloring code with coloring plugin - #347

Closed
lucky01 wants to merge 161 commits into
freezy:masterfrom
lucky01:coloring_plugin
Closed

replace coloring code with coloring plugin#347
lucky01 wants to merge 161 commits into
freezy:masterfrom
lucky01:coloring_plugin

Conversation

@lucky01

@lucky01 lucky01 commented Nov 24, 2022

Copy link
Copy Markdown
Contributor

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.

@freezy

freezy commented May 13, 2023

Copy link
Copy Markdown
Owner

Only if frame.width and frame.height matches the size of the frame data, which is not the case if HDScaling is active.

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:

image

Would that make sense?

@lucky01

lucky01 commented May 14, 2023

Copy link
Copy Markdown
Contributor Author

Either there are a lot of paths missing or wrong in your graph or I just don´t get it.
Anyway, scaling IS done after colorization already and the width/height parameters are just taken to indicate that scaling is needed. I´m ok how it is but if you consider this as a bug, feel free to change it.

Comment on lines +45 to +52
public enum ColorizerMode
{
None = -1,
SimplePalette = 0,
Advanced128x32 = 1,
Advanced192x64 = 3,
Advanced256x64 = 4,
}

@freezy freezy May 29, 2023

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  • None means 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.
  • SimplePalette means 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.
  • Advanced128x32 means that all frames are colored and returned by the plugin, at 128x32.
  • Advanced192x64 also means that all frames come from the plugin, at 192x64.
  • Advanced256x64 same as above, but at 256x64.

@lucky01

lucky01 commented May 29, 2023 via email

Copy link
Copy Markdown
Contributor Author

@freezy

freezy commented May 29, 2023

Copy link
Copy Markdown
Owner

Right, so ACDC with only a .pal should return SimplePalette, right? (It returns None.)

@lucky01

lucky01 commented May 29, 2023 via email

Copy link
Copy Markdown
Contributor Author

@lucky01

lucky01 commented May 29, 2023 via email

Copy link
Copy Markdown
Contributor Author

@freezy

freezy commented May 29, 2023

Copy link
Copy Markdown
Owner

It is not a simple palette but multiple palettes with ROM based palette switching.

Yes, so how about a MultiPalette mode, where dmdext can query the plugin for the palette with GetCurrentPalette() (returning an array of colors)?

You need to make sure the console data is forwarded to the plugin

Yes, that's the case.

@lucky01

lucky01 commented May 30, 2023

Copy link
Copy Markdown
Contributor Author

Yes, so how about a MultiPalette mode, where dmdext can query the plugin for the palette with GetCurrentPalette() (returning an array of colors)?

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)

@freezy

freezy commented May 30, 2023

Copy link
Copy Markdown
Owner

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?

@lucky01

lucky01 commented May 30, 2023

Copy link
Copy Markdown
Contributor Author

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.

@freezy

freezy commented May 30, 2023

Copy link
Copy Markdown
Owner

Cool, now how do I get the new palettes?

@lucky01

lucky01 commented May 30, 2023 via email

Copy link
Copy Markdown
Contributor Author

@freezy

freezy commented May 30, 2023

Copy link
Copy Markdown
Owner

That sucks. What you're proposing is:

  • Your DLL converts a gray4-frame to RGB24 based on the current palette (expensive)
  • dmdext extracts the palette from the RGB24 frame (expensive)
  • dmdext creates a new colored frame with original frame data and the extracted palette (cheap)

Instead of:

  • Your DLL just returns the palette (cheap)
  • dmdext adds the palette to the frame (cheap)

@lucky01

lucky01 commented May 30, 2023 via email

Copy link
Copy Markdown
Contributor Author

@freezy

freezy commented May 30, 2023

Copy link
Copy Markdown
Owner

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.

@lucky01

lucky01 commented May 30, 2023 via email

Copy link
Copy Markdown
Contributor Author

@freezy

freezy commented May 30, 2023

Copy link
Copy Markdown
Owner

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?

@lucky01

lucky01 commented May 30, 2023

Copy link
Copy Markdown
Contributor Author

Intensive tests of my plugin solution have been made by the community and no drawback of any kind has been reported.
It seems all users of my plugin solution are happy.
The only thing I can agree with you is that we disagree on every point we discuss, Makes no sense to start the discussion again.

@freezy

freezy commented May 30, 2023

Copy link
Copy Markdown
Owner

Intensive tests of my plugin solution have been made by the community

But you've just changed the entire API. Nobody has ever tested what we're discussing here. This argument is nonsense.

The only thing I can agree with you is that we disagree on every point we discuss, Makes no sense to start the discussion again.

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.

@lucky01

lucky01 commented May 30, 2023

Copy link
Copy Markdown
Contributor Author

But you've just changed the entire API. Nobody has ever tested what we're discussing here. This argument is nonsense.

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.

@freezy

freezy commented May 31, 2023

Copy link
Copy Markdown
Owner

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:

 [1] 2023/05/31 22:27:39.110  INFO | [Pin2Color] Successfully loaded colorizer plugin ... 
 [1] 2023/05/31 22:27:39.155  INFO | [Pin2Color] Failed to open colorizer ... 

Which makes sense, since yourself said:

I sent you a dll version for testing. I refactored the coloring plugin interface to use the BSD-3 licensed dmddevice.dll api.

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?

Comment on lines +490 to +499
private static void processEvent()
{
if (_activePinUpOutput != null) {
uint eventID = ColorizeGetEvent();
if (eventID != lastEventID) {
lastEventID = eventID;
_activePinUpOutput.SendTriggerID((ushort)eventID);
}
}
}

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@freezy freezy closed this in #374 Aug 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants