Beginning of a New Era

[Dazz]

On 3/17/2023 at 6:13 AM, freezy said:

So, trying to conclude here.

 

But first, I want to make something clear. RGB24 or not RGB24 has no impact whatsoever on real pins. Dmdext is a Windows software made for virtual pins, so whatever API or devices it supports has no effect on how real pin displays work. This means that even if Lucky1 fixes the RGB24 output in his plugin, PIN2DMD will still be the only display that works with PIN2DMD coloring on the real pin side.

 

That said, I have been talking to a few developers and they think that converting RGB24 should be doable, even in real time. So, my proposition is the following:

1. I port back Lucky1's plugin system from his fork into dmdext.
2. I convert the RGB24 output back into colored 4/6-bit frames that work with all displays.
3. I'll test and see how well that works. If there's a lag, you'll need a faster computer.
4. Lucky1 provides the PAC coloring DLL separately, where people can download it.

This would solve the problem of the hostile fork and the GPL violation. It also solves other problems the fork has, like laggy video mode on PinDMD3s with 4-bit coloring. It will also relieve Lucky1 of having to keep maintaining the fork.

 

So, it would be the solution with maximal benefits for everyone. It's still stupid to have to do the conversion when there's no technical reason for it, but I guess that's the ego tax.

 

@lucky1 let us know if you agree with the points above.

 

Also, if you're a coloring author, please like this post if you agree. And my message from the first post still stands. Serum got quite some traction meanwhile, and if you're fine with soon-to-be-released real pin Serum support, you should give it a try.

 

As a final note, personally, this is a compromise of what I already consider a compromise. I'm still not happy having DRM in my project, further pushing the monetization incentive. But I also recognize that for now, it's the best shot we have at a solution with everyone's best interests in mind.

 

This sounds extremely reasonable.

Freezy has my full support.

[marccy1138]

Didn’t mean to diminish the point of the extended conversations on the topic. 
 

 I do understand all the work everyone does and the thousands of hours of your free time spent on the code, etc.. Moreover, I understand the protection of what you create. 

 

The color roms are one of my favorite (and to many others) additions to tables. Just don’t want to see them go away or you guys stop inventing better and better stuff for us all! 

[Terranigma]

I don't want to get my hopes up in case someone accidentally leant on their keyboard, but I think I saw a glimmer of agreement just now. I feel like I haven't slept in days, so I really need this to not be a hallucination.  I'd also love a new diagram 😄

[lucky1]

On 3/17/2023 at 12:13 PM, freezy said:

So, trying to conclude here.

 

But first, I want to make something clear. RGB24 or not RGB24 has no impact whatsoever on real pins. Dmdext is a Windows software made for virtual pins, so whatever API or devices it supports has no effect on how real pin displays work. This means that even if Lucky1 fixes the RGB24 output in his plugin, PIN2DMD will still be the only display that works with PIN2DMD coloring on the real pin side.

 

That said, I have been talking to a few developers and they think that converting RGB24 should be doable, even in real time. So, my proposition is the following:

1. I port back Lucky1's plugin system from his fork into dmdext.
2. I convert the RGB24 output back into colored 4/6-bit frames that work with all displays.
3. I'll test and see how well that works. If there's a lag, you'll need a faster computer.
4. Lucky1 provides the PAC coloring DLL separately, where people can download it.

This would solve the problem of the hostile fork and the GPL violation. It also solves other problems the fork has, like laggy video mode on PinDMD3s with 4-bit coloring. It will also relieve Lucky1 of having to keep maintaining the fork.

 

So, it would be the solution with maximal benefits for everyone. It's still stupid to have to do the conversion when there's no technical reason for it, but I guess that's the ego tax.

 

@lucky1 let us know if you agree with the points above.

 

Also, if you're a coloring author, please like this post if you agree. And my message from the first post still stands. Serum got quite some traction meanwhile, and if you're fine with soon-to-be-released real pin Serum support, you should give it a try.

 

As a final note, personally, this is a compromise of what I already consider a compromise. I'm still not happy having DRM in my project, further pushing the monetization incentive. But I also recognize that for now, it's the best shot we have at a solution with everyone's best interests in mind.

 

Thanks freezy for your proposition. In general I totally agree with you and I sounds like something we should continue to discuss in detail. Especially point 1 leaves a lot of room for interpretation how this is technically done.

I sent you a message on github. Let´s continue there.

[lucky1]

5 hours ago, Terranigma said:

 I'd also love a new diagram 😄

 

@freezy I also think this would be helpful to understand the details of point 1

[freezy]

Cool! That was a long path!

 

I hope to be working on this soon, but I first I want to finish an VPE physics refactoring that I've started weeks ago and only recently got fully back into context after having forgotten half of what I did. 🙄

 

I think my approach for 1. is going to be to pick some of the changes from your branch. But I'd like to do it in a way that is decoupled from PAC, i.e. a user setting that points to the DLL. The VNI code should be kept in dmdext to provide backwards-compatibility to those who don't want to use the plugin. It should however be possible to override this behavior and also let the plugin handle VNI.