• 0 Posts
  • 28 Comments
Joined 8 months ago
cake
Cake day: March 21st, 2024

help-circle


  • For PSP development, PPSSPP can be very good if configured correctly and you know how to use it.

    You can debug on a PSP using psplink but compared to PPSSPP it’s a nuisance to do it every single time. Plus, using a GUI debugger is way nicer anyway.

    What really fascinated me was Sony’s approach. For all intents and purposes, it was on par with the PS2 or even better (because of more memory).

    Yeah sure, the VUs coupled with the GS throughput were better for graphics processing than the Media Engine in the PSP, but the devil is in the details.

    But unlike the PS2, it has a real OS that is capable of loading modules and even do some fake multitasking! This was groundbreaking for the time and this is what made it so magical for homebrew IMO.


  • It’s very good.

    Basically, there is one maintainer in the AUR (the name escapes me, jonathon I think it was?) who applies the necessary patches to the old NVIDIA drivers to make them run with a modern Linux kernel.

    Of course, there won’t be any Wayland support, but the experience is acceptable as long as you temper your expectations in terms of graphics API support. (No vulkan sadly)

    I hadn’t used it myself but I know a person who does and loves it. iGPU handles Wayland stuff while the NVIDIA is there for the heavy lifting in Xorg.






  • 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.





  • 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.




  • 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.




  • It’s just their ego showing through.

    It basically now comes down to the current devs depending on new Rust devs for anything that interacts with Rust code.

    They could just work together with Rust devs to solve any issues (API for example).

    But their ego doesn’t allow for it. They want to do everything by themselves because that’s how it always was (up until now).

    Sure, you could say it’s more efficient to work on things alone for some people, and I’d agree here, but realistically that’s not going to matter because the most interactivity that exists (at the moment) between Rust and C in Linux is… the API. Something that they touch up on once in a while. Once it’s solid enough, they don’t have to touch it anymore at all.

    This is a completely new challenge that the Linux devs are facing now after a new language has been introduced. It was tried before, but now it’s been approved. The only person they should be mad at is Linus, not the Rust devs.