Pin2Dmd Editor

[lucky1]

On 8/1/2021 at 3:53 AM, malenko said:

So, getting mad errors on the beta. Lost on why I cant select more than 16 colors (its in 64 color mode)

 

What you sent me is a 16 color project and not a 64 color project. You need to select convert when it loads and all should be fine.

[malenko]

I'm not *that* retarded.  Hit convert, save,  exit editor,  reopen, load project, get same "zomg this is a 16 color file!?!?!"
lathe rinse, repeat.

 

I just loaded up the editor on a different computer and it seems to have taken, so when I get home I'll just wipe out all the pin2dmd program files and go from there 

 

 

wheeeeeeeee

[lucky1]

Did you enable 64 colors in the config ?

[malenko]

its all sorted, I just deleted all the pin2dmd exe files and stuff form my main PC and downloaded new ones, everything's working just peachy now.

 

 

[lucky1]

Fixed a bug in RAW dump reading in latest beta

[malenko]

I'm having trouble copy/pasting to and from the editor to photoshop.

[Terranigma]

@lucky1 If I load up a dump in the editor and attach a Pin2dmd via USB with colour files for that game which the dump is from, should I be able to do a live preview and get a 1:1 representation of the colour file? I'm doing some testing and I am not sure if the colour file has issues or if the editor/USB connection is too slow and is causing the colour file to break. I'm basically playing back the raw dump, it seems to have a bit of lag.

If it's not fast enough, (speed 10) is it possible to speed it up to be 1:1 of a real pin? If it's my setup, is there anything I can do to improve it? Thanks

[lucky1]

The livepreview can be used to check wether each frame is triggered and colorized. A exact replication of the real pinball playback speed is never possible. Generally you can say if it looks good on the livepreview it will also look good on a real pinball. If every frame is triggered the playback speed is not of importance.

Maybe colorization authors can help you better with your specific problem than me. 

 

P.S. please stop tagging me in your posts. There are plenty of others who can answer such questions. 

[Terranigma]

Thanks. 

[slippifishi]

OK I have done a bit of HD editing tonight and trying to figure out how I can add this to my workflow. I am a little concerned that I will need to switch triggers between exports; for instance, if I use an HD scene in a project then run it on my 128x32 display, I see noise instead of the scene (obviously, it is not designed to show that data, this is not my problem). At this early stage of upgrading it's easy enough to track triggers and scenes and swap them back and forth between exports as it is just a handful of scenes, but as the number of HD scenes increases to the levels of a complete project it would be difficult or maybe impossible. I don't want to break my 128x32 support so I can add some HD screens for those fortunate enough to have one...

 

Just thinking out loud but perhaps there could be a new export function in the editor that would allow a project to support both types? For example:

 

1. Select the scene to be scaled to HD - for example "slippi scene"
2. The editor generates a new matching 256x64 scene using the selected scaling method and generates a name "slippi scene_HD"
3. The original scene is also renamed "slippi scene_SD"
4. If the scene is already keyframed, the keyframe remains and continues to point to the newly named "slippi scene_SD"
4. At the point of exporting/using a new export option, the user chooses between SD export and HD export
5. During file generation, if the user selected HD export, then for each keyframe of the applicable types where the scene has a name ending in "_SD", look for a matching scene name with "_HD", eg slippi scene_SD := slippi scene_HD
 - If a matching scene is found, use that for the trigger instead.
 - If no scene is found use the orgiinal keyframe scene as defined.

 

* There are probably a few gaps - should confirm "slippi scene_SD" doesn't exist before the scale function is used in 2 so the rename in 3 will be safe

 

In this way, my existing projects can be easily upgraded while keeping 128x32 support for bug fixes etc without duplicating the project or requiring swapping triggers. It might also help encourage other artists to generate some HD content if they can be assured their existing projects can still be used by non-HD users.

 

Happy to add something to github if you would like lucky, but wanted to bring up the conversation here first in case anyone else has any thoughts

[lucky1]

42 minutes ago, slippifishi said:

OK I have done a bit of HD editing tonight and trying to figure out how I can add this to my workflow. I am a little concerned that I will need to switch triggers between exports; for instance, if I use an HD scene in a project then run it on my 128x32 display, I see noise instead of the scene (obviously, it is not designed to show that data, this is not my problem). At this early stage of upgrading it's easy enough to track triggers and scenes and swap them back and forth between exports as it is just a handful of scenes, but as the number of HD scenes increases to the levels of a complete project it would be difficult or maybe impossible. I don't want to break my 128x32 support so I can add some HD screens for those fortunate enough to have one...

 

Just thinking out loud but perhaps there could be a new export function in the editor that would allow a project to support both types? For example:

 

1. Select the scene to be scaled to HD - for example "slippi scene"
2. The editor generates a new matching 256x64 scene using the selected scaling method and generates a name "slippi scene_HD"
3. The original scene is also renamed "slippi scene_SD"
4. If the scene is already keyframed, the keyframe remains and continues to point to the newly named "slippi scene_SD"
4. At the point of exporting/using a new export option, the user chooses between SD export and HD export
5. During file generation, if the user selected HD export, then for each keyframe of the applicable types where the scene has a name ending in "_SD", look for a matching scene name with "_HD", eg slippi scene_SD := slippi scene_HD
 - If a matching scene is found, use that for the trigger instead.
 - If no scene is found use the orgiinal keyframe scene as defined.

 

* There are probably a few gaps - should confirm "slippi scene_SD" doesn't exist before the scale function is used in 2 so the rename in 3 will be safe

 

In this way, my existing projects can be easily upgraded while keeping 128x32 support for bug fixes etc without duplicating the project or requiring swapping triggers. It might also help encourage other artists to generate some HD content if they can be assured their existing projects can still be used by non-HD users.

 

Happy to add something to github if you would like lucky, but wanted to bring up the conversation here first in case anyone else has any thoughts

 

What you suggest could work for replacement scenes but I don´t think that it will work for dynamic scenes where parts of the screen need to be replaced using LRM mode instead of "only" colormasked. There you have different colorization modes which are not compatible with each other in terms of keyframing etc. So I think in the end you will end up with two projects anyway.

[slippifishi]

I have found a small bug in the editor which is sometimes causing a crash and potential loss of work. Latest editor, fw 4.23, replicated as follows:

 

Open a project, switch on "live preview" and select a scene. Create a new palette. "Live preview" setting is disabled (this is expected, the list of palettes has changed). Re-enable "live preview" and reselect the scene. Edit the newly added palette and select a new colour. At this point, the PIN2DMD display crashes/turns black, and the editor becomes very unresponsive, almost as if stuck in a loop; there are no errors displayed.

 

You can wake the editor up again by cycling the power to the display, but if you just power the display off, the editor is now in a bad state (live preview enabled with no display connected) and can full on crash without any exception dialog if you try and perform any more actions that would result in a display update.
 

[lucky1]

On 9/24/2021 at 3:03 PM, slippifishi said:

I have found a small bug in the editor which is sometimes causing a crash and potential loss of work. Latest editor, fw 4.23, replicated as follows:

 

Open a project, switch on "live preview" and select a scene. Create a new palette. "Live preview" setting is disabled (this is expected, the list of palettes has changed). Re-enable "live preview" and reselect the scene. Edit the newly added palette and select a new colour. At this point, the PIN2DMD display crashes/turns black, and the editor becomes very unresponsive, almost as if stuck in a loop; there are no errors displayed.

 

You can wake the editor up again by cycling the power to the display, but if you just power the display off, the editor is now in a bad state (live preview enabled with no display connected) and can full on crash without any exception dialog if you try and perform any more actions that would result in a display update.
 

 

I used the latest beta of the editor and yould not reproduce the problem.

Please try setting your display to default settings

[SpaceGambler]

I went to download the latest editor yesterday, is there a 32bit version to run on 32bit Windows or only 64bit now?

[lucky1]

Only versions for 64 bit Java Runtime

[TheFool]

I was wondering if there is a way to merge 2 projects together. I have tried to "Import project" from the File dropdown menu, but cannot get it to work. I run into a java lang error calling "onImportProject". I searched the forums here, with no luck. I might be missing a step or two in the editor, or possibly there is a particular way the files need to be configured. I have tried a few different things but with no luck. Thanks, Matt

[lucky1]

You need to do this manually by importing / exporting single scenes 

[TheFool]

Ok Great, Thank you for clarification. I will do that. I always appreciate how fast you respond to all the questions that come up about how to do this or that. I really did try to find answers in the forum, but no luck. I did find a ton of great info and tips about Pin2dmd and the editor, so it was time well spent.  Thank you again. Matt

[sudsy7]

I have a question (probably for @lucky1) for when you use a gif file as an input file.  I load them and make scenes and keyframes with them - no problems and everything works fine.  But every time I load the project subsequently, the palette for that gif is apparently loaded again, because I always get a message to the effect that it already exists and I have to acknowledge it before the project continues loading.  The palette is indeed already created and is permanently in the palette list - because it was created the first time the gif was loaded as a recording.  I don't even use the palette, but it automatically is created at startup every time.  How can I stop this annoying message from popping up every time?

 

[kara2010]

Hello,

I am trying to get along with Layered ColorMask, but unfortunately I fail.

 

In my example I try to edit the Scene "ATT - credits" as Layered ColorMask. I have selected D-Mask, and marked an appropriate area. Then I selected a hash and pressed "Set Hash".

 

This is the state of my screenshot:

 

But as soon as I select another Scenes, and then again the "ATT - credits", no more D-Mask is set. How do I get this saved?

 

If I look at this tutorial here:

https://pin2dmd.com/chapter-8-advanced-coloring-using-colormask-layered-mode/

 

Like on the screenshot from the tutorial here, my hash should start with M1 when I click on Set Hash. But that doesn't happen.

 

I will be grateful for any help.

 

Kind regards

Karsten

[lucky1]

You can verify the hash stored for the selected LCM frame in the area marked in red here.

[kara2010]

Hello Luck1,

on the screenshot from the tutorial you can see that the keyframe is selected. You can see all D-Masks and the check mark set at D-Mask. In addition, there is an M at the front of the hash.

When I click on the keyframe, there is no M in front of the hash, the D-Mask check mark is not set, and I don't see any masks in the edit window as in the tutorial.

 

 

Something is wrong.

 

Greetings

Karsten
 

[lucky1]

5 hours ago, kara2010 said:

When I click on the keyframe, there is no M in front of the hash, the D-Mask check mark is not set, and I don't see any masks in the edit window as in the tutorial.

 

That is normally the case when no mask is used to generate the hash of the keyframe selected.

[kara2010]

7 hours ago, lucky1 said:

That is normally the case when no mask is used to generate the hash of the keyframe selected.

 

And that's where my problem is. I have used a D-mask, and it still does not work.

 

In the following screenshot you can see the following.

 

1. D-Mask is selected.
2. layered ColorMask is active
3. the hash is assigned.
4. despite assigned hash with activated D-Mask no M was prefixed to the hash.

 

 

I have been working on this for many hours, but I am running out of ideas.

Could you please check if there is not a bug in the current version of the editor?

 

Thanks a lot for your effort.

 

 

Kind regards

Karsten

 

 

Edited June 16, 2022 by kara2010

[lucky1]

The M in front of the hash is only displayed when a global D-Mask is used to generate a KEYFRAME. It is NOT displayed in "scene specific" D-Masks of a LCM or LRM scene.

 

Furthermore the M is just informational and has no function at all.

 

As long a the hash is detected either calculated with no mask, with a global or scene specific mask the color should be applied.

 

It is not a bug.