New version! Pin2Dmd dmddevice.dll with DmdExt as plugin

[lukpcn]

@lucky1 I was thinking, maybe You and Freezy can make a one package out of Your and freezy's version ? It will lead to less confusions maybe ? Just I thought, maybe it is not possible at all.

[lucky1]

19 minutes ago, lukpcn said:

I was thinking, maybe You and Freezy can make a one package out of Your and freezy's version ? It will lead to less confusions maybe ? Just I thought, maybe it is not possible at all.

 

It is what this version is about. It brings the best of both together. Color code from my DLL and nice rendering from freezy.

[lucky1]

On 5/6/2022 at 3:04 PM, harrykoseck said:

However, the Pupack of the Baywatch table does not work anymore since the update. This is the only Puppack that has this problem.

 

Should be fixed in the version I just uploaded. 

[ashleyb]

On 5/2/2022 at 1:24 PM, lucky1 said:

 

 

Please test with the latest version. Should be fixed now.

 

One word about the colors though. My intention is to have the look of a virtual DMD as close as possible to a real pin2dmd that the colorization authors don´t have bother about any differences there when they create colorizations using the pin2dmd editor. So it may be that you experience that the picture of a previous version of freezy looks different to this DLL but when the previous version was off compared to a real pin2dmd I will keep it like it is now.

Works great now. Thanks.

[wryker]

What am I doing wrong. I read the original post and copied the files (5 of them) to VPinMAME and now all I get is the following:

[mellkul]

hey iv just updated to the new dll  still haven issues with the spiderman color 

[outhere]

58 minutes ago, wryker said:

What am I doing wrong. I read the original post and copied the files (5 of them) to VPinMAME and now all I get is the following:

If you are using a real dmd make sure you turn it on in the INI file

[lukpcn]

1 hour ago, lucky1 said:

 

It is what this version is about. It brings the best of both together. Color code from my DLL and nice rendering from freezy.

 

Yeah I know, but when freezy will release next version he won't have Your changes in his dmddevice.dll and pac files won't be supported again, and again will have to get Your dmddevice.dll and overwrite.... or am i wrong ?

[lucky1]

16 minutes ago, lukpcn said:

 

Yeah I know, but when freezy will release next version he won't have Your changes in his dmddevice.dll and pac files won't be supported again, and again will have to get Your dmddevice.dll and overwrite.... or am i wrong ?

 

Since freezy is a plugin for my dmddevice.dll I only need to use the latest freezy code to compile a new dmdext.dll to instantly make the new features available.  So it will be much quicker than the last time where users had to wait a very long time for the 64color support.

[Tikimaster]

Tested the Version from Today with Spiderman.
Color DMD is working. I use a patched color rom from here:

Edited May 9, 2022 by Retsamikit

[wryker]

1 hour ago, outhere said:

If you are using a real dmd make sure you turn it on in the INI file

I have an LCD DMD so will this work w/that? I thought it did?

[outhere]

1 hour ago, wryker said:

I have an LCD DMD so will this work w/that? I thought it did?

Yes

[freezy]

Hi @lucky1

 

After sleeping on it a few nights and getting feedback from other members of the community, I officially disapprove of your "new idea". There are a few problems with it, so let me elaborate.

1. We've already discussed this, but it stands that shipping my code with your proprietary binary violates the GPL. The fact that other packages do it too doesn't legitimize it, and it doesn't matter whether your software works without my code or not.
2. There are about 10k installations of dmdext. What you're about to get are 10k support queries from confused people. What you're doing is taking control over a flow that was previously managed by dmdext. Suddenly your DLL will be the controlling entity, but only for the use cases you care about (coloring). So some of the users will use the established flow documented in countless threads and tutorial videos, but if you want bleeding-edge coloring, you gotta swap everything. That's a really bad user experience. That's also the main reason for my reaction.
3. But I am also... slightly annoyed that you didn't consult with me about this first. It seems that your main trigger was that dmdext couldn't keep up with your changes and thus it was just easier for you to ignore dmdext completely and use it only for rendering. But there are other approaches to solve this, like I already proposed in private. You could develop a module that does the coloring and have it loaded by dmdext. This would be the proper solution and a lot less confusing for everybody. It would also allow keeping the dmdext configuration in a single file, and not violate the GPL.

I strongly urge you to reconsider your approach. If you do, I will help you with the API and getting releases out fast. But this way is just, as someone wise said to me... opening the Pandora's box.

 

Cheers.

 

   -freezy.

 

[wryker]

1 hour ago, outhere said:

Yes

Then I can't figure out what I'm doing wrong. Dang it.

[lucky1]

1 hour ago, freezy said:

We've already discussed this, but it stands that shipping my code with your proprietary binary violates the GPL. The fact that other packages do it too doesn't legitimize it, and it doesn't matter whether your software works without my code or not.

 

I still think it does not violate the GPL since I only pass data to the DLL just like pinMame does but since @freezy requested it I removed the DmdExt.dll and put it into a separate zip in the first post of this thread. The source of this DLL can be found here https://github.com/lucky01/dmd-extensions/tree/dmdext.dll

 

[freezy]

That's not what I requested.

 

Look, I don't have the energy or time to try to convince you that your whole approach is wrong. If you don't see that for yourself, then continue, but please be aware that you're not doing any favors to the community, specially not to those who take their time to give support to others.

[lucky1]

12 minutes ago, freezy said:

That's not what I requested.

 

Look, I don't have the energy or time to try to convince you that your whole approach is wrong. If you don't see that for yourself, then continue, but please be aware that you're not doing any favors to the community, specially not to those who take their time to give support to others.

 

I think this discussion is getting academic. I don´t see the difference between your code as plugin for my code or my code beeing a plugin for your code. IMHO for the user the only thing that counts is that it works the way it should and that they don´t have to wait for updates that long.  Do you know how many messages I received asking when is 64 colors supported by freezy not to mention that I did most of the debugging to make it work somehow ? From my point of view it is a choice between two pandoras boxes and I chose the one that is easier and quicker for me.

 

[lucky1]

5 hours ago, wryker said:

What am I doing wrong. I read the original post and copied the files (5 of them) to VPinMAME and now all I get is the following:

 

You message says that pinmame can´t find the contents of the zip file in the same folder the vpinmame.dll is in.

[wryker]

1 hour ago, lucky1 said:

 

You message says that pinmame can´t find the contents of the zip file in the same folder the vpinmame.dll is in.

I thought I followed the instructions. D/L the zip file. Copy the 5 files to the VPinMAME folder. Copy & rename the copy of my dmddevice.ini to dmdext.ini

[mellkul]

10 hours ago, Retsamikit said:

Tested the Version from Today with Spiderman.
Color DMD is working. I use a patched color rom from here:

hey im not to sure how to use this rom patcher, any input would be great 

[lucky1]

6 hours ago, wryker said:

I thought I followed the instructions. D/L the zip file. Copy the 5 files to the VPinMAME folder. Copy & rename the copy of my dmddevice.ini to dmdext.ini

 

Do you use vpinmame or vpinmame64 ? If vpinmame64 you need to use the dmddevice64.dll and dmdext64.dll from the zips in the first post.

[lucky1]

1 hour ago, mellkul said:

hey im not to sure how to use this rom patcher, any input would be great 

 

[freezy]

@lucky1 You know, just throwing in arguments like the discussion is getting "academic", doesn't help anyone. I've given you hard arguments, and you're ignoring them. Nobody is doubting that people want it to "work". Nobody is doubting that it shouldn't happen in a timely manner. Nobody is doubting your help to make it "somehow work" in dmdext.

 

What I'm saying is that your design is problematic. Let me try to explain it again, if it's so difficult to understand.

 

The primary goal of dmddevice.dll is to output DMD data to a device. You get a stream of frames, and the DLL can either output it to a hardware device (the original goeal), or render it nicely on the monitor. Its concern is outputting.

 

At some point, the coloring came up. Now we have two concerns: Outputting and coloring. In your PIN2DMD design, you don't care about separation of concerns. It's all the same to you, since you only have one input and one output. But in dmdext, we have multiple inputs and multiple outputs. So the coloring component sits in the middle. Dmdext very much separates those different concerns, because it would be impossible to write a coloring routine for every single output device.

 

What you're doing now is forcing everybody to mix those concerns together. What this means is that if somebody wants to support coloring, also the output implementation that has nothing to do with coloring needs to go through your dmddevice.dll.

 

That also means that there will be no way to make for example VPE work with coloring. Because VPE will very well separate those concerns and not use an output API in order to do coloring.

 

Then, there's a final point: By forking my repo and redistributing it as a wrapper for your API, you're effectively gate keeping dmdext. That means if someone wants to add support for a new hardware device to dmdext, they are dependent on you pulling in the changes. Which you don't have any incentive at all, since you're only using dmdext for the LCD rendering. But maybe that's why you're so reluctant to collaborate with me on that. It gives you more control over dmdext.

 

To summarize, the drawbacks of your design are:

 

• You'll be effectively gate keeping dmdext
• You'll be preventing other hosts like VPE to make use of coloring
• You'll confuse a whole lot of people, resulting in other people needing to help them

And finally, and that's my personal opinion, it's a slap into the face for all the people who worked on dmdext, specially @Funkyman. You could have done this before he spent months fixing coloring in dmdext. Now we'll have to remove all the coloring code from dmdext, vaporizing hundreds of hours of work.

 

The only argument from your side I heard is that's "easier and quicker" for you. Could I make the consequences and impact of this more clear to you?

[lucky1]

3 hours ago, freezy said:

Which you don't have any incentive at all, since you're only using dmdext for the LCD rendering.

 

What are you talking about ? I use dmdext as output for pin2dmd, LCD, pindmdV3, pixelcade etc. Like I said I simply pass the colorized RGB24 data to dmdext and it outputs to every device it supports, except PUP which is connected to my dll because it needs the uncolored frames for triggering.

 

3 hours ago, freezy said:

You'll be preventing other hosts like VPE to make use of coloring

 

I thought VPE replaces VPX but still uses PinMame for ROM Emulation, so as far as I can see there should be no problem and if there is one I´m here to fix it.

 

3 hours ago, freezy said:

That means if someone wants to add support for a new hardware device to dmdext, they are dependent on you pulling in the changes.

 

That should be no problem as long as the new device agrees with the license we published our code under.

 

3 hours ago, freezy said:

You could have done this before he spent months fixing coloring in dmdext.

 

Don´t forget Funkyman and I worked together on this and split the work. Funkyman took care of the ability to use 64 colors (6 planes rendering) and implemented the scaling while I was working on updating and debugging the coloring code itself. So a good part of the wasted time is my personal time. I wish I would have saved that time,  but it is like it is.

Now with the introduction of the .pac format I had the choice to add it to two codebases again with the possibility of having to look for someone who has time to help me or just add it to my codebase and use dmdExt just for output and never have to be involved in maintaining a second codebase. The decision was easy.

[freezy]

1 hour ago, lucky1 said:

I thought VPE replaces VPX but still uses PinMame for ROM Emulation, so as far as I can see there should be no problem and if there is one I´m here to fix it.

 

DmdDevice.dll is used by Visual PinMAME. VPE uses a different, cross-platform API called libpinmame. What I'll need is an API to do colorizations only. The same API that we could use in my proposition of dmdext loading the coloring module from you.

 

Please, work me with me on that. It's the right thing to do, technically, and morally.