various problems with 2.2.0 beta 2

[Pinbalbilly]

Hello, I want to report several problems that I have with my zedmd. I have Vpinmame 3.6, frezzy 2.2.0 beta2, in zedmd HD, I find the following errors: sega tables Baywatch, maverick, Frankenstein, the dmd image is not understandable, everything is mixed up, it is impossible to use it. - tables data east hook, Batman, checkpoint, turtles, the dmd comes out double, duplicate, attached photos. Any help to fix the problem?

With freezy 2.1.2 it works fine, but I have a delay in some video modes

Using virtual dmd no problem

Thanks!!!!!

[Pinbalbilly]

Sega tables

Data East tables

[Westworld]

I have Vpinmame 3.6, frezzy 2.2.0 beta2, in zedmd HD same for me. Using ZeDMD in HD (using 4 x P264x64 displays) with 2.2 display from PinMame is mixed up. Even the test button from setup.exe, both 32 and 64 bit versions. Using DMDExe with -test produces a correct image. Going back to 2.1.2 and all works fine (or using 2.2 with 128x32 version of ZeDMD).

[Westworld]

Just noticed that the bad display is not "only" with ZeDMD, also with the build in web server. Just enable the web server, connect a browser and you have the same issue. I tried using Chrome on Windows 11 with game "24" ROM 1.5, but same issue with all other games.

It looks like every second line is empty and that produced that messed up display.

Here a screenshot, where I had the virtual DMD and the browser running on the same computer:

[freezy]

I'm not sure how the two could be related, but I'll find out. @zesinger could you reproduce this with ZeDMD?

[Westworld]

I'm not sure how the two could be related, but I'll find out.

maybe this helps. I tried with 24 (1.5), which is send as gray4Planes. With 2.1.2 dimensions is send as 256x64 (with HD enabled). With 2.2 dimensions is send as 128x32 The panes are 512 byte per pane, which would fit to 128x32, but produce that strange display (line filled, line empty). I manually overwrote the dimensions to 256x16 and now rendering was perfect, but of course only the top quarter of the screen.

For me it looks as if it would set the wrong size (not HD) but render in HD quality, but only in a buffer fitting for normal resolution.

[Westworld]

Tested 2.20 final, still the same.

Question: scaletohd = true

is this still supported/required? I could not find it in ReadMe. If I set it to false, all works fine (128x32 is send, ZeDMD scales it up). Setting it to true, the virtualDMD shows a visible better quality/scaling, and ZeDMD and Web Browser get s messed up (see above, as 128x32 is send with the data from 256x16, rest missing).

Workaround to use 2.2.0 for now is to disable HD.

This could explain why not many reports arrive, it only happens with scaletohd=true I tried scalermode = doubler and scalermode=scale2x

[freezy]

For ZeDMD the question to @zesinger and @mkalkbrenner is: In dmdext, there's a scalermode setting that upscales 128x32 frames to 256x64. This is mainly for those who like the upscaled images with their virtual DMD or other resizable destinations. My question is, whether dmdext should actually never do this for ZeDMD (and thus removing the option which up-scaling algorithm to use, there are two).

Right now, I think I've fixed the ZeDMD issue by emitting dimensions before sending the upscaled frame. But up to you. If you want to never received up-scaled frames, you'll need to refactor ZeDMD and not use IResizableDestination - in IFixedSizeDestination you could disable it with DmdAllowHdScaling. PR welcome.

The bug in browser stream should be fixed, too. Please test here:

• 32-bit
• 64-bit

@Westworld scaletohd has been replaced by scalermode. If you still have scaletohd in your config, that's fine, it's still read, parsed, and used. But you can also remove it and only use scalermode (for global upscale) and vni.scalermode to choose which algo to use in VNI colorizations that have upscaled frames.

[Westworld]

Quick testing with browser and ROM based tables: seems to work, but I'll do more testing. ZeDMD HD tested with many ROM based tables, all worked fine, but needs to play more on cabinet.

Flex based tables fails with both ZeDMD HD and Browser. So far I tested only JP's Horrorburg and Deadpool. They have at the beginning of their script the lines:

Horrorburg 'FlexDMD in high or normal quality 'change it to True if you have an LCD screen, 256x64 'or keep it False if you have a real DMD at 128x32 in size Const FlexDMDHighQuality = False

If that is false, ZeDMD HD works fine. If set to true, ZeDMD displays either nothing or only one image and then that image is frozen. With the previous 2.2.0 version (including betas) it worked with false, with true it showed the double screen images as in the examples above. With 2.1 it worked fine with false and true (=better quality)

Browser does not to display anything at all (black area, while Browser Inspector shows that Websocket works and package arriving). I need to do more testing here, that's more difficult on Cabinet, will do later on Notebook.

[Westworld]

I believe we can close this issue as solved now.

For me, all tables checked with ZeDMD HD works fine.

For Flex I don't know if that is an error in Flex, in ZeDMD or in DMDExtension or combination, in any case, the original issue is fixed. When I set flex to normal quality and scalermode=double, it works fine. When I set flex to Const FlexDMDHighQuality = true, Flex sends directly 256x64. This works with scalermode=none, but fails in combination with scalermode=double, then it sends 512x128 but only the upper left quarter, so bad display in ZeDMD. Anyway, this can be solved by avoiding the combination, which produces a double scaling.

I cannot verify that using WebSocket, as flex always sends RGB24 and this fails with WebSocket and 2.2. To avoid getting a too long mixed thread, I have opened a special case for that: #413

Suggestion: close this one. If needed, we should open a new one for flex.