noflip95 Posted February 11, 2020 Share Posted February 11, 2020 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. The first scene is well detected, the palette is loaded and the areas (lines) are well colorized (BARB*WIRE ... Gprom checksum) ✔️OK. The next sequence is an error message, not triggered, and colorized with the default palette. ✔️OK, that look normal. The scores/game_over is displayed. Same as above, not triggered, and colorized with the default palette. ✔️OK, that look normal too. 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. 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) 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: Barbwire_test.mp4 Barbwire_test.mp4 Link to comment Share on other sites More sharing options...
Content Provider NetzZwerg Posted February 11, 2020 Content Provider Share Posted February 11, 2020 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 Link to comment Share on other sites More sharing options...
noflip95 Posted February 13, 2020 Author Share Posted February 13, 2020 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. Barbwire_test2.mp4 Link to comment Share on other sites More sharing options...
Content Provider lucky1 Posted February 13, 2020 Content Provider Share Posted February 13, 2020 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. Link to comment Share on other sites More sharing options...
noflip95 Posted February 17, 2020 Author Share Posted February 17, 2020 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": 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: 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. Link to comment Share on other sites More sharing options...
Content Provider lucky1 Posted February 17, 2020 Content Provider Share Posted February 17, 2020 The reversed bitorder is coming from the dump and not the editor. Did you create this RAW dump using a real machine or pinmame ? Link to comment Share on other sites More sharing options...
Content Provider lucky1 Posted February 19, 2020 Content Provider Share Posted February 19, 2020 On 2/17/2020 at 9:24 AM, noflip95 said: So the RAW issue look specific to dumps created for GOTTLIEB pinballs. Fixed in the latest pinmame source https://sourceforge.net/p/pinmame/code/4915/ Adjustments needed in the editor will be in the next release. Link to comment Share on other sites More sharing options...
Content Provider lucky1 Posted February 20, 2020 Content Provider Share Posted February 20, 2020 Link to comment Share on other sites More sharing options...
noflip95 Posted February 24, 2020 Author Share Posted February 24, 2020 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. Link to comment Share on other sites More sharing options...
Content Provider lucky1 Posted February 24, 2020 Content Provider Share Posted February 24, 2020 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.