What's new
Pinball info

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Pin2dmd - colorisation issues on the horizon…

Paul

Staff member
Joined
Oct 5, 2012
Messages
11,544
Location
South Wales
Alias
Toibs
Taken from here : https://vpuniverse.com/forums/topic...d32E1n_Ozq631wA5W2bU29TQw6Hdk53q9MTkpWS_A9Q7c

As you might know, there have been disagreements lately between @lucky1 and myself about how to handle DMD coloring in the future. There are a few technical things I'd like to explain, but also a bit of history and how our opinions differ. I try to be as neutral as possible, everything described is to the best of my knowledge, and I try not to exclude anything of relevance.

I'm an open source enthusiast. Everything I develop in my free time, I publish on GitHub for others to use freely. There is only one thing I want in return: If you use my code in a project, your project must be open source as well. The goal is to promote free software (free as in "freedom", not "beer" ;)). For example, it avoids that a corporation grabs the software, improves and sells it, without publishing their improvements (they're allowed to sell it). All this is legally described in a license called the GPL. It's quite a common license, for example the Linux kernel uses it, but also smaller projects like the Kodi media center (the first open source project I contributed to).

Most of my pinball-related projects are GPL-licensed. Dmdext is GPL, VPE, even the source of vpdb.io is GPL and fully available on GitHub. Doing open source for backend-services has its risks, people find vulnerabilities quicker, but in my experience, people seek more often to create than to destroy (or "rip off"). Neither dmdext nor VPE would be what they are today were they closed source.

Lucky1 had a different experience. His first firmware for PIN2DMD was open source, and soon some guy came around, used his code and loaded it on another device he built and sold (and claimed credit for). This wasn't to be tolerated, and soon after, the PIN2DMD firmware became closed source. Not only that, while you were free to build your own PIN2DMD hardware, the firmware had to be purchased from Lucky1. So the firmware became commercial software and its revenue was donated to a charity of Lucky1's choice (and still is today).

To understand why that's relevant, let me explain dmdext's origins. After I built my cab, I decided to purchase a PinDMDv3 from VirtuaPin. Russ (the developer who was commissioned to create VirtuaPin's PinDMDs) had already written a driver for VPM, so it was plug and play. What Russ created was an API that would be used when loading DmdDevice.dll (if available), and output the frame data to the hardware device. Lucky1 also used this interface for the PIN2DMD.

But my DMD didn't work with all the other simulators (PinballFX, Pinball Arcade, and Pro Pinball). So I looked at how the PinDMD3 driver was done, and started screen grabbing the PinballFX DMD to be able to use my hardware DMD in those games. But because development takes time, and I didn't want to spend time coding on my cab, I implemented another output driver: The virtual DMD. I put some effort to make it render nicely (later on, @vbousquet improved this shader even more), since I was gonna be looking at it every day. This was the inception of dmdext.

Since PinDMDv2 devices were still out there, I also implemented an output driver for PinDMDv2, PinDMDv1, and later PIN2DMD. The architecture of dmdext was designed in a way that it was easy to add new input or output drivers: Implement a bunch of interfaces depending on the frame formats, add the config, done.

I largely ignored VPM/VPX, because there were already drivers for that. That was until Lucky1 approached me and introduced me to his colorization project. At that point, PIN2DMDs where already being used in real pins, and there was more demand in colorized games than available. So Lucky1's idea was in order to find more colorization authors, the project should be accessible to more people (LCD and PinDMD3 owners, in the virtual pinball community).

It was already established that real pin owners were paying for getting access to the colorization files. However, since that wouldn't be a realistic model for the virtual pinball community, colorizations would be free for v-pins (but for v-pins only). In order to prevent real pin owners from using the files from the virtual pin community, Lucky1 used a different format.

So the idea was that I would port the colorization code into dmdext in a way difficult to port back to C which is the programming language usually used for embedded devices (at that time, the coloring was done on the actual PIN2DMD device, through the firmware). And I did exactly that, commented the code in Swiss German so not even Google translate would output anything useful, and spent weeks long debugging, until we finally introduced DMD coloring in dmdext 1.7.

And the plan worked. DMD coloring took the community by storm, and out of thousands of new users, a handful of new coloring authors emerged.

With time, Lucky1 added new features, and those features were also ported back into dmdext, mainly by other contributors like @DJRobX and @Funkyman. It usually worked like that: A new feature dropped, and PIN2DMD users started testing it. Remember, there were two implementations: Lucky1's original, closed-source version, and the open source dmdext port. Once the feature was stable, Lucky1 would send me his changes to be ported back to dmdext, so LCD and PinDMD3 users could use it too.

The very inconvenient thing though was that there was a significant time gap between new features in PIN2DMD, and their port into dmdext. This was mainly because I was (and still am!) busy with VPE, but also because it's hard for me to get into the context. See, I don't follow every new coloring feature, and without some documentation, it's hard to know what changed, let alone debug problems.

But we always managed to keep up, until version 1.10 which introduced 64-color support (thanks to the efforts of Lucky1 and Funkyman).

Then, in March, we got a question from @zedrummer, who was working on a new, cheaper hardware DMD and wanted to integrate it with dmdext. I pointed him into the right direction, which soon ended up in a PR which is still open to this day, due to a few changes I wanted him to implement.

Shortly after, I got an email from Lucky1, titled "copycats", with a request to add a clause to the dmdext license that forbids anyone to use dmdext's coloring code for "other projects" without the approval of him and Steve (the author of the PIN2DMD editor).

At first I thought this might have something to do with the zedrummer's new DMD, but after inquiring what this was all about, Lucky1 pointed me to this threadwhere somebody got dmdext running on a real pin (for the record, that was when I first learned about that project).

See, once you publish code in a given license, you cannot retroactively change that license. The "deal" I had with Lucky1 was that it should be difficult for non-programmers to re-implement coloring, but the license was clear from the beginning. That sooner or later someone would come and port it back into another language to use in other projects has always been a risk.

In the email, Lucky1 mentioned that the problem of such a project was that the "donations [to the coloring authors] can be circumvented", and he announced that in the future, the VNI files would be encrypted so they couldn't publicly be decrypted anymore. He proposed to use a different DLL than dmdext's DmdDevice.dll for VPM and use dmdext's DLL for RGB24 output. It only dawned to me until later what that actually meant.

Around the same time, another thing happened: @Dazz got an email from an IP holder, where they inquire whether VPU is selling colorizations for real pins (they are not). Along with a note that redistributing their IP (in this case, the frame data of their games) would be illegal.

From my understanding, neither the VNI nor the PAL file were including any of the original frame data. The PAL just contains color palettes, and the VNI contains hashes and the coloring data that was added by the author. The only data that links back to the original frames are CRC32 checksums, which are not, by any definition, proprietary IP.

But be that as it may. One more reason to further restrict the coloring, Lucky1 spent two weeks implementing his DRM, which resulted in the new PAC format you probably know by now. There were two more problems to solve:

  1. The old VNI/PAL files had to disappear
  2. It had to be done quickly

The first point was more or less accomplished by asking all the coloring authors to update their files (i.e. remove the PAL/VNI and replace them by PAC). The second point was more difficult, because of dmdext's notoriously long periods of back porting code (although to be fair, Funkyman is still active and would have been a lot quicker compared how long it took for 64-color support).

So, why not get rid of dmdext entirely? But dmdext is still useful for the nice LCD rendering. So Lucky1's approach was to change the paradigm: Instead of dmdext's DmdDevice.dll, everybody should use his own DmdDevice.dll, which does the coloring and loads dmdext for the LCD output. It was only then when I started to understand the consequences, and the more I thought about it, the less I started to agree with it.

First of all, dmdext is GPL-licensed. It's actually illegalto ship a non-GPL binary together with GPL-licensed code. Lucky1 is doing exactly that.

The second problem that I have with this approach is that it's what's called a hostile fork. Lucky1 is actually instructing users to not use the original dmdext project anymore, but his own modified copy of it (his "fork"). He's creating a competing product, based on dmdext. This has a negative impact on the community:

  • Confusion. "freezy" is suddenly not freezy's anymore, but Lucky1's "freezy". Years of forum posts and videos become invalid. An enormous effort has to be done to rectify this.
  • Control. All new changes that go into dmdext will have to go back into Lucky1's fork, otherwise they won't be available for users using the fork. That makes Lucky1 the gate keeper for new features (for a project he didn't create).

The third problem is compatibility. Any new hardware support that goes into dmdext must be signed-off by Lucky1 before it gets the coloring feature. Imagine a newer, cheaper technology for a DMD, like zedrummer's project. That would be a benefit for the community, right? Well, coloring support would be at the mercy of Lucky1.

Finally, the fourth problem is that it's just bad software design. It doesn't separate concerns, resulting in a chain of programs that doesn't make logically any sense. Coloring cannot be used for anything but VPM. I'm working on VPE, and I can't use an API made for DMD hardware to implement coloring, because that would mess up everything.

Well, there are three solutions for these problems:

  1. Lucky1 publishes his coloring code as open source. This would make it legally compatible and give us a way to port it back into dmdext. It would also allow us to provide cross-platform support when VPE comes out.
  2. We change the license of dmdext to something less restrictive, for example MIT or BSD. That's pretty hard to do because the copyright of the dmdext code still applies to each individual contributor, and I cannot change the license without their consent. So I would need to contact them each individually.
  3. A compromise: we create an API that does coloring only (an API is like a contract of how different pieces of software communicate with each other). The API supports all the frame formats used today (not just RGB24). Dmdext implements that API. Lucky1 converts his code to match the API as well. Dmdext loads any library that implements the API at runtime, if available. But both programs need to be shipped separately, in order to respect the GPL.

Now, if you look at Lucky1's motives why solution one is unlikely to be happening, you'll see two patterns:

  1. He despises "copycats". It seems likely that the main purpose of the DRMed PAC format is to lock out any future hardware DMDs the community might come up with.
  2. He wants to "protect" the coloring authors. Or otherwise said, coloring authors still need to be able to sell the colorizations to real pin owners.

I think we can all sympathize with pattern one. It's always hard to see others profiting off your work. But I really don't think that DRM is the solution. It didn't work in any of the entertainment industries, and they have much larger budgets. It nearly always goes at the expense of the user. Another reason why I personally won't spend a second on DRMizing anything is that the task sucks, and I rather focus on the fun and innovative parts of my projects (if possible, of course).

About pattern two, I'm very skeptical. I talked to coloring authors, and I don't think the compensation is that important. None of us here get compensated, and we all pour a ridiculous amount of time into the hobby. We're doing just fine. If you're in for the money, you're better off investing in some NFT pyramid scheme or buying some crypto (now is a good time, I heard, haha!).

Additionally, DRM can and will be cracked. If you encrypt stuff, you need to decrypt it with a key. Unless you issue a personal key for every user, you need to store it in the binary you're shipping. That means it can be extracted. Providing individual keys doesn't solve key sharing. Unless you have some kernel-level **** going on, it's just impossible to protect.

Solution number two is also very unlikely. It boils down to changing the license of my project so others who don't even contribute to this project can make money. With all the consequences that come with it, like tensions between community members, VPU getting angry letters, more complexity for the user. That's something I'm opposed against, not in favor of.

I'm trying to pitch solution number three for a few days now. A couple of other software developers from the community like @NailBuster and Funkyman also chimed in why this is the solution to go, under the circumstances. Lucky1 announced that he won't work with me anymore because I called his arguments BS. And sadly, through intermediary communication with Funkyman, Lucky1 insists on shipping a single binary with both his proprietary code and dmdext, and wants me to change the license.

So I guess we'll part ways. I'll keep PAL/VNI support in dmdext for some time, but PAC colorizations will only be available for current devices. Dmdext will be used against my will. VPE will most likely not support colorizations at all.

All that is left for me to do is to appeal to the coloring authors to make a statement about their "donations" from real pins. Guys, if you're really in for the money, so be it. But if you're not, please speak out now, maybe there's a still chance for solution three.

Cheers,

-freezy.
 
Someone has got greedy and someone who is key to the project doesn’t like that.
 
So long and short is.

Freezy makes software based on open source for the community. Someone used his code to make a DMD. Lucky1 who makes Pin2DMD didn't like that.

Lucky1 threw his toys out of the pram, blamed Freezy, made his own 'fork' of Freezys software and DRM'd it

Now colourisation files are encrypted and if you want to use them you need to use Pin2DMD.

I'll just use ColourDMD.

No need to fund this lucky guys wallet IMO.
 
Money and the pinball emulation world do not mix
Years ago VP and some tables were licensed to a company , this tore the heart out of the community as some peoples tables were bought and others were ignored
 
Has this added to the availability of them or is that just because of the general economy with components etc?
 
Lately even some colour files on vpins do not work with the old files (on a monitor not pin2dmd).

I always thought it was cr@p that real pinballers have to pay for colour files and vpin users do not. I have a library of real pin colour files. Some free some paid for.

ColorDMD seems less hassle. But at least you know it works and no dramas.

At the moment its not an issue as you cant get pin2dmds for love or money!
 
Back
Top Bottom