Add plugin support and refactor render graph. - #374

I´m currently on vacation and can start testing earliest in 3 weeks .
From the plugin side it makes no difference wether you have pac / vni or fsq as a source . If it works with one on your side it should work with all 3 . Did you test all source resolutions 128x32 128x16 192x64 and 256x64 ? With and without scaling ?
Is the plugin working with all of that ?
BTW there is no such thing like Gray6Source. No pinball machine sends frames in 6bit format. That can be removed from the code. It is a relict from the first days when we started to implement colored gray 6
6bit is always colored gray 6.

From the plugin side it makes no difference wether you have pac / vni or fsq as a source . If it works with one on your side it should work with all 3 .

Yes, the problem is just that my VNI collection is somewhat limited, and PAC files is what people will finally use.

If you could give me a few non-standard game names, that would help. Specially games with 128x16 input and games with HD output. Then I can hunt down those VNIs. Also, you were mentioning segdisplay colorizations?

Did you test all source resolutions 128x32 128x16 192x64 and 256x64 ? With and without scaling ?
Is the plugin working with all of that ?

A little bit in the train, and it crashed. ;) Looking into it.

BTW there is no such thing like Gray6Source.

Yes, I figured. Will clean that up.

Have a good vacation!

For 128x16 there are hook, batman, star trek 25th, checkpoint and tmnt. Games with 256x64 are Capcom Football Flipper but there is no colorization. Seg Display there is Lupin and Ken based on diner both presented by darden78 on vpu, but I can send you my testing project when I´m back.

Seg Display there is Lupin and Ken based on diner both presented by darden78 on vpu, but I can send you my testing project when I´m back.

Sorry, I missed this. I'll ping darden78 on VPU, maybe he's willing to share.

Seg Display there is Lupin and Ken based on diner both presented by darden78 on vpu, but I can send you my testing project when I´m back.

Sorry, I missed this. I'll ping darden78 on VPU, maybe he's willing to share.

I sent you a simple test project

I recognized that you have the color rotation code in the virtual display. I moved it to colorutils and that way made it available for all RGB24 devices like pixelcade, pindmd3, avi etc.

Okay, I'll have a look. Right now, when rendering the rotations for the virtual DMD, we actually only update the palette in the shader (as opposed to rendering an entire RGB24 texture).

Your LibDmd/DmdDevice/AlphaNumeric.cs does also not have my latest fixes

Your LibDmd/DmdDevice/AlphaNumeric.cs does also not have my latest fixes

Hmm, I'm pretty sure I did pull your changes. I haven't gone through all of them yet, but this one seems up to date.

Your version versus mine.

Anything particular that is missing?

I just had a look at your plugin code. Why do you try to split the RGB24 frame in palette based frames in there, while the majority of the supported devices does not need that ? Why not only split frames and generate a palette when the output device needs it to overcome performance lags that way ? So far I have no performance issues reported from pindmdv3, pixelcade or pin2dmd users processing the colorized frames as RGB24.

Because it's the frame format that goes into the render graph, and once it's in there, subscribers don't know whether it's a frame that can be converted back to colored gray. I profiled it, it turned out not to be an expensive operation.

Did you take both the splitting into palette based and the conversion back to RGB24 for e.g. the virtual dmd into account for your profiling ? I introduced a coloredgray source to be able to differentiate a normal RGB24 frame from a colorized RGB24 frame in the rendergraph.

The virtual DMD renders colored gray frames, the RGB conversion is done in the shader.

It's funny that you seem to be concerned about performance now, when you could simply return colored gray frames in the plugin and get the best of both worlds. ;)

Frankly , personally I don´t care because I don´t use my vpin cab anymore. But if users recognize that your implementation of the API is laggy compared to mine there might be an issue. But if you are sure that the speed is the same - fine !

@lucky01 I've added frame de-duplication since it avoids a whole lot of garbage collection. Is the plugin dependent on a trigger of duplicate frames, or will that still work?

The plugin it attached to the 15ms frame timing of pinmame

What happens if the plugin only gets frames when they change? Some animations don't play?

I expect some scenes have a wrong timing e.g LAH with movie replacement scenes,
They will not be updated depending on the scene frame timing but on the source change timing.
As a sidenote I tested frame deduplication to the pinup output and some pup frames did not trigger that way.

#347 (comment)

Okay, thanks.

I'll de-dupe after colorization then. TBH I have never used PinUP and @nailbuster is currently on holidays.

I'll release a beta version of this branch tonight, since PinballFX is launching a new version today with dmddevice support, for which I had to add a few fixes, which ended up in this branch.

Hopefully I'll get the de-duping fixed before, otherwise that will be another beta.

Are you back from holidays and did you happen to test this a bit more?

to debug, if you want to see what pupdll is getting from dmdext. In vpinmame folder set showdmd=1 in the dmddevicepup.ini you should see a small 128x32 window at position 0,0

I already checked that and the frames are forwarded correctly, however it seems that the matching does not work reliably with the 32bit version.

from memory i remember only getting 'changed' frames which i thought was great as it meant i didn't need to worry checking for dupes on the pup side.

No in previous versions you received the frames at 60Hz without dupe check.

I can't reproduce the FlexDMD issue you have on VPU (it's down, so posting here). If you pull latest and compile it with the TEST_WITHOUT_PIN2DMD compiler flag, it'll just write the frame size to a pin2dmd.txt file for PIN2DMDs. That's how I'm testing without the device.

I'm getting frame data for both PIN2DMD and virtual DMD. Can you reproduce with that? If so, can you share your DmdDevice.ini?

TBH, I don't think it's fair to stall because of this. It's literally and edge case of an edge case that has nothing to do with the plugin nor coloring in general.

Sure ! Can do next week ! The more critical issue is PUP triggers not working correctly on 32bit compile. Any updates ?

I´m not stalling anything here I just want to make sure it is working at least as good as my current version and does not contain issues that were already solved there.

I'm getting frame data for both PIN2DMD and virtual DMD. Can you reproduce with that?

I can reproduce that however when I start FlexDMDUI, go to the designer tab and click on run you can see that with virtual set to false it only sends 2 packets while with set to true it constantly sends packets when the display changes. I assume without virtual it only sends the init frames but not the display content.

When you exit flexdmdUI it sends another 3 frames for deinit.

Thanks, now I see it. Looking into it!

Try this. I haven't tested everything because I'm on vacation and it's difficult to launch actual games through remote desktop, but the missing output should be fixed.

I'll look into pinup when I'm back home, but this might got fixed as a side effect as well. If you could verify that'd be awesome.

I'll look into pinup when I'm back home, but this might got fixed as a side effect as well. If you could verify that'd be awesome.

I don´t have pinup installed but will ask someone to test. Enjoy your vacation

FlexdmdUI works fine now but

Baywatch 1.0.5 (192 x 64)
.pal/.vni color files, 32bit some pups trigger, many do not

still the same problem !

Okay, cool. So pup is the last remaining issue?

I have another two issues here which I need to check wether they are caused by the plugin or your code.

@lucky01 any hint of a trigger in Baywatch that I could test? I have Pup set up now, but I'm kinda clueless what to look for.

I can only forward the information I receive, because I don´t have pup installed.
It seems that the 32bit does not trigger at all or rarely while the 64bit version does work quite well.
My version is stil working best in both x86 and x64. Maybe just play the table and see the difference.