Open psiomicron opened 2 years ago
Seems like 32bit also has a similar issue, but for whatever reason it works fine the 1st time started. The following times, it fails, too. So somehow the 32bit version is more lucky with some uninitialized mem maybe?
To be honest 32bit seems to work and is playable for me, but I do notice when I close out of the table VPX will crash as well, so maybe it's related.
On Sun, Nov 20, 2022, 16:21 toxie @.***> wrote:
Seems like 32bit also has a similar issue, but for whatever reason it works fine the 1st time started. The following times, it fails, too. So somehow the 32bit version is more lucky with some uninitialized mem maybe?
— Reply to this email directly, view it on GitHub https://github.com/vpinball/pinmame/issues/80#issuecomment-1321273085, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFPTQP5HLJE75RNSSNA7GX3WJKW7BANCNFSM6AAAAAASE7K7JE . You are receiving this because you authored the thread.Message ID: @.***>
ROM works presently with both 32 and 64 bit builds you just cannot reinitialize it unless you end VPM, the display will be blank.
Thanks! This points once more to some instability/uninitialized memory, i guess.
@toxieainc if it is any consolation if i run up the ROM in a current build of MAME, it does not seem to like to restart/reset while active in memory either.
ROM works presently with both 32 and 64 bit builds you just cannot reinitialize it unless you end VPM, the display will be blank.
Are you sure it works for you in 64 bit? I've update and reinstalled vminmame for 64 bit on different computers and it doesn't run. Audio works but graphics are garbled.
yes, works fine far as i can tell here
I'm also getting this problem, using VPinMAME/libpinmame/PinMAME version v3.6-573-5d6459d on Windows 10 Pro (64-bit). I have no clue if VPinMAME has any way to create a verbose log file of a game; if it does, I'll happily provide one.
ADDENDUM: I just tested and this still happens as of the latest commit: aaa6676.
Here's a video I recorded showing the garbled graphics, but otherwise functional game. (note how the graphics change later in the recording; I believe this to be further proof that uninitialized memory is the cause of the problem).
https://github.com/vpinball/pinmame/assets/22881403/ba2cd8a0-a629-4166-9fc7-2a5f56316212
Some observations:
babypaca
and babypacn
that have this problem. Other hybrid games like Caveman work just fine.Since libpinmame
in your post caught my eye, I decided to check to see how babypac
is handled in libpinmame
.
This game has a display type of CORE_VIDEO
. All updates are ignored because of this line:
`if (((ptPinMAMEvidUpdate)(layout->fptr))(bitmap,cliprect,layout) == 0) continue;`
libpinmame
has a callback for each display, and this continue totally skips over it.
For the heck of it, I modified
static PINMAME_VIDEO_UPDATE(byVP_update) {
TMS9928A_refresh((core_gameData->hw.display ? 2 : 1), bitmap, 1);
save_screen_snapshot(bitmap);
return 0;
}
And indeed the screen is there:
I'll look into this some more to see if I can add support in libpinmame
and vpx standalone.
If its 'only' the 64bit display code of VPM, then hopefully this is easier to fix. Lets see how testing goes if libpinmame eventually get support. Thanks!
I did some more digging (namely by trying to find a bisect, albeit with limited resources as I'm relying entirely on Github Actions artifacts) and determined that babypac
broke at some point between Release 3.5 and this commit: https://github.com/vpinball/pinmame/compare/v3.5-217-bd54096...v3.6-369-102e419. There's still about 300 or so commits to dig through, though I hope this at least helpful to point out!
Same for me, Babypac show garbled screen with 64 bits vPINMAME only, 32 bits work properly.
The last working version of Babypac in 32bit was 10.8.0-925. All the releases after, the drop target in front of the captive ball is up when the game begins. The drop target should be down so you can hit the captive ball and transfer it to the other side.
Ok it is a vpx issue.
sorry, my post is at the wrong place.
Something is pretty strange with Baby Pac-Man... If I start a game and wait until Pac-Man can move, then hit reset, the game will reboot okay. If I reset the game during attract mode, or before I can move, reset will cause a blank screen, and starting a game isn't possible.
Pereaps it’s a rom initialisation issue. This table have alway started with sound stutter before. I think this kind of rom need more time to initialise?
Steve Ellenoff owns a Baby Pac-Man, and he did the emulation back then. The stuttering bootup sound is actually correct, the real game does it as well. And of course you cannot really reset the game as your can in PinMAME hitting F3, you can only switch it off and on, so that error simply cannot occur with a real machine. 😉
@volkenborn Thanks for clarification. I never played the real pinball machine. :)
Well. I could fix at least the reset issue; that was due to some uninitialized sound latches. A possible explanation why the graphics issue only occurs with Baby Pac-Man: it's the only game rotated by 90 degrees by driver!?
@volkenborn I will test your fix when coming at home Thanks you very much for the fix An other similar hybride table having similar strange issue is the Caveman table The rom crash half the time when starting the table since the first release I think I think you could find something wrong with the rom initialisation?
@volkenborn vPinmame show garbled image at 0 Deg normal position Tested the table and you are right about the rotation issue, rotating to 90 Deg and the screen are shown so not at the right orientation. tested from the table init section of the table script: .Games(cGameName).Settings.Value("rol") = 1
.Games(cGameName).Settings.Value("rol") = 0
Maybe also related to https://github.com/vpinball/pinmame/issues/129 ? (as the old MAME uses a lot of 32bit x86 ASM code for blitting, which may be incomplete/outdated in the C variants??)
Babypacman rom does not work with VPinMAME 64 bit. Images is scrambled. 32 bit works fine.