Pin2Dmd Colorprism V4.0 Firmware

[lucky1]

A single Colomask frame stays until the next trigger takes over. Maybe that helps. For Replacement simply edit the delay of the last frame to stay longer

Generally you should avoid placing the load of a LCM scene into a transition because it needs to load the masks and hashes of the frames. 

[Pinballuser]

10 hours ago, lucky1 said:

I can add a cancel button, but why would you want to create a second keyframe if assign them both to the same scene and could trigger both scenes with one single keyframe ?

If you want to have them triggered individually choose the second hash.

 

I don't 

for this case the same color mask will work for both frames  , so I deleted one of the scenes.

if I was using the replacement mask  then I would need both. (using  a different hashs to trigger both scenes as you suggested)

 

The problem I saw is that

Like you  I was expecting to see the "keyframe already exists" pop up  when I  was (unknowingly) using the same hash for 2 different frames.   

 

edit

Out of curiosity but do 10-15 minute long DMD dumps eat up memory   when  you create or run the vni and pal file.

I had a 5+ minute long dump with about 20-30 usable frames

I opened the text file in note pad to remove many of the unused frames. was this just a waste of time in my part.

 

 

[sudsy7]

46 minutes ago, lucky1 said:

A single Colomask frame stays until the next trigger takes over. Maybe that helps. For Replacement simply edit the delay of the last frame to stay longer

Generally you should avoid placing the load of a LCM scene into a transition because it needs to load the masks and hashes of the frames. 

The "Super Cue" scene that is becoming  "uncolored" is a single Colormask frame - and it is staying, but it isn't staying colorized for some reason.

I'm not sure what you are saying about transition.  There really isn't a transition frame between the single colormask scene and the LCM for the pool balls, even though there does appear to be some artifact dots (in the upper two lines) from the LCM appearing in the uncolored colormask frame.   But that isn't a transition frame - not sure why that is happening.

[lucky1]

8 hours ago, Pinballuser said:

The problem I saw is that

Like you  I was expecting to see the "keyframe already exists" pop up  when I  was (unknowingly) using the same hash for 2 different frames.   

 

The update of a keyframe is only checked if a keyframe is selected. If no keyframe is selected you will get the dulicate message

8 hours ago, Pinballuser said:

Out of curiosity but do 10-15 minute long DMD dumps eat up memory   when  you create or run the vni and pal file.

 

No

7 hours ago, sudsy7 said:

there does appear to be some artifact dots

That seems to be a transition frame which comes from a change of the memory content on the capcom DMD controller which is not fully finished. Refresh of the display memory and refresh of the display are not synced.

32 minutes ago, sprudeldudel said:

I have a question regarding how from a technical point of view I can achieve to color the "car wipe" screen transition on getaway.

I´m not an expert in how to use colorization techniques on specific scenes because I have almost zero experience in colorizing . There a far more experienced artists you should ask and tag instead.

[sudsy7]

3 hours ago, sprudeldudel said:

Couldn't this be triggered with a mask excluding the area the artifact shows in? in that case it would not disturb the display.

I'm not actually triggering the frame with the artifact dots.  It's not a frame that is even present from a dump - it's sort of a "hybrid" frame (for lack of a better word) that consists mostly of the Super Cue scene but with a little bit of information from the 8 Ball scene.

3 hours ago, lucky1 said:

That seems to be a transition frame which comes from a change of the memory content on the capcom DMD controller which is not fully finished. Refresh of the display memory and refresh of the display are not synced.

  Ok, so it is most likely exclusive to Capcom and that's why nobody else is seeing the issue.  That transition frame never occurs if I make the 8 Ball scene a regular replacement scene just for your information.  I guess the reason the coloring is not persistent on the colormask scene is because the LCM trigger for the 8 Ball scene has actually occurred, which turns off it's coloring but leaves it's image on the display during the momentary delay before the LCM is actually displayed.

[lucky1]

3 hours ago, sudsy7 said:

That transition frame never occurs if I make the 8 Ball scene a regular replacement scene just for your information.

I´m pretty sure it occurs but it is faster gone and therefore not recognizeable. For replacement it only needs to load the color data of one frame.
 

 

3 hours ago, sudsy7 said:

  I guess the reason the coloring is not persistent on the colormask scene is because the LCM trigger for the 8 Ball scene has actually occurred, which turns off it's coloring but leaves it's image on the display during the momentary delay before the LCM is actually displayed.

The frame should only be updated if all color data is loaded. until then it should  stay on the current frame.  

Could it be that the last frame of the Super Cue Scene is not triggered by a single frame colormask , or that the detection mask triggering that last frame does contain the area where the artifacts are ?

Can you send me your project data through PM , that I can look into it.

[sudsy7]

3 hours ago, lucky1 said:

Can you send me your project data through PM , that I can look into it.

I couldn't figure out how to attach the files in a PM, but I'll send them to your email.  Also, if you need any logic output from the machine or anything like that, I'd be happy to get it for you. 

[lucky1]

2 hours ago, sudsy7 said:

I couldn't figure out how to attach the files in a PM, but I'll send them to your email.  Also, if you need any logic output from the machine or anything like that, I'd be happy to get it for you. 

The problem is that Super Cue is a replacement scene which has its own timing and ended to early. You can easily fix this by editing the dealy of the last frame and set it to e.g. 1000. It either display for one second if not new trigger comes but will be interrupted by the 8ball lcm trigger. 

[sudsy7]

On 2/26/2021 at 12:44 PM, lucky1 said:

The problem is that Super Cue is a replacement scene which has its own timing and ended to early. You can easily fix this by editing the dealy of the last frame and set it to e.g. 1000. It either display for one second if not new trigger comes but will be interrupted by the 8ball lcm trigger. 

I sent you an email, but the Super Cue End scene is just before the LCM and it is a single frame colormask scene.

Update:  The issue was resolved.  A dump of the real pinball machine showed outputted frames that were not present in the virtual pinball dump that were causing interference with keyframe hashes.   Thank you for your help @lucky1

[Pinballuser]

 

is their anything we can do to switch to 64 colors if the prompt to switch does not pop up when we load the project.

 

the only changes in the settings I have done

-create a shortcut when a scene is cut

-I had auto save every 5 min  but was getting a Java error so I disabled it.

 

I tried a project that was created with an older editor  and  created a new project in the 64 color editor  ; closed and reopened the project and I still did not get the prompt to change to 64 colors.

scratch that,      you can fix this by changing the number of colors from 16  to 64

top menu 

Pallettes/Mode --->Editor Configuration --->  General Tab  --->  Project  Colors = 64

 

 

 

 

 

 

 

 

[lucky1]

Version 4.08 is up on github which improves speed of LCM scenes for real pinball machines. You also need to export you rproject for real pin with the latest editor on google drive to get the full improvement

[sudsy7]

15 hours ago, lucky1 said:

Version 4.08 is up on github which improves speed of LCM scenes for real pinball machines.

That is an understatement.  This greatly improves speed of LCM scenes.  On Breakshot, before this upgrade, there were some frames where the ball rolls across the screen on the 8 Ball Tally Board that were noticeably missing, presumably while the LCM was being processed.  Now, I think every frame is shown.  Significant improvement (at least on Capcom real pinball).

[lucky1]

20 hours ago, Pinballuser said:

-I had auto save every 5 min  but was getting a Java error so I disabled it.

Should be fixed in the latest upload. Please check.
I also updated the check keyframe button that every possible combination of keyframes and masks is checked and not only the Mask/Hash combination which is assigned to a keyframe. 

[Terranigma]

Hi Lucky1, with the release of 4.08 which introduced this new improvement for LCM as well as back for 3.17 which added LCM support I was wondering if it was possible to add a version checker to the editor, colour files and firmware.

Something like a minimum version of firmware needed to run the colour file. It could be a simple flag such as MinVr=4.08 that is added to the colour file to check upon load. The firmware would look for the flag and if it is set to 4.08 and the user is running say 4.01 it will prompt them to update. It could just be a reminder/warning at the start or it could lock you out until you update depending on the settings. Maybe just a reminder/warning?

If the colour file has no version set then it will be ignored.

For example with someone running Last Action Hero on a firmware 3.0 it will have issues. There are a lot of people out there who don't use this forum or update as they should.

Yes it would require colour authors to export again but because 4.08 requires you to export with the new editor anyway to make it work it shouldn't be a problem.

The other upside to this is that it could encourage older colour files to be updated and checked for maximum compatibility with 4.08 and beyond. It would still be the choice of the creator but it would introduce some version control as well which is always good for the community and your hard work making sure everyone is updated and taking advantage of the latest features.

Thanks again for all your hard work and the new version is great.

 

[lucky1]

2 hours ago, Terranigma said:

Hi Lucky1, with the release of 4.08 which introduced this new improvement for LCM as well as back for 3.17 which added LCM support I was wondering if it was possible to add a version checker to the editor, colour files and firmware.

Something like a minimum version of firmware needed to run the colour file. It could be a simple flag such as MinVr=4.08 that is added to the colour file to check upon load. The firmware would look for the flag and if it is set to 4.08 and the user is running say 4.01 it will prompt them to update. It could just be a reminder/warning at the start or it could lock you out until you update depending on the settings. Maybe just a reminder/warning?

If the colour file has no version set then it will be ignored.

For example with someone running Last Action Hero on a firmware 3.0 it will have issues. There are a lot of people out there who don't use this forum or update as they should.

Yes it would require colour authors to export again but because 4.08 requires you to export with the new editor anyway to make it work it shouldn't be a problem.

The other upside to this is that it could encourage older colour files to be updated and checked for maximum compatibility with 4.08 and beyond. It would still be the choice of the creator but it would introduce some version control as well which is always good for the community and your hard work making sure everyone is updated and taking advantage of the latest features.

Thanks again for all your hard work and the new version is great.

 

Thanks for your input. In general you should ALWAYS use the latest version of the firmware.
So the instructions are simple "Always check for a new update before using pin2dmd with a colorization". Just tell this your customers. I think such a kind of version checking would lead to more confusion. For me feature requests like this are rather cosmetic und not on top of my priority list. My time is limited and I prefer to invest it in new functional features instead of such no functional features.

[Terranigma]

8 minutes ago, lucky1 said:

Thanks for your input. In general you should ALWAYS use the latest version of the firmware.
So the instructions are simple "Always check for a new update before using pin2dmd with a colorization". Just tell this your customers. I think such a kind of version checking would lead to more confusion. For me feature requests like this are rather cosmetic und not on top of my priority list. My time is limited and I prefer to invest it in new functional features instead of such no functional features.

No problem. For me it is no issue either because I can control the firmware version bundling myself and also between the other person and let them know and guide them. Anything I have will always be the latest as well. This was more a suggestion for others as not everyone reads the read me or follows instructions.
I understand about the preference to prioritise new functionality and that’s cool. Just thought I’d share my ideas.

I will focus on some feature suggestions in the future. 

Keep up the great work!

[outhere]

Have a feature so you can have the Pin2DMD off when you prefer the DMD on a LCD

Example: Frankenstein, Batman Forever, Maverick and, Baywatch plus a few other ones

Because these 4 tables uses a 192x64 dmd and not a standard one.

[lucky1]

8 minutes ago, outhere said:

Have a feature so you can have the Pin2DMD off when you prefer the DMD on a LCD

Example: Frankenstein, Batman Forever, Maverick and, Baywatch plus a few other ones

Because these 4 tables uses a 192x64 dmd and not a standard one.

That is something you can either control in Pinmame or Freezy already.

[outhere]

 

6 minutes ago, lucky1 said:

That is something you can either control in Pinmame or Freezy already.

You're saying I can make it so nothing will show up on my physical pin2DMD hardware
When I have your DmdDevice.dll file in the VPinMame Folder along with Freezy rename to DMDscreen.dll

By default I have Pin2DMD turned off in the DmdDevice.ini file and only have it on for the certain games but it shows up on the LCD and my pin2DMD

[lucky1]

2 hours ago, outhere said:

 

You're saying I can make it so nothing will show up on my physical pin2DMD hardware
When I have your DmdDevice.dll file in the VPinMame Folder along with Freezy rename to DMDscreen.dll

By default I have Pin2DMD turned off in the DmdDevice.ini file and only have it on for the certain games but it shows up on the LCD and my pin2DMD

I this constellation I think you have to wait for the new freezy DLL but that is not my job

[Pinballuser]

On 3/7/2021 at 9:26 AM, lucky1 said:

Should be fixed in the latest upload. Please check.
I also updated the check keyframe button that every possible combination of keyframes and masks is checked and not only the Mask/Hash combination which is assigned to a keyframe. 

No more java errors and auto save is working.

out of curiosity I assumed that the auto save would simply save over the existing project but it seems like the auto save is stored elsewhere.

I saved and closed the project and later came back to it when I opened it I got a  pop up with something along the lines of  "auto saved detected would you like to restore file" 

Where are the auto saved files stored, the only PIN2DMD files I found outside my PIN2DMD folder is in the Windows/User folder.

[lucky1]

1 hour ago, Pinballuser said:

Where are the auto saved files stored, the only PIN2DMD files I found outside my PIN2DMD folder is in the Windows/User folder.

The autosave files are stored as pin2dmd-autosave.xml+.ani in the user folder

[pticolu]

Hi,

I can't get my pin2dmd ( stm32 discovery ) to work with this version number 4 and VPinMame 3.3... 
I downloaded the package updated by lucky1 on github, replaced the .dll in the VPinMame folder and in XDMD but it doesn't work. My DMD only works on PBX, and the tables with ultra DMD, and my roms work with the VPinMame setup... I checked my .ini file in my DMDext folder several times but nothing works. I think I have the right firmware version because my DMD shows "colorprism v4.07".
It was working perfectly with VPinMame version 2.8 but I decided to update it because I had problems with the recent tables. 
Does anyone have the solution please? I would really appreciate it.
Thanks a lot in advance! 

Best regards

[lucky1]

33 minutes ago, pticolu said:

Hi,

I can't get my pin2dmd ( stm32 discovery ) to work with this version number 4 and VPinMame 3.3... 
I downloaded the package updated by lucky1 on github, replaced the .dll in the VPinMame folder and in XDMD but it doesn't work. My DMD only works on PBX, and the tables with ultra DMD, and my roms work with the VPinMame setup... I checked my .ini file in my DMDext folder several times but nothing works. I think I have the right firmware version because my DMD shows "colorprism v4.07".
It was working perfectly with VPinMame version 2.8 but I decided to update it because I had problems with the recent tables. 
Does anyone have the solution please? I would really appreciate it.
Thanks a lot in advance! 

Best regards

I think that problem is not specific to the firmware version but to your setup.

Please open a new thread.

[pticolu]

Ok thanks, I switch