Forks, contributions & betterDXcam vs BetterCam

[Avasam]

Hi! Sorry that I have to open this on the upstream repo to talk about forks but the Issues tab is not available on the currently maintained forks !

To the fork owners, could you enable the Issues tab ? (Especially if there's a link to it on your PyPI page)

With many people wanting the promise of speed from DXCam, but without its current upstream implementation issues (especially since the archival / death of D3DShot). Multiple forks have been created. And now there's 2 being published on PyPI

• https://pypi.org/project/bettercam/ by @RootKit-Org
• https://pypi.org/project/betterDXcam/ by @E1Bos
• and another popular fork https://github.com/AI-M-BOT/DXcam by @AI-M-BOT

This brings the question: Is one objectively better than the other? And how? Should efforts maybe be combined to perfect the library with better visibility?

[E1Bos]

Hello, I'd be more than happy to enable the Issues tab.

I don't think one of objectively better than the other. My main reason for forking DXcam was to add support for the resolution changing during execution, which I need for some features using in my other program VALocker. I tried using bettercam, which advertized that feature, but I found it still crashed.

bettercam also has tight integration with numpy and other libraries, which increases the package size when compiled into a single .exe (take it with a grain of salt though, I may be incorrect)

With the owner of DXcam disappearing, I saw it as the only solution to implement the changes I needed.

This is fairly outside of the scope of my own coding expertise, and I'm not really familiar with PyPI as a package developer, so all suggestions and help are welcome.

[AI-M-BOT]

Hi! Sorry that I have to open this on the upstream repo to talk about forks but the Issues tab is not available on the currently maintained forks !

To the fork owners, could you enable the Issues tab ? (Especially if there's a link to it on your PyPI page)

With many people wanting the promise of speed from DXCam, but without its current upstream implementation issues (especially since the archival / death of D3DShot). Multiple forks have been created. And now there's 2 being published on PyPI

* https://pypi.org/project/bettercam/ by @RootKit-Org

* https://pypi.org/project/betterDXcam/ by @E1Bos

* and another popular fork https://github.com/AI-M-BOT/DXcam by @AI-M-BOT

This brings the question: Is one objectively better than the other? And how? Should efforts maybe be combined to perfect the library with better visibility?

Sorry i just saw this.
I have enabled the issue tab already, and feel free to pull requests!
I don't think there exists "objectively improve" now since @ra1nty did most of the great job and without him our forks won't exist. So far I have just done some minor modifications and brought some of the code from other contributors.
Publishing to PyPI? Not sure if it is necessary since some others already did.

[ra1nty]

Hi folks, pardon my disappearing, went through some life changes. I will start going through the issues & pull requests in the upcoming month and aim to do some updates & patches here and there. I would also be open to add fork owners @E1Bos @AI-M-BOT to maintainers/developers of this main repo. I'm also wondering will @RootKit-Org be interested in joining the development this main repo, as it's still the most downloadable / indexed pypi repo.

Btw thanks for the great work @E1Bos @AI-M-BOT. Really appreciate that.

[E1Bos]

@ra1nty thanks for the response! I appreciate the acknowledgment but I just implemented changes from #85 and #50. The real credit should go to @elmoiv for his lovely solution. However, I wouldn't mind helping maintain this repo if it means lifting some of the burden from your shoulders.

It's great to see DXcam get back the love it deserves!

Once #50 is merged and the PyPI package is updated, I'll be able to delist betterDXcam from PyPI.

[elmoiv]

Thanks for the mention @E1Bos, I was developing an anti-cheating software for a company and chose to use DXcam but while trying to fix some of it's bugs and stability issues, I settled on using mss with opencv as I only needed 30 FPS which was okay. The problem that DXcam failed with but mss didn't was when player unplugs an external screen while my software tries to record all available screens. This would crash dxcam adapter immediately (I think due to Desktop Duplication API) which led me to use mss instead.

I am also available for any fixes as DXcam is an amazing piece. It just needs some tweaks here and there.

Thanks @ra1nty

[lovettchris]

I found another way to do fast screen capture using Direct3D11CaptureFramePool and this does work in a remote desktop also.

See https://pypi.org/project/wincam/

I also simplified the interface to support screen coordinates with examples of how to find a window by point, hwnd or process id.