Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
noflip95

Need help for basics editing, bug or what ?

Recommended Posts

hi,

I started a colorization project for the Gottlieb SYS3 "Barbwire", but I am having some difficulty understanding the logic of the Pin2DMD editor.
Either I did something wrong, or there is a bug because the result does not correspond to the programmed behavior.

I use the latest firmware (Colorprism v3.08) and the latest editor release (v2.5.0.6 dated 02-07-2020 - so very recent).

I've created a simple project:

  • only two palettes (one default with green shades, and one with normal colors red/orange/yellow/blue)
  • only two scenes, the startup screen and the "replay at screen", using colormask mode 
  • the two scenes are triggered by two keyframe, using a little mask M0 (same for both, but of course, with different values)

The project can be downloaded here :Barbwire.zip

When testing with VpinMame, it's works, but not exactly as expected.

  1. The first scene is well detected, the palette is loaded and the areas (lines) are well colorized (BARB*WIRE ... Gprom checksum) ✔️OK.
  2. The next sequence is an error message, not triggered, and colorized with the default palette.  ✔️OK, that look normal.
  3. The scores/game_over is displayed. Same as above, not triggered,  and colorized with the default palette.  ✔️OK, that look normal too.
  4. The "Replay At" sequence is displayed. Triggered, so use the correct palette and the areas are also well colorized.   ✔️OK, till now, the behavior is normal and logic.
  5. The score/game_over is displayed again. But this time, the palette/areas is  WRONG. Use blue/orange, but as there is nothing triggered here, it should use the default palette (green)
  6. The sequence continue, with high scores. As nothing is triggered, the default palette is used.    ✔️OK, we return here to something logical.

I'm newbie in colorization and try to understand how to use Pin2DMD editor.
I've read documentation and watched tutorials, but I can't understand this behavior.

What I'm doing wrong?
Why the score/game displayed after the "Replay At" still use the same palette?

I will be glad if someone could explain me, why this behaviour.

Here is the video of what happen at startup:

 

 

Share this post


Link to post
Share on other sites

Just checked the project file and your video. What is happening with your score scene is color bleeding. You colorized the replay at scene and the mask stays too long so it bleeds over into the game over score scene. First possibility is to add a palette switch to the game over scene, but you will need a mask to trigger it at the static content like the gameover text. Second possibility is to reduce the delay time of the replay at scene, but I would not suggest to do that. Since you anyway will have to use a mask, it would be more comfortable to add a static color mask scene, to be able to give different colors to the game over, credits and score.  Added a scene to the project, for you to see:

Barbwire.ani Barbwire.xml

Share this post


Link to post
Share on other sites

Yes, that's what I thought too, the mask has been applied for far too long. I tried by also putting a colorization on the game over sequence (with the same colors as you), that works ... but bad again 😥

After the "game over" screen is displayed, the high scores scroll.
The 1st/2nd/3rd/4th scores still use the palette set previously by the "game over".
But the 5th score, revert back to the default palette.

Why ? It seems that in some cases, when there is no keyframe detected, there is a time delay which maintains the previous palette.

 And we see the same problem after, with the sequence "Gottlieb" "by Premier" "Barbwire" that remain colored with the "game over" palette.
And then when "Say no to drugs" is displayed, it revert back to the default palette.

I tried to change the "duration" parameter but it has absolutely no effect.
With version 2.5.0.6 of February 4, entering manually this parameter is totally irrelevant. The input works in reverse, as in Arabic, if I type 12345, I get 54321! Worse, zeros are sometimes lost: if I type 504, I get 45 !!! it makes no sense

I wanted to open a bug in Github, but I saw that a new version was released on February 7 (with the same number 2.5.0.6 - it's useful to navigate there !!!). Now the duration field is grayed out and cannot be changed.

For me, it's clear, it's a major bug.
I don't think it's a problem of speed to analyze keyframes. I do not know if the problem is related to the editor, or to the firmware, but what is obvious is that it is not normal behavior.

 

Share this post


Link to post
Share on other sites

A single frame color mask is always applied until the next keyframe triggers. There is no way to assign a length how long a single mask has to stay, that is why the duration field is greyed out in my release.  Only simple palette switches have a duration. It has proven to be best practice to have triggers for every scene of the pinball machine. Like NetzZwerg already said, you simply need to assig a keyframe to the following frame to stop the single frame colormask of beeing applied or make it a 2 frame colormask and change the delay (not duration) field of the frames to suit your needs.

The duration field for palette switches should not be edited by hand. Scroll forward in the animation and use the fetch duration function to assign how long the pallete should last.

Btw make sure you use RAW version of the dump recordings to assign triggers to scenes for Gottlieb. However you can use the txt version to colorize the scene.

  • Like 1

Share this post


Link to post
Share on other sites
On 2/13/2020 at 10:43 AM, lucky1 said:

... Btw make sure you use RAW version of the dump recordings to assign triggers to scenes for Gottlieb. However you can use the txt version to colorize the scene.

The RAW version of the dump doesn't work.

I've tried with this dump file (and also with the non-zipped, but the result is the same): barbwire_attract.raw.gz

The "load recordings" works, the file is correctly loaded and recognized. But then, when I try to play the sequence ("start" button) or to advance a single frame, the JAVA hang with the error "Argument not valid":

2020-02-17_08h14_59.png.2d8f9664bb59ce7aaf092d9c24a2520b.png

And the displayed sequence look strange, as if some pixels where reversed or shifted.

The "WARNING" message (correctly displayed with the TXT version of the dump) is displayed as this:

2020-02-17_08h54_33.png.4c6bed3d90167139e42a849f9eb20a9a.png

I've tested with another dump file from another type/brand. 
With a Scared Stiff dump (Bally/Williams), the RAW dump file is correctly loaded and read. No issue with that.
So the RAW issue look specific to dumps created for GOTTLIEB pinballs.

It's strange, this problem look similar to those for which I had open a ticket on github (reversed typing in the duration field).
I've the feeling, that sometimes, text and datas are processed in reverse order (from right to left, instead of left to right).

Here, we clearly see that the WARNING message is partially displayed form left to right, and another part is displayed "mirrored" from right to left.

Share this post


Link to post
Share on other sites

The reversed bitorder is coming from the dump and not the editor. Did you create this RAW dump using a real machine or pinmame ?

Share this post


Link to post
Share on other sites

OK, thank you very much Lucky1,

This week-end, I did a "raw" dump test with the last VpinMame build (r4936) that I compiled. I also used the latest version of the editor (from February 20) and indeed, it works much better.

No more JAVA error and the display works much better.
Even if, I haven't understood everything about colorization yet, 🙄 but I'm trying to learn.

Obviously, so far no one has ever colorized anything for the GOTTLIEB SYS-3, or even has never tried to do it, otherwise they would have noticed these bugs.
Thank you for the correction.

Share this post


Link to post
Share on other sites
6 hours ago, noflip95 said:

Obviously, so far no one has ever colorized anything for the GOTTLIEB SYS-3, or even has never tried to do it, otherwise they would have noticed these bugs.
Thank you for the correction.

That is not true. There is at least the  Streetfighter II colorization from Malenko  and the  Super Mario Bros from ScottyC I know of. The difference is that these are completely based on txt dumps which can make a some problems if you use anything other than the first hash for the keyframe. RAW dumps are more reliable for keyframing, while you should still use the txt dumps to colorize the scenes.

Share this post


Link to post
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

×
×
  • Create New...