1
point
markjgx
Joined 112 karma
- "Surfer: The World's First Digital Footprint Exporter" is dubious—it's clearly not the first. Kicking off with such a bold claim while only supporting seven major platforms? A scraper like this is only valuable if it has hundreds of integrations; the more niche, the better. The idea is great, but this needs a lot more time in the oven.
I would prefer a cli tool with partial gather support. Something that I could easily setup to run on a cheap instance somewhere and have it scrape all my data continuously at set intervals, and then give me the data in the most readable format possible through an easy access path. I've been thinking of making something like that, but with https://github.com/microsoft/graphrag at the center of it. A continuously rebuilt GraphRAG of all your data.
- Some players will also be convinced that you're cheating if you play the game really really well, and they will get upset. CS:GO (now CS2) has a very fascinating way of determining if someone is cheating. A ML based heuristic that is constantly being retrained, that can accurately judge whether someone is actually cheating or not based off their Overwatch (not the game) replay system. https://www.youtube.com/watch?v=kTiP0zKF9bc
- > Managing build configurations...
In terms of package management, you can apply rules to what crates you want to include; including specific platform constraints.
On the code side it's pretty much the same as C++. You have a module that defines an interface and per-platform implementations that are included depending on a "configuration conditional check" #[cfg(target_os = "linux")] macro.[target.'cfg(target_os = "linux")'.dependencies] nix = "0.5"https://github.com/tokio-rs/mio/blob/c6b5f13adf67483d927b176...
- Glad this was flagged. A lot of people have a misconception of managed languages being slow compared to your regular ol' binary program, these days that couldn't be further from the truth. In traditional high performance C/C++ development you have to manually split your code into hot and cold paths, static analysis optimization can only go so far.
Do you want to inline this function in your loop? Yes and no, i.e. you might be taking up some valuable registers in your loop, increasing register pressure. Time to pull out the profiler and experiment, wasting your precious time.
Managed languages have the advantage of knowing the landscape of your program exactly, as __that__ additional level of managed overhead can help the VM automatically split your code into hot and cold paths, having access to the runtime heuristics of your program allows it to re-JIT your hot paths, inline certain functions on the fly, etc.
- "and it looks like they're finally improved on what was a terrible, clunky, extremely dated UI." doesn't hold true, it's mostly the same UI with a dark reskin. Certain editor hot paths have been reworked and that's about it. The editor is almost exclusively written in Slate, Epic's in-house Window framework/general GUI module. Slate's got a pretty interesting nested MACRO system. Most definitely not data-driven and pretty much as hard-coded as it gets, redesigning the editor for real would be difficult to say the least. In reality most experienced developers don't want a new design, they are happy with the workflow they have and I have to agree with them. I'm generally happy with the "if it ain't broke don't fix it" reskin decision.
- 1 point
- I started out by doing a raytracer, graphics programming is really rewarding. https://raytracing.github.io/books/RayTracingInOneWeekend.ht...
- 2 points
- 2 points
- Thanks. It's called BadLads, it's all about multiplayer roleplay, where each player has their own job. The games about to get giant procedural cities (with full interiors!) and native virtual reality support. Here's the last devblog, although a bit dated: https://devblog.chemicalheads.com/posts/upcoming-update-teas...
- I choose to irrationally support Linux, because I like Linux. There is literally no financial incentive for me to do so. We were recently debugging a newer build on Linux, which was inexplicitly crashing on a players machine, while running great in the testing environment. This was causing a major headache as the game needed to ship that day.
We had another Linux volunteer test it out on his mostly vanilla Ubuntu setup, and it worked great. Ended up creating a chart of all the available testing configurations, e.g. comparing drivers across all the available environments. The supposed blame ended up being a statically linked library on his system. Funny thing is the tester who was crashing was enjoying the game in Proton while I was debugging the Linux build.
- If you don't want to download every single frame you could feed these into DAIN (Depth-Aware Video Frame Interpolation) https://github.com/baowenbo/DAIN
- I like protonmail and consider it mostly a suitable replacement to gmail. I say mostly because some websites don't accept emails with the protonmail domain. Weird huh. My understanding is that protonmail might of been used by some bad actors and it's been labelled as the bad people email.
https://community.netlify.com/t/email-domain-protonmail-com-...
- 67 points
- 4 points
Coming from the game dev world, I’ve grown more and more convinced that managed languages are the right move for most code. My reasoning is simple: most game developers don’t have the time or patience to deeply understand allocation strategy, span usage, and memory access patterns, even though those are some of the most performance-critical and time-consuming parts of programming to get right.
Managed languages hide a lot of that complexity. Instead of explaining to someone, “you were supposed to use this specialized allocator for your array and make sure your functions were array-view compatible”—something that’s notoriously tedious to guarantee in game engines given how few developers even think about array views—you just let developers write code and most of those problems go away.
I’m not saying everything should be managed. Core engine code should still live in the predictable, statically compiled world. But history shows it can work: projects like Jak and Daxter were written primarily in a custom LISPy scripting language, and even Ryujinx (RIP), the excellent Nintendo Switch emulator, is written entirely in C#.
Another strong technical reason is that managed JIT languages can profile at runtime and keep optimizing call sites based on actual usage patterns. Normally, developers would have to do this by hand or rely on PGO, which works but is painful to set up.
Industry standards make this harder to adopt since platforms like Sony still block JIT, but I think this is the direction we should be moving.