freezy

VIP Class
  • Content count

    97
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by freezy

  1. I'm still pretty sure you're using an old version. I'll publish a new official release soon to get rid of that doubt. When using the exe, the log is what's displayed in your console.
  2. I've tested this. If it doesn't work I'll need your exact command plus the log.
  3. Sorry I was kind of slow these last weeks, but happy to see your issues resolved. And thanks for reporting your solutions, otherwise people would have spent time trying to resolve them in vain. EDIT: I'm posting this here as well: For those having crashes (probably quite a few), try this new build: DmdDevice.zip
  4. There is a post-build script that copies DmdDevice.dll to the VPM folder, you probably need to update it: Right-click on the PinMameDevice project, Properties, Build Events and under Post-build update the folder 3 times. Maybe try putting the .dll into SysWOW64 instead of the VPM folder, otherwise I'll need a log, please.
  5. New version here! I've added two new things for you guys to test: 1. In DmdDevice.ini, add: [browserstream] enabled = true port = 9000 Want to check the score of junior's game in the basement? Open a browser and connect to the IP of your cab port 9000 (or whatever you put). It'll stream the DMD live to your browser. 2. In DmdDevice.ini, add: [vpdbstream] enabled = true Then open https://test.vpdb.io/live in a browser and run a game. You might even see someone else playing. There were some other fixes and additions as well, e.g. you can now override settings per game in the .ini, like positioning the virtual DMD slightly differently depending on its resolution and backglass. More details in the changelog and README.
  6. No it's not required. However, the default options have all displays enabled, so if you want to avoid all your ports being scanned for pin(2)dmd1-3, you turn them off in the .ini. Also if you want to customize the other options you obviously need it.
  7. Yeah sorry, I'll update GitHub with a fresher release in the next few days. There have been a lot of changes and new features since.
  8. The GitHub release is very old. Try the one in this thread: DmdDevice.dll
  9. In VPM, make sure coloring is checked for the game you're running, and that the table you're running uses the colored ROM. Also, don't take the DLL from the official VPX installer because it has coloring disabled, you'll need the last one I posted in this thread.
  10. Ah nice find! Will update accordingly. Been playing around with network streaming, something cool coming up soon!
  11. Thanks for the report, something with non-standard resolutions seems indeed to be buggy, I'm currently looking into it.
  12. I don't do anything fancy for segmented output. Have you been able to test with another dmddevice.dll as well? Would be cool if we can figure out whether the problem's on DLL or VPM side before we invest more time into this.
  13. Yeah something with the virtual DMD seems to be screwed up. Debugging as we speak.. PinDMD3 users: Is the sound still stuttering? EDIT: If it does, try this one. I've moved the output code to different thread so VPM doesn't get stalled while sending stuff to the DLL (also the virtual DMD bug mentioned above is fixed). DmdDevice.dll
  14. Yes, those of you having crashes, please make sure it's really the DLL causing it. You can test that by unchecking "External DMD" in VPM, if it still crashes it's not the DLL. If you're using dmdext's DmdDevice,dll, look for an exception at the end of the log, that's another hint. If you don't see a log, make sure that DmdDevice.log.config is at the same location as the DLL. If the DLL is at a location you cannot write to as non-admin (e.g. SystemWOW64), edit DmdDevice.log.config and change the path of the log file to another folder. This is important, I can't fix stuff without a log.
  15. Hmm, that's weird. Do you have any other DmdDevice.dll in SystemWOW64 or System32? When it crashes, does it also crash when external DMD is not enabled in VPM? @Westworld which ROM crashes through setup.exe? I ran a few tests and for example Metallica Pro 1.70 crashes with SAMbuild 2.8b02 even without external DMD on my cabinet.
  16. Bugger.. Can you debug it? Pin2Dmd#SetColor() is run with the correct color, right?
  17. Thanks, that looks like the same bug roar described (PinDMD3 driver problem). If you got a log somewhere please post it, otherwise I'll have a look tonight. EDIT: D'oh, just looked at the PinDMD3 code for RGB24 rendering and yeah it might be better sending the frame when it's not identical to the previous, instead of vice versa. Updated DLL attached. DmdDevice.dll
  18. And this is a version that doesn't send the RGB24 frame if the previous one was identical. If you have a minute to check that RGB24 is still working that would be great. You'll see in the log how it's sent to the display. Best is to try with dmdext.exe, "dmdext test" should show (Bitmap => RGB24) when connecting. If the test image appears on the DMD that's already great, otherwise try dmdext mirror -s screen and move something in the upper left corner of your screen to check if more than 1 frame works. DmdDevice.dll dmdext.exe
  19. Okay then it's a PIN2DMD driver problem. Can you check if it's better with this? DmdDevice.dll
  20. Yes, the default color when nothing is set is orange. I've just tested that use case. Removed palette files from AFM, checked colored in VPM. In this case, the 4-color palette of VPM is applied.
  21. Well, check out this code. _colorize is the boolean from PMoptions.Colorize set by PM_GameSettings. _color is also set through the same call from the first three value of the same PMoptions struct. So what I'm doing in PM_GameSettings() is set the _colorize bool, the _color Color and run Init(), which runs SetupGraph(). So in any case, the color should already be set when running the block linked above. Do you have a use case where I can reproduce orange instead of blue showing up?
  22. Yes, and that. By "orange" I meant the color from VPM
  23. Okay for PinDMD3 it was a trivial change so I didn't test it on mine, but maybe I still screwed it up. However, a log would be interesting in any case. You can find it as DmdDevice.log and it would be very helpful if anyone having problems could paste it here (use the "code" formatting). @TerryRed: It should work like that: If "Colorize DMD (4 colors)" is checked in VPM, it searches for palette files. If none found, it just uses the color you have set in VPM. If that option is not checked, it renders orange. It shouldn't matter whether the DMD is virtual or not, If you see different behavior, let me know with a log please.
  24. @stefanaustria: Hmm yeah that would of course somehow be possible. Main problem is just that we can only have one nested level in .ini files. I'll figure something out. @Westworld that looks like a compilation issue. You're using 32-bit VPinMAME, right? Here's another build I've just tested. Make sure you run the 32-bit setup.exe. By the way: @DJRobX, you can now add ignorear = true to if you want the dots weirdly sized as well. And @CarnyPriest, H/VFlip are now switched. DmdDevice.dll