freezy

VIP Class
  • Content count

    88
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by freezy

  1. Ah nice find! Will update accordingly. Been playing around with network streaming, something cool coming up soon!
  2. Thanks for the report, something with non-standard resolutions seems indeed to be buggy, I'm currently looking into it.
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. Bugger.. Can you debug it? Pin2Dmd#SetColor() is run with the correct color, right?
  8. 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
  9. 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
  10. Okay then it's a PIN2DMD driver problem. Can you check if it's better with this? DmdDevice.dll
  11. 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.
  12. 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?
  13. Yes, and that. By "orange" I meant the color from VPM
  14. 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.
  15. @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
  16. As I explained above, if you just care about PBFX2 it's dmdext.exe, otherwise you're welcome to test VPM with the DLL as well.
  17. Fuck me, how many posts do I need to type in twice because of this buggy IPBoard. Grmpf... Anyway, here's a new build. I've included dmdext.exe as well, so @bent98 please have a try with PBFX2. Also try crazy frame rates like --fps=120. @roar and @Jodannar, please check if you still got stuttering. I've benchmarked PinDMD3 a little and I'm getting around 8mbps on the bus which takes 1ms to send over a colored 2-bit frame. So as Lucky1 said, it's probably not a bandwidth issue. @Westworld the video problem should be fixed as well. DmdDevice.zip
  18. @Westworld: Yeah I might have broken that feature in a previous refactoring. Will look into it, but it's not a codec problem as far as I can see. I'll probably post a new binary later today.
  19. Yeah I don't have a working PROC setup yet. But it's on my mental TODO list.
  20. Nope, although it would nice to test it and give feedback. Spent quite a few hours rewriting it so PIN2DMD gets more optimized data. Will post a new binary as soon as Lucky1 validates it.
  21. Hmm and it didn't stutter before at all? For Pinball FX2, you'd need to update dmdext.exe when I release a new version. Both the exe and DmdDevice.dll are based on the same code though, that's why optimizations apply to both projects. The dmddevice.dlls from Lucky1 are pure C-implementations for each display, so you'd need a different one for each display. They are fast but contain only minimal features, i.e. sending frames from VPM to the display. The DmdDevice.dll from me is "universal", meaning one single file for all displays, plus virtual DMD support. It also implements Lucky1's frame-by-frame coloring algorithm that was previously only available from PIN2DMD users (because it was implemented in the display's firmware, not in dmddevice.dll).
  22. I'm working on the performance issues. I've refactored my render graph so it now can output palette-encoded bitplanes which are easier on the DMD's CPU and the port's bandwidth. Lucky1's PIN2DMD driver already does that, but mine should do it too now. Good news is that the original dmdext benefits from this as well, e.g. Pinball FX2 will get performance boost with PIN2DMD/PinDMD3 displays as well. For PinDMD3 I'll play around with the port speed, but I might end up just capping frames at a lower frame rate as Lucky1 suggested.
  23. Sounds like a major failure to me. @russdx, care to comment? Can you send more than 1mbps to PinDMD3? Why did you use a crappy serial port instead of USB?
  24. Uhm so why not pick just a faster interface for the damn display? USB is way faster than that? Are the controller more expensive or what's the problem? I'll have a look at manually doing some congestion control but this sucks.