search

mjrgh / PinballY

A table browser and launcher ("front end") for virtual pinball cabinets.
Other
47 stars 22 forks source link

VNI/PAL Colorized ROMs not launching in color, Real DMD, consistently #41

Open kaicherry opened 5 years ago

kaicherry commented 5 years ago

I have several "Color ROMs" on my system colorized via pal/vni files. When launching from PinballY, the games are not in the proper colors/seem to be using default 4 colors.

Launched from Visual Pinball directly they are fine. Using Feb 7 64bit build, VPX 10.5, etc.

mjrgh commented 5 years ago

Are you saying that you're getting the wrong colors in Visual Pinball? In other words, you're not talking about what you're seeing within PinballY itself, but rather what you're seeing while the game is running in VP, when launched from PinballY?

kaicherry commented 5 years ago

Yessir. It's quiet...strange - the ONLY VNI/PAL pair this doesn't seem to effect is Star Wars; all other color PAL/VNIs that I have demonstrate what I described. Additionally, I have found in some instances that the Real DMD Dots change color from solid red-orange. They have been both yellow, and blue.

This has actually been going on for the last 3 or so builds/2019 builds.

mjrgh commented 5 years ago

Make sure you have logging enabled in dmd-extensions. Run until you get the wrong colors showing. Quit out of everything. Go to your Visual Pinball folder and look at DmdDevice.log. See if that sheds any light on it.

PinballY actually isn't involved in setting the color palette for a Visual Pinball game - that's negotiated between VP and DmdDevice.dll. The only thing I can think of for why PinballY affects it at all is that there's some kind of contention based on timing. PinballY tries to entirely release the DMD device before even launching PinballY, but maybe there's a thread running in DmdDevice.dll that needs a couple of seconds to let go. Hopefully the DmdDevice log file will tell you more about what's going wrong.

kaicherry commented 5 years ago

I will capture and post on next occurrence.

kaicherry commented 5 years ago

I was not able to "find anything" in any log...however with good old-fashioned repetition and deduction...I was able to find "a clue"

I was able to replicate the "situation" directly from PinMAME's Setup64; it simply appears that the DmdDevoce64.dll doesn't...do color. None of the colorized PAL/VNI pairs worked. From 32Bit, everything is fine.

Is it possible that, somehow, sometimes, when launching from 64bit PinballY, 64Bit DMDDevice.dll (DMDDevice64.dll) is still "in play"?

I actually went back and downloaded DMDDevice64.dll from GitHub to be sure I was using the correct/freezy dll. It does not appear to render vni/pal color at all in the 64bit flavor, software nor hardware dots.

mjrgh commented 5 years ago

It might be worth asking freezy about it. I think he does a separate build for the VP/VPM distribution that doesn't include color support, so maybe he forgot to do the normal color builds for x64 last time he did a release.

Is it possible that, somehow, sometimes, when launching from 64bit PinballY, 64Bit DMDDevice.dll (DMDDevice64.dll) is still "in play"?

That probably is the case at some level - once a DLL is loaded into a process's memory space, Windows keeps it cached in some ways even if the process unloads it. But I can't see how that would matter. Windows has an absolute rule that 32-bit and 64-bit code can't be mixed in one process. So even if DmdDevice64.dll is locked in memory, 32-bit VP/VPM shouldn't be able to see it. The only way that could make sense is if you're loading 64-bit VPM. Do you normally keep 64-bit VPM installed? But wait, I don't think that can be it either. VP loads VPM as an in-process COM server, meaning it's loaded as a DLL, which again triggers that absolute prohibition against mixing code types.

Assuming, anyway, that you're running 32-bit VP.

Do you have 64-bit VP + 64-bit VPM on your system? If you do, then this might finally explain it. PinballY figures out the default EXE for VP by looking at the .vpt/.vpx file associations. Maybe that's finding the 64-bit vpinballx.exe by default and launching that. You could try explicitly setting the EXE file path in the Visual Pinball setup options in PinballY to use the 32-bit VP EXE if you have both installed.

kaicherry commented 5 years ago

Ok. Easier, repeatable, for me:

  1. Run PBY in window, RealDMD set to Autodetect. Launch Game, say, AfM113b. DMD is in 4 colors.
  2. Quit VPX
  3. When returned to PBY, set Real DMD to "Disabled". Launch game, DMD is colorized.

I don't believe the 64Bit dll is being unloaded in this instance, or, as I said, for some reason, the 64Bit DLL isn't doing color. Explicit or implied vpx path doesn't matter, and I don't know that I have installed a 64bit version of VPX 10. VPX is 32Bit. I have no idea how/why it is "working"...only what seems to be happening :)

mjrgh commented 5 years ago

Okay, that's definitely good information.

Can you try a little more experimentation, on that basic theme? I want to make sure that switching between Auto and Disabled mode works reliably over many iterations - if so, I can effectively switch to Disabled mode while launching a game, and switch back on return. So if you could try doing a bunch of test runs like this...

Just do that in a loop a bunch of times to make sure that VP goes into color mode reliably each time. If that works, I think we have a solution - I can do the same things as when switching to Disabled mode before each launch.

kaicherry commented 5 years ago

Worked out fix/workaround - Remove DMDDevice64.dll from PinMAME/VPinmame folder. Install in PinballY root folder explicitly.

This seems to have fixed the situation, just did it. See if that helps/makes any sense.

mjrgh commented 5 years ago

Well, very interesting! I'm glad you found a workaround, but this new discovery is even more perplexing.

Even though you have a workaround, I'm going to go ahead with the more aggressive "Disable mode" type unloading during launch. When I have that in place maybe you can try moving the DLL back to the VPM folder and see if the problem comes back.

kaicherry commented 5 years ago

Will do.

mjrgh commented 5 years ago

I was about to do the more thorough shutdown along the lines of switching to Disable mode, and now that I look at it, it turns out that it's already doing that. Would you mind going back and doing that test I proposed earlier? That would be with DmdDevice64.dll moved back to the VPM folder, where it was originally when it was causing problems. Here's the test again:

The key here is to NOT EXIT PINBALLY at any point. I want to see if the enable/disable switching actually solves the problem repeatably as it seemed to in your earlier test. Based on what I see in the code, I'm thinking it's not going to solve it after all, but I'm hoping you can test it and find out for sure.

mjrgh commented 5 years ago

The beta 7 (out now) now explicitly unloads the DmdDevice DLL before each launch. If you have a chance, try moving DmdDevice64.dll back to the VPM folder where you had it originally and see if the PAL/VNI issue is still occurring.

kaicherry commented 5 years ago

NOJOY - issue is the same, likely to your surprise :) If the dll is only in VPinMame folder, when VPX starts, issue. If the dll is in PinballY folder, it's fine.

mjrgh commented 5 years ago

Okay, thanks for checking. I'm pretty much out of ideas, so I'll leave it open as "unsolved" for now. Hopefully someone will eventually find an explanation. Maybe run it by freezy if you have a chance and see if he has any ideas about it; maybe there's something he's doing in the DLL that's causing it.

For anyone running into the same thing:

kaicherry commented 5 years ago

You don't have to move it out. You just have to have a copy in the PinballY folder, perhaps PBY uses/loads that one explicitly. I certainly have less ideas than you do :)

mjrgh commented 5 years ago

Oh, good to know - I edited the workaround above to reflect that. You're right, PBY looks first in its own folder (that was originally intended to let you use a different version of the DLL for PBY if necessary, but it works out nicely for this case too. :))

blc29seb commented 5 years ago

I don't know if it's related but I also have some problems with the real dmd (i have pin2dmd screen) I am under pinballY 64bits the last version (i have both 32 and 64 bits version of dmd-extensions -https://github.com/freezy/dmd-extensions/releases) i put in attached my log files and i make a short video to illustrate the pb : https://drive.google.com/file/d/1tm8Q-376Z1yeByuF7xAEYgtOycFlsVYv/view?usp=sharing (video) DmdDevice.log PinballY.log

I use a png pictures to display brand of pinball the last action hero pinball has no media for the dmd and displays PinballY but sometimes the dmd screen no refresh with the current pinball the colors are bad not corresponding to the png picture (in virtual dmd and in game it's ok) the pinballY text changes color, sometimes it's white instead of orange

I have another question. Is that normal when I activate the virtual dmd I have images of the rom while on the real dmd I have nothing (see southpark on the video)

kaicherry commented 5 years ago

Mike, your new build/patchfix of freezy's DLL impacts this workaround in a negative way; for some reason the 32bit one refused to do color. Switched it back to your previous one, (for VPinMame) and am using the new one for PBY. Removing them, switch around, didn't impact what was happening, so i switched the 32-bit variant back.

I am not sure this is a me thing or not; the new 64-bit one in PBY folder with the old one in VPinMame was the only combo that worked.

mjrgh commented 5 years ago

Were you using a 1.7.1 variant before? There's a known bug (see Thalamus's posts on vpforums) in 1.7.2 where it doesn't do color. Since my patched version is based on 1.7.2, it unfortunately inherents that bug.

I'm in the process of adding the new patch to my 1.7.1 branch, so you might try that when I post it.

kaicherry commented 5 years ago

Yeah, that's it, i had 1.71...I remember this now :) Thanks man :)