Jump to content

Pin2Dmd Editor


lucky1
 Share

Recommended Posts

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)

image.thumb.png.3b93cc6ba29cd8a227b7b24ab06d5c76.png

 

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.

Link to comment
Share on other sites

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 

 

image.thumb.png.5e4874c959804cc58abdea3765ad06a8.png

 

wheeeeeeeee

Link to comment
Share on other sites

  • 5 weeks later...

@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

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...