New release: v2.2.0 BETA2

[freezy]

No, from the gate keeper aka lucky1. I have no idea who is involved in the private testing. I know since today that you seem to be one of them.

[Cliffy]

17 minutes ago, freezy said:

No, from the gate keeper aka lucky1. I have no idea who is involved in the private testing. I know since today that you seem to be one of them.

Ah. Ok well I'm not exclusive. Happy to help anyone since this is for everyone's benefit. Appreciate and admire all you do, freezy.

[freezy]

I've disabled de-duplication for Pinup. Updated builds in the first post. @Cliffy please let me know if that fixes it.

 

@NailBuster If you wanna have a look why it only triggers on the second frame, let me know, I can easily re-enable de-duplication.

[Cliffy]

1 hour ago, freezy said:

I've disabled de-duplication for Pinup. Updated builds in the first post. @Cliffy please let me know if that fixes it.

 

@NailBuster If you wanna have a look why it only triggers on the second frame, let me know, I can easily re-enable de-duplication.

Adadms Family tested with your new 32 bit dll on pal/vin. Pups trigger perfectly. Thanks!

Will go though my massive test list and see how they work. Good job finding the culprit

 

Baywatch pup pack doesn't trigger at all, not even on ball lost, with 32 or 64 bit. 

Batman Forever pup pack doesn't trigger at all, not even on ball lost, with 32 or 64 bit. 

Terminator 2 pup pack triggers perfectly 32 and 64 bit

Demolition Man pups trigger good

Batman Data East pups trigger good

Last Action Hero- can only run 64 bit. Pups trigger ok but not great (lag, doesn't catch them all) and if you start another game when first game ends the pup pack will not restart.

Guns n' Roses DE- no pup triggers at all

 

[freezy]

Thanks, but I'll need table links and pup pack links to those that don't work, otherwise I cannot reproduce.

 

I'll also need indication what's supposed to happen. I don't know any of those packs (I have never used pup packs), so I have no clue what to look for. If you say "Baywatch doesn't trigger at all", please specify what you expect versus what's happening, and when.

[Cliffy]

Ok I'm glad you're willing to verify these tests yourself. 

When I say doesn't trigger at all that means, in the case of the 192x64 display games- bats forever and baywatch, the pup pack needs to do more than simply loop and attract video over and over.  Since you're new to pup packs lets use the Addams Family that you tested yesterday. Imagine if the only thing that happened during game play was the movie trailer constantly repeating. That's what's happening with Baywatch and batman forever. We would expect a trigger for a new video clip or a callout upon hitting the skill shot, for example and always- always a ball lost call out and new video clip when the ball drains out.  Now, without diving too deeply here MOST ball lost triggers are via a switch and not a pup capture but in the case of Baywatch *ALL* triggers are pup capture. Here's a pic of the triggers for Baywatch. All are marked as "D" which means pup capture. Switches on the table are "W" triggers. For your purposes we need all the "D" triggers to actually trigger.

 

Will gather up links as requested- thanks again

[freezy]

@Cliffy Before you spend too much time on this, wait until I fix how the frames are scaled before sending to pup, there is a bug there @NailBuster just noticed.

[freezy]

@Cliffy I think I've fixed it. Downloads in the first post. I've attached the files to the post, since AppVeyor has, uh, quota issues.

[Cliffy]

41 minutes ago, freezy said:

@Cliffy I think I've fixed it. Downloads in the first post. I've attached the files to the post, since AppVeyor has, uh, quota issues.

YYYYESSSS! 

Baywatch and batman forever pup packs both trigger perfectly with 32 and 64 bit dll's. Great job! 

Of course I need to test others as well but this is a great sign that you're on the right track. Thanks Freezy and @NailBuster

 

I'll get back to you on further tests

[Cliffy]

so far everything I've tested with your 32 and 64 bit dll's has triggered the pup packs. 

All the data east 128x16, sega 192x164, all pal/vni games with pup packs test perfectly. 

Serum .cRZ work great- even the new @ebor Diner .cRZ looks great with your 32 and 64 bit dll's.

Even games with only .pac or pal/fsq trigger correctly although, of course, the colors are all wrong on the dmd.

IMO you've nailed it. Now time for you and @lucky1 to get the plugin's hammered out

[lucky1]

@freezy Any attempt to fix the need for duplicate frames on the pup side or is this your finale solution ?

Here is a compile of my plugin corresponding to the current freezy DLLs in the first post

 

 

 

 

[freezy]

@lucky1 I've talked to @NailBuster and I might add a configurable toggle to de-dupe the pup output. Or, if he can identify the bug, I can also easily switch to de-duping per default in a next release. Otherwise, this should be good to go.

 

I've tested the binaries above and I'm getting "Failed to open colorizer plugin Pin2Color v4.52.220" with both VNI and PAC colorizations. So, _open() returns false. Not sure how to debug this on my side. I've tested with i500_11r (PAL/VNI) and tomy_500 (PAC) on both 32 and 64 bit.

[lucky1]

What do you mean with above ? From the first post ?

 

I tested with the virtual dmd and my dmddevice.ini and it worked fine

[freezy]

I mean that placing pin2color.dll and pin2color64.dll into the VPM folder and referencing them in dmdevice.ini, with dmddevice.dll in the first post of this thread, fails.

 

Maybe you've posted the old ones from the fork?

[freezy]

Correction, with the DLL from the first post, it works, with a new build, it doesn't. You don't happen to do any checks which binary is calling the plugin?

[Cliffy]

Good morning  gentlemen. Nice to see progress overnight! 

So I've grabbed @lucky1 pin2color dll's and kept the dmddevice dll's that @freezy posted yesterday. Was thrilled with all the successful pal/vni testing I did yesterday and equally excited to tell you my first test with .pac went flawlessly.  My favorite .pac with pup for testing is AFM. It one of those you will immediately know if it's going to work or not and by golly she worked great.

vpx 10.7.4 rev 414 x86 32 bit DX, vpinmame 3.6 -sc rev 483

Attack From Mars LE v4.vpx (jpsalas) 

.pac color good, pup pack triggers good.

dmddevice.log and puplog attached.

Will obviously run through the same tests I performed yesterday. On top of that I'll try some pal/fsq. 

Thank you both and of course @NailBuster for getting us this far. Exciting!

 

 

DmdDevice.log PUPLOG.txt

[freezy]

Good to hear! Can you grab the latest dmddevice.dll I've posted and check if that works, too? I only added a new build setting, the code is identical.

[Cliffy]

47 minutes ago, freezy said:

Good to hear! Can you grab the latest dmddevice.dll I've posted and check if that works, too? I only added a new build setting, the code is identical.

Ohhhhh c'mon now. Don't fix what ain't broke!  Ok will grab them. First post I presume?

 

Another test just now. pal/fsq for Flintstones color perfect, pup pack triggers perfectly.  32 and 64 bit good.

 

UPDATE. Now with your newest dmddevice and dmddevice64 dlls the same Flintstones pal/fsq colors all wrong. I have to go back to yesterdays dll's. sorry. @lucky1 pin2color dlls are again out of synch with your newest dll's. 

[freezy]

OK, so it's not just me. Lucky1, what the heck?

[lucky1]

Here is my plugin dll with your tested build from yesterday. Then I will wait for the release version until I compile a new plugin dll. To prevent my colorization code or any colorization to be misused again, my plugin dll is bound to the binary, just like it was the case with my fork of your DLL.

 

 

 

 

DmdDevice.ini DmdDevice.dll pin2color.dll pin2color64.dll DmdDevice64.dll

[freezy]

No way

[Dazz]

7 hours ago, lucky1 said:

Here is my plugin dll with your tested build from yesterday. Then I will wait for the release version until I compile a new plugin dll. To prevent my colorization code or any colorization to be misused again, my plugin dll is bound to the binary, just like it was the case with my fork of your DLL.

 

 

 

 

DmdDevice.ini 11.69 kB · 16 downloads DmdDevice.dll 11.84 MB · 13 downloads pin2color.dll 127.5 kB · 13 downloads pin2color64.dll 101.5 kB · 13 downloads DmdDevice64.dll 12.33 MB · 14 downloads

 

@lucky1

What is your deal?  Why are you being the way that you have been with this?  The way that you are handling this is completely un-necessary and is becoming detrimental to the community. It's getting to the point where it's becoming un-tolerable.  This is going to screw more people than you think it's helping.  This is going to become a support nightmare... No wonder there is a push to other formats.

[tabascoman77]

10 hours ago, lucky1 said:

Here is my plugin dll with your tested build from yesterday. Then I will wait for the release version until I compile a new plugin dll. To prevent my colorization code or any colorization to be misused again, my plugin dll is bound to the binary, just like it was the case with my fork of your DLL.

 

 

 

 

DmdDevice.ini 11.69 kB · 16 downloads DmdDevice.dll 11.84 MB · 13 downloads pin2color.dll 127.5 kB · 13 downloads pin2color64.dll 101.5 kB · 13 downloads DmdDevice64.dll 12.33 MB · 14 downloads

 

Wow...you have GOT to be kidding me, dude.

[tabascoman77]

2 hours ago, Dazz said:

 

@lucky1

What is your deal?  Why are you being the way that you have been with this?  The way that you are handling this is completely un-necessary and is becoming detrimental to the community. It's getting to the point where it's becoming un-tolerable.  This is going to screw more people than you think it's helping.  This is going to become a support nightmare... No wonder there is a push to other formats.

 

He's been a grifter and a thief since day one...but this is a new low.

[lucky1]

6 hours ago, Dazz said:

This is going to become a support nightmare

 

Why ? In my opinion it makes support much easier than having to support all possible combinations of freezy versions combined with plugin versions. 

If Freezy releases the new version 2.2.0 there will be a plugin version 2.2.0 which is tested to be working with that version.

If he releases a version 2.3.0 there will be a plugin version 2.3.0

etc.

As easy as that.

 

P.S: With the serum.dll freezy makes sure that it has the matching version of the serum.dll by embedding it into his dll. That is not possible with the plugin because of his license restrictions.