Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forks, contributions & betterDXcam vs BetterCam #100

Open
Avasam opened this issue Jun 18, 2024 · 6 comments
Open

Forks, contributions & betterDXcam vs BetterCam #100

Avasam opened this issue Jun 18, 2024 · 6 comments

Comments

@Avasam
Copy link

Avasam commented Jun 18, 2024

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

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
Copy link

E1Bos commented Jun 18, 2024

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
Copy link

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
Copy link
Owner

ra1nty commented Jun 27, 2024

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
Copy link

E1Bos commented Jun 27, 2024

@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
Copy link

elmoiv commented Jun 28, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants