3 ms·
I wouldn't have guessed C# would be a good fit for something like this, but neat to see!
by seabrookmx 3y ago
I wouldn't have guessed C# would be a good fit for something like this, but neat to see!
- lnxg33k1 3y agoOh, in terms of emulators written in C#, never heard of Run[1]UO[2]? C# revolutionized the UO world back like 20 years ago(?) it has(d?) the right balance between simplicity, clarity and performance [1] https://www.runuo.net/ https://www.runuo.net/ [2] https://github.com/ClassicUO/ClassicUO https://github.com/ClassicUO/ClassicUO Shit shouldn't have thought about UO, now I am sad :'( (and old)
- wiz21c 3y agoIn the future there's fire, in the past there is gold :-)
- mentos 3y agoRunUO is what turned me from a player into a programmer. I believe there’s still a forum comment out there from 2001 where I was asking about the mess of squiggly brackets {} and if this is really how programming is done. It’s a really fun reminder of what that first exposure to programming felt like. I’ll never forget how magical it was to make my first edits to the code and see it reflected in the game. Created a feedback loop that has continued to reward me over 20 years later. :)
- lnxg33k1 3y agoYeah what did that for me was mIRC scripts, kinda miss every now and then the feeling ^^
- deaddodo 3y agoC# is a common choice for emulators, actually. It probably goes C/C++ (it's really hard to disambiguate the two, in this case; few codebases are pure either way) then Rust (for hobby emulators, it's probably third or fourth for serious efforts), C# and Java. JavaScript and Python are very common for hobby efforts, but generally exceptions for serious codebases (excepting WASM).
- hx8 3y agoBizHawk is a premier emulator for generating Tool Assisted Speedruns and written in C#. https://github.com/TASEmulators/BizHawk https://github.com/TASEmulators/BizHawk
- minimaul 3y agoBizHawk is basically a wrapper for other emulators, though. Essentially a fancy frontend.
- lbussell 3y agoI believe Ryujinx actually translates the ARM code to .NET IL, which is then JIT compiled to machine code by .NET. As far as I know it’s a pretty innovative approach to emulation! And on Apple Silicon, it just runs the Switch’s Arm64v8 instructions natively using a hypervisor! [1] [1] https://blog.ryujinx.org/the-impossible-port-macos/ https://blog.ryujinx.org/the-impossible-port-macos/
- josephg 3y agoI wonder if wasm would be another good target for this sort of thing in the future.
- averne_ 3y agoThis isn't true anymore. It was their first approach, but since then they have switched to their own JIT recompiler. You can read their rationale here: https://github.com/Ryujinx/Ryujinx/pull/693 https://github.com/Ryujinx/Ryujinx/pull/693 For the MacOS port, they also added an ARM-to-ARM JIT in case hypervisor runs into issues.
- whizzter 3y agoI think that first approach (Part of the name RyujinX from RyuJIT?) while not optimal did get them off the ground quickly, now with a bit of traction (people into the project since it actually functions) they can could easily find takers(or the time) to write the improved JIT. I'm actually tinkering on a WASM runtime and emitting MSIL code from WASM trees is quite straightforward so far (tho running into some more complicated cases now that I'm integrating the test-suite), compared to the non-trivial (code stamping) pure native JIT's I've done in the past it's quite a big timesaver (and those still only did target one CPU platform).
- steelframe 3y ago> they have switched to their own JIT recompiler ... they also added an ARM-to-ARM JIT in case hypervisor runs into issues Having worked in industry for some multiple of decades, I can say with some confidence that if a small team were to successfully build and deploy their own JIT recompiler to solve an actual customer problem, they would be considered gods by management and given bonuses and promotions. Realistically the project would never get off the ground because their management would be pressuring them to hurry up and add some random new API within the next quarter. Most devs just looking at the existing code and are more or less doing a copy-and-paste with some minor tweaks for their new "feature." They're trying to slap together quick demos that are little more than, "And now this thing makes an RPC call to that thing." The level of performance I see from people who pull down well into 6 figures of income typically falls well below the level that I'm seeing in this Switch emulator project. Usually for something like that to actually happen it takes a VP mobilizing an org of size 20+, with multiple layers of management taking a year or more to hire or steal talent from other orgs. Some companies are built differently (i.e., Apple) and can pull cross-org talent together for something like "get Intel binaries running pretty well on M1." But I find that tends to be the exception rather than the norm for larger tech companies. Maybe I'm just working in the wrong places.
- meibo 3y agoC#, especially with in recent releases, has really been turning into somewhat of a systems programming language. They keep adding tools that allow for very low-level memory management/manipulation and the ability to run on so many platforms/generate native code makes it very attractive. It's also just fun to write.
- Zuiii 3y ago> They keep adding tools that allow for very low-level memory management/manipulation and the ability to run on so many platforms/generate native code makes it very attractive. It's also just fun to write. I've been having issues with golang's opaque GC when targeting wasm. Does C# offer anything on that front? Can I at least control when it triggers?
- meibo 3y agoYou can pause the GC, run it yourself and tweak it a bunch, but in my experience it usually causes more trouble than it's worth - you have to be really careful with it.