New version! Pin2Dmd dmddevice.dll with DmdExt as plugin

[lucky1]

 

44 minutes ago, freezy said:

It's the right thing to do, technically, and morally.

 

If only all were that straight when it comes to righteousness and moral.

 

44 minutes ago, freezy said:

What I'll need is an API to do colorizations only.

 

44 minutes ago, freezy said:

Please, work me with me on that.

 

Please take my needs and the needs of the colorization authors into consideration. I think you have all the info. Will do when we have found a consent there and I have the time.

 

[freezy]

Is that a yes?

[lucky1]

1 minute ago, freezy said:

Is that a yes?

 

Just taking your needs into consideration is not a consent.

[freezy]

That's just a whole load of bullshit and you know it.

 

Looks like @hauntfreaks was right about you after all.

 

Cheers.

[lucky1]

57 minutes ago, freezy said:

That's just a whole load of bullshit and you know it.

 

Looks like @hauntfreaks was right about you after all.

 

Cheers.

 

So if others don´t share your opinion, you are getting insulting and shout out for others that share the same opinion like you to support you ?  And what should that be good for ? I think we are done here !

[Tikimaster]

12 hours ago, mellkul said:

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

Download the bspatch
 

 

12 hours ago, mellkul said:

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

You need:
bspatch
the original rom, which I downloaded from Stern, opend the zip and used the *.bin I found inside
the diff file from that package.
put the things in one directory, open a command window and go into that directory.
There you have to use a command like this:

bspatch SPD101VE.BIN smanve_101c_BySharkky.bin smanve_101c_BySharkky.diff

bspatch[SPACE]orinal-bin-filename[SPACE]nameofoutputfile[SPACE]diff-file-to-use
bspatch opens the patcher, first is input, second is output, third is name of the diff file to use to create
press Enter
Dos Windows does something..
if everything goes like it should, you´ll now find a new bin file. rename the new *.bin file to "smanve101c.bin" and put it in a zipfille named "smanve101c.zip", use this as new rom and put the *.pal file into VPinMAME/altcolor/smanve101c.
thats all.

Edited May 10, 2022 by Retsamikit

[mellkul]

50 minutes ago, Retsamikit said:

Download the bspatch
 

 

You need:
bspatch
the original rom, which I downloaded from Stern, opend the zip and used the *.bin I found inside
the diff file from that package.
put the things in one directory, open a command window and go into that directory.
There you have to use a command like this:

bspatch SPD101VE.BIN smanve_101c_BySharkky.bin smanve_101c_BySharkky.diff

bspatch[SPACE]orinal-bin-filename[SPACE]nameofoutputfile[SPACE]diff-file-to-use
bspatch opens the patcher, first is input, second is output, third is name of the file to create
press Enter
Dos Windows does something..
if everything goes like it should, you´ll now find a new bin file. rename the new *.bin file to "smanve101c.bin" and put it in a zipfille named "smanve101c.zip", use this as new rom and put the *.pal file into VPinMAME/altcolor/smanve101c.
thats all.

Perfect thank you very much 

[Funkyman]

Hey @lucky1, I'm a bit confused why you decided to do it this way? I understand your motives, and can sympathize..however, I feel like a better design choice would be to extract the coloring code into it's own lib and have both DMDExt and your DLL load that one.  It would make things a lot easier and I'd have no problem helping to get DMDExt working with it. I feel like the current design is leaving LOTS of users confused and not understanding how to go about getting this working. Thoughts?

[hauntfreaks]

4 hours ago, freezy said:

That's just a whole load of bullshit and you know it.

 

Looks like @hauntfreaks was right about you after all.

 

Cheers.

that dudes been a problem from day one.... typical greed

[lucky1]

23 minutes ago, hauntfreaks said:

that dudes been a problem from day one.... typical greed

 

If you call it greedy to collect the pin2dmd activation fee and forward it to 
children hospice service, children cancer centers, orphans home, Ukrainian refugees, support for multiple sclerosis patients etc - then yes I´m proud to be greedy and even more proud not to be liked by guys like you. 

[sudsy7]

38 minutes ago, Funkyman said:

I feel like the current design is leaving LOTS of users confused and not understanding how to go about getting this working.

Why do you think lots of users are confused about this?  Copying a few files into the pinmame directory is really not that difficult.  Installing VP for the first time - now that's confusing!!!

[mlager8]

Not meaning to invalidate anyones work, but just posing a question. Is there really that many problems with the existing color implementation? I seem to have most of the colorizations including the 64 versions working without issues. I'm usually inclined to go the "if it aint broke..." road but its seems all the colorization authors have jumped to the .pac format exclusively forcing an upgrade. I think @NetzZwerg even states all future releases will be .pac only, though now looking at TOM maybe that has been revised?

 

Is there a reason all authors have switched to the pac format with exclusivity?

 

Also is pac format open or proprietary?

[Funkyman]

27 minutes ago, sudsy7 said:

Why do you think lots of users are confused about this?  Copying a few files into the pinmame directory is really not that difficult.  Installing VP for the first time - now that's confusing!!!

I'm going by the 8-9 pages of comments, questions, etc on this thread!  

[zedrummer]

Hello

 

@lucky1I have just developped a new cheap real DMD device for vpins and I have questions about these "improvements":

- So if I understand everything, to make my device compatible with your new system, I just need to compile a new dmdext.exe including the code for my device from the @freezy code, use your dmddevice.exe, copy the dmddevice.ini as dmdext.ini and it should work?

 

- Reading this answer you made...:

 

8 hours ago, lucky1 said:

 

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.

 

...I worry a bit: in my code, what mainly degrades performance are the serial transfers and I thought that the advantage of using 4/16/64 paletted colors compared with RGB24 was to drastically reduce the buffer size to transfer.

So if everything is converted to RGB24 before being transfered, what is the point not to directly propose a pin2dmd editor in RGB24 that would permit even higher quality images? Specifically for the Pin2DMD device, do you convert to RGB24 and pass through dmdext too or do you send directly the "compressed" 2/4/6bits per pixel from dmddevice to your device?

 

Thanks

David

Edited May 10, 2022 by zedrummer

[lucky1]

9 minutes ago, Funkyman said:

I'm going by the 8-9 pages of comments, questions, etc on this thread!  

 

Like stated in the first post I expected some problems in the first release(s) and wanted to have them fixed quickly. So 90% of the previous pages refer to bugs in previous release which should be all fixed and not to installation issues. I consider the current release as stable since there have been only positive reports recently.

[lucky1]

19 minutes ago, zedrummer said:

what is the point not to directly propose a pin2dmd editor in RGB24

Memory on the device

19 minutes ago, zedrummer said:

Specifically for the Pin2DMD device, do you convert to RGB24 and pass through dmdext too

yes

[zedrummer]

15 minutes ago, lucky1 said:

Memory on the device

By device, you mean the memory on the MCU? If what is sent from dmddevice to dmdext and then from the dmdext to the device is RGB24, what does it change?

 

Could you tell me about my question on the way to make my device works with your new dmddevice mode, please?

Thanks

[NailBuster]

All drama aside, let’s focus on the community and discuss technically why I believe this new lucky-dmddevice.dll setup is the wrong approach/idea.

 

1>  You’re taking an open-source dmddevice.dll that is used by everyone in vpin-land and deciding to replace it with your closed-source lucky-dmddevice.dll with a custom-fork version of dmddevice.dll that has a different settings/file as dmdext.dll/dmdext.ini?    

 

Why this is bad:   So every wiki post/forum post/video made in the last 5 years is now WRONG when they say things like ‘open up dmddevice.ini and do this’….it’s now ‘dmdext.ini’?   Do you understand the vpin-landscape of thousands of users?  and throwing this change in there for no good reason?

 

2>  Closed source/sole person being the gatekeeper for coloring and now pup-frame feeding.  

 

Why this is bad:  So someone adds a patch to freezy/dmddevice.dll or a new feature.  It cannot be used unless those changes are applied to your FORK of this dmdext.dll ‘plugin’.  Also,  current dmddevice.dll is tested and proven to work with 100+ puppacks and now you’re going to mimic/write your own pup-frame feeder in your closed source dmddevice.dll.  If I wanted to add a pup-feature to dmddevice.dll, I no longer would just modify the open-source dll but now need to ask you to do it in your driver.

 

3>  general confusion now that dmdevice.dll is NOT what is expected.  For example,  everywhere when checking the freezy version you have… you no longer right-click/properties of dmddevice.dll to see if you need to update your freezy… you now need to check dmdext.dll.  Just seeing small examples like flexdmd-gui showing you your dmddevice.dll is incorrect will confuse many people (and rightly so).

 

Although expert-vpin users may think all these changes are ‘minor’….it’s easy to say if all you care about is getting your own system operational.  There’s a few ‘angel’ supporters out there helping hundreds/thousands of non-expert users… they’re trying to make things easier for everyone, not more complicated.

 

And finally,  with the open-source dev-team of dmdext willing to work with you and create a color-api to make it external and solve your main issues….why would you say no?  You would get very little questions/support with making your code an external plugin to the existing dmddevice.dll.  What you’re doing here is just asking for community to get more frustrated with all this...and its NOT required, you are choosing to add this complexity to the community where there's a better/less frustrating solution to it moving forward.

[Pinballerx]

Yeah, it's a bit complicated for a regular joe like myself. I can't for the life of me get a .pac file to work. I got the new hd dmd going but getting a .pac file running has left me baffled. I tried everything. Added the dll files, copied my ini data from one to the other etc etc but pacs wont work just the vni and pal files.

[BlackPredator72]

I'm not sure now if I should update to this new file system or just stick by the last "open source" version.

If I update will my pup-packs still work? Well I can just try it and restore my backup when I get into trouble.

Hopefully you guys come to an agreement to work together and keep it simple for the normal users.

[Pinballerx]

15 minutes ago, BlackPredator72 said:

I'm not sure now if I should update to this new file system or just stick by the last "open source" version.

If I update will my pup-packs still work? Well I can just try it and restore my backup when I get into trouble.

Hopefully you guys come to an agreement to work together and keep it simple for the normal users.

I finally got it to work and it was a bear. But i was also dealing with ghostbusters rom and that was a lot of my problem. Also medieval madness had multiple roms. Anyway its lovely now I got it working. my pup packs were not effected

[sraptor]

I installed it and work great, much better than the old one. Thank you Lucky1 to make this update work much better.

 

[timhobbs]

there is an awful lot of drama in vpin land and it doesn't really do anyone any good. egos should be checked at the door...

 

as a software developer i get the urge to make it work and do it fast, and no one appreciates hold ups that make them have to wait. but taking an open source codebase and plugging it in to a closed source one seems a bit sketchy. and i realize there is a reason for the "donations" for pin2dmd but i think if you looked at it as an outsider it could seem a little shady that you are basically hijacking open source code - it kinda makes it look like you may be doing it for your own bank account.

 

not to mention all the docs and videos and whatnot that are now no longer up to date. or the casual vpin owner that doesn't really feel super comfortable with all the "software stuff" and the confusion he/she will have about whether or not to change/update software, or even how.

 

getting things setup and running well in this hobby is hard enough without a 180 happening, even worse when it divides the community. i am a nobody but for the sake of the hobby please work with these guys, lucky, and just get this setup in a way that is not so disruptive - not just what works best for you, but for everyone.

 

we need less drama and more harmony

[Tikimaster]

I am also very unhappy with this situation. On the one hand I spend a lot of time helping others and these changes are an explanatory disaster, on the other hand I understand the motivation very well. I know one thing: if there is to be an API for all, it will only come through collaboration and talking and working together. Please, come together, guys.. It will be a desaster to loose even one of you.. In real life, when we realize we've turned down a one-way street, we back up a bit to the last intersection and decide on the better way to our destination. Please, dear developers, don't let it fail at the end because of something stupid like pride.
My humble opinion. - And lots of thanks for the great work of both of you.. 🙂

[Jibjabber]

13 hours ago, mlager8 said:

Not meaning to invalidate anyones work, but just posing a question. Is there really that many problems with the existing color implementation? I seem to have most of the colorizations including the 64 versions working without issues. I'm usually inclined to go the "if it aint broke..." road but its seems all the colorization authors have jumped to the .pac format exclusively forcing an upgrade. I think @NetzZwerg even states all future releases will be .pac only, though now looking at TOM maybe that has been revised?

 

Is there a reason all authors have switched to the pac format with exclusivity?

 

Also is pac format open or proprietary?

 

I'm hoping authors who have switched to exclusively pac will reconsider and release pal vni versions too so people have a choice at least