So, Switch emulation already shows some impressive in-game footage, even if it's still very experimental and broken oc.
Thanks god there's no closed source aberration this time (or I'm not aware of it).
There's Yuzu and Ryujinx, I wondered what are the big differences between these two ? They don't pursue the same goal, isn't it ?
From what I understand, Yuzu is based on Citra, which is written in C++, and Ryujinx is a brand new emulator written in C#. It's also good to see that some devs contributes to both projects.
If I am correctly, yuzu is more concerned with accuracy and has an interface. Knowing Citra, yuzu should be the superior choice.
I don't know much more. It is interesting but as of now it is not much of use for me until I purchase my Nintendo Switch. Most likely I think I would purchase one next year when there should be a solid library of games available for it (hopefully?). Too much else to do for now. I would hate it to purchase a Nintendo Switch and store it on the attic to collect dust a month later because I ran out of games. I already own The Legend of Zelda: Breath of the Wild, Donkey Kong Country: Tropical Freeze and Mario Kart 8 for my Wii U and only Super Mario Odyssey seems interesting currently. Sooo...
Nevertheless, from what I have seen and heard from footage of yuzu, I am impressed. The speed it is evolving with is just insane. Do these developers not sleep at all?
C# is my favourite language for most situations, but I wouldn't have thought it would be a good fit for a modern console emulator. You can just about get native assembly to work, but by the time you're doing that, it's probably better to be writing that chunk in C++ and use C# for the higher level stuff.
Well, only time will show which one ends being better, but as of now, my bet is on yuzu simply because it's coded in C++. I have some prejudice over compile-to-bytecode languages like Java and C# because while they generally are easier to use and to develop multi-OS programs, they tend to have a bigger overhead than "native" languages like C/C++, on a high performance requirement scenario like writing an emulator, I can't see those bytecode-languages going much further without needing way higher system requirements than they would need if they were just coded in a native language instead...
I was gonna mention that I can't imagine a C# emulator of a modern system being anywhere near fast enough. Also C# reminds me of Java a lot, and it's best to stay away from that when at all possible.
As a Java developer (Android), I love C#, it's basically "better Java" in many ways. I did not had the occasion to test Kotlin yet, but it seems that way too.
While it's true C++ outperforms C# in most benchmark tests, I think it's not necessary a bad idea for an emulator. There's a visible performance gap of course, but I think we can still get decent results.
Bytecode languages tend to do quite well (sometimes beating native code) when things can be vectorised or otherwise make use of non-ubiquitous ISA extensions as they're optimised for what's there at runtime. In other situations, like most application software, the speed difference won't be noticed. In performance intensive things, though, it's a case of weighing up whether a well-optimised implementation in an easy language will beat a less well-optimised version in a harder, but faster language. If you're on a tight development schedule, gaining extra time to improve things by saving time while making the first attempt can pay off.
As for Java vs C# vs C++, these days, I'd go for C# if I had the choice between any of them, and C++ if C# wasn't an option. A huge number of the bonus extras that C# can do and Java can't are things C++ can do too, and now smart pointers are fairly standard, I'd rather deal with the odd bit of memory management than repeatedly realise I'd forgotten how to do something in Java, then google how to do it and discover that it's simply not possible. There are loads of things which when I was mostly writing Java I found out it couldn't do, but there'd always be a helpful StackOverflow user explaining how it would actually be more harm than good, but since learning C#, I've discovered that it can do most of those things with no caveats or gotchas. My brother's actually trying to learn C# as he didn't get an internship because they wanted either C# or C++ experience, but he's only been taught Java. I've set him a project which I know from experience is a massive nuisance in Java, but easier in C#, and there are loads of things that I have to ask him why he's done weirdly, and it's always because of some feature I forgot Java didn't have, so didn't realise I needed to tell him about.
All that said, if someone were to look through my GitHub activity, it would look like my favourites were C++, GLSL and Python, as the biggest things I've done recently are OpenMW's shadows (which aren't quite finished yet) and revamping Mod Organizer's Python plugin interface so it wasn't useless.
I am feeling pretty lonely here with my love for HTML, JavaScript and PHP. I occasionally refer myself to Java. Last time I used C++ had to be years ago during my studying. And to be honest, I didn't attempted C# yet.
Well... I am more of a fan of Java anyway than going in the C direction. My GitHub page is just filled with JavaScript mostly... Which is just... Well...
[color=#000080]During my studies, I did Basic, Maple (well, you can forget that one), Python, C++, Java, PHP and JS.
Well, I really more C++ than everything else. I've had an Web programming overdose already and I hate JS being soooo permissive, it is a pain sometimes to debug when the result is a complete mess because of an operation normally not permitted...
Python is great to learn, but not that much powerful as C++. Java misses a lot from C++ I think... That's what I'm curious about C# that I've never tested at the moment...[/color]
Is there anything stopping grumpy web programmers from programming in something like TypeScript and then compiling it to JavaScript and handing that to their bosses? I was under the impression that it could be done in such a way that you can't tell the JavaScript is autogenerated.