I need to remind some people here who don’t seem to understand something.
Forks may be dead and development may not be as fast as the original.
However - you must think about the future and not the situation right now. Yuzu and Ryujinx sources will be invaluable information for people making emulators later down the line.
It’s a matter of when and not if someone picks it up again.
The way I did it is by trying to solve more and more advanced problems with simpler tools/features, then looking at more advanced features and seeing where they could be applied to make the problem solving simpler. Rinse and repeat.
An easy example that I can remember is making arrays that dynamically expand. I started with the barebones malloc and worked out how to use std::vector (and other list types) in its place.
Understanding that concept is, what I believe, to be the foundation of learning programming.
I’m no pro whatsoever, but using this method really helps me pick up and learn new languages.
Oh you mean Android Studio automagically “updating” your versions so that your build breaks and you spent 3 hours figuring out what just happened without you even touching anything?
Oh cool, I didn’t know!
I’ll go check it out, thanks!
I want to try to use Rust myself as well to build a library and I wonder how it’ll turn out (especially since I do Win32 hacks mostly lol).
No problem. Please do report back!
We really do not have many (if any) Rust alternatives for code hooking and injection and doing stuff with rendering like we do with C++.
Maybe you could finally figure something out we can use for other games as well!
I’ll preface this by saying that I’m not familiar with Rust nor Hearthstone at all, but I do deal with D3D9 and D3D11 on Windows to do similar things. Hopefully this will give you insights how you could approach this. (Closest I’ve done was code injection on Android)
The most common and robust approach to this is to hook/detour the API functions that the game imports from the renderer backend.
One way you usually do this is by creating a dummy library which overrides/intercepts the system library and passes through every function call to the API, except for the ones you need, you’d put your code before/after the passthrough. This usually requires you to gather all exported symbols and re-create them, which is a very tedious but rewarding task, as it usually is very stable and can work around things such as DRM.
Usually, since that sits quite low on the application’s code stack, it is most efficient for it to be a more general-purpose hook which can load other libraries. Examples would be things like the ASI loader or Reshade on Windows.
Another way would be to do code injection via library side-loading. Essentially, you can simply load a library that performs the code hooks and does necessary renderer API hooking. This is usually done in combination with the previous method (it being a “plugin” loader), however, it is also possible to modify game binaries to call dlopen to load your library and its exported function as an entrypoint (in which case you need to do platform’s CPU assembly code for a bit).
Those are the entrypoints for your code. After that, it is all about necessary render backend code that you need to do in order to draw graphics/text/etc.
In C/C++ land I’d just tell you to use Dear ImGui, but seeing as that doesn’t exist for Rust, you’re kinda on your own.
Same with the API detouring. Ideally, you’d make a plugin loader that does the job for you. Not sure if that exists in Rust yet.
For references, Vulkan overlays such as MangoHUD or ReShade could be useful to help you figure out how to draw stuff on screen.
As for the rest of your code - it can run in a separate thread that does the job for you as the game runs. Or, make a client-server relationship and make the game hook be the server for your info that you need.
This is the real issue. This is one area that Windows, despite its historical hardships, handles much better.
(Mac OS too but they killed kexts for the public anyway)
I’d love to see a more dynamic approach (that doesn’t rely on DKMS) someday.
Yes but, in practice some of these things don’t matter much at all. At that point you’re looking at the performance stack a bit too deeply.
Look at the bigger picture. For example - an RTX 4090 can perform about as well on PCIe 3.0 as it does on 4.0 in most tasks that you’d likely use it for.
You don’t have to care about some of these things as much as you used to before. Sometimes you can get too deep into hunting the best version of your system before you realize that it really doesn’t make that much of a difference.
Unrelated but this is totally possible on a PS4…
…after jailbreaking it and booting into Linux.
Which makes me even more mad at Sony removing OtherOS, but oh well.
I used to play Duel Links and shortly Master Duel after it came out. I don’t anymore but hopefully this will help.
If I was going back to the game, I’d go to look for budget deck lists and seeing what ranks up easily. Most of the community is on Discord and Reddit, as well as YouTube (yugitubers and alike) so I’d go and look there. (Not to mention Dkayed’s website, https://masterduelmeta.com and looking at the decks that topped, you’ll be surprised it’s sometimes not all meta stuff)
I’d also go look for some easy farming methods. These usually come in a form of a current event (IIRC in MD there are these “festivals” for each card type, such as Synchro Festival). These events are usually a very easy way to gain a lot of gems for not much playing.
It is what it is. TCG paper Yu-Gi-Oh is even more expensive than MD.
DL is arguably cheaper but it’s been a long time since I last played (2021).
EDIT: Oh and before I forget - there will always be Dueling Book as a free alternative. This is a manual simulator, not an automated one, and allows you to use any card you want with custom rules.
TRUXTON
EDF EDF EDF
Ahh the memories
Yes, both Yuzu and Ryujinx were open source.
Ryujinx is licensed under MIT and Yuzu is under GPLv3.