VB.net and C# essentially compile to same intermediate code, so for most applications there is no discernible performance difference.

However, VB.net lacks language facilities for "unsafe" code, which allows C# to use pointer manipulation and dereferencing for high-performance memory access.

Direct pointer manipulation and dereferencing are very useful features when you manually manipulate large arrays of data, such as pixels of an image. VB requires you to marshal such operations (essentially performing redundant copies of the data) to get the same access, which will slow things down.

If you mainly load your graphics from image files, then the loader and renderer already implement the high-performance logic so you don't have to worry about it.

Use VB.NET until you're coding and thinking "Oh golly! I wish I could use a plain damn pointer in here!".

So if I understand correctly, I am safe to continue with VB.net for my MUDs, but should think about C# if I plan to add pixel-based movement? Most of the graphics in the game i'm working on currently are static images loaded from a file, with only a couple exceptions to some menu stuff that is animated.

Don't worry about it, VB.Net is fast, modern PCs are fast(and by the time you actually release something they will be even faster), pixel based movement and animation is computationally trivial and if you need to do some really heavy data mangling there is most likely a highly optimized low level library available that does it for you regardless of what language you use.

Unless you have a very good reason performance should be the last thing you consider when you choose a language, your primary concern should be platform support(The language you use must work well enough on your target platforms) and after that you should look at things that enhance your productivity (language features, tools, libraries, etc), performance is only a concern if your language makes it difficult to reach your performance targets (and you are almost guaranteed to run into a situation where your chosen language makes it slightly difficult to reach your performance target long before it makes it anywhere near impossible).

I would still recommend looking at C# though but not because it will make your applications magically faster (it won't) and not because it lets you write unsafe code to squeeze a bit of extra performance out(if you need to write alot of unsafe code you might aswell use a low level language) but because it is a very nice language to work with and it has a huge community and tons of great tools.

VB.Net shares the same compiler/JIT/Runtime technology as C#, and they've had a decree of maintaining feature-parity for awhile now. You can basically think of them as two dialects that speak differently but otherwise have the identical capacity for communicating powerfully. C# is neither faster, nor slower than VB.net in mainstream terms -- I suppose its possible that the patterns one or the other encourages might be marginally slower or faster in specific cases, but you should mostly be free to defy those patterns. I don't hesitate at all to say that, between the two, use what's most comfortable because neither has a clear performance or expressive advantage. I happen to think that C# is the better language, myself, and probably a significant majority would agree, but that's no good reason to dump VB.net if you're already familiar with it.

That said, there are ecosystem differences -- as I said, most people seem to prefer C# by a significant margin, and so its easier to find people to help you out if you're writing your code in C#. Likewise, there tend to be more tutorials and references written in C#, and also some of the VB.Net code you'll find are straight-line ports of the C# version, which may not yield idiomatic VB.net. Moreover, most .net libraries are written in C#, so you'll eventually want to be comfortable at least reading it. All of those things combined tend to mean that any VB.net programmer who sticks with programming long enough eventually will also pick up C# (except, perhaps, those whose job is solely to maintain large, legacy VB code bases, as sometimes exist in enterprises).

If you were new, and asking the question "Should I learn C# or VB.Net" I would hands-down recommend C#, but since you are coming already with VB.Net experience, there's no need for you to drop what you're doing now to take a break and learn C# before returning to your project. You will probably (want to) come to learn C# before long, and that's a good thing, but let that come to you as you need it is my advice, unless you are simply itching to learn a new language, or are finding that not knowing C# is holding you back right now.

I honestly don't think that many developers actually use the C# unsafe functionality provided by

https://msdn.microsoft.com/en-us/library/chfa2zb8.aspx

and

https://msdn.microsoft.com/en-us/library/ct597kb0.aspx

I find that most hobby developers use C# because products like Unity (or traditionally XNA) provide their APIs using these languages. Unity in particular does not allow the unsafe facilities of C# anyway for certain platforms like the WebPlayer exporter.

If you need pointer access (and many hobby / indie games probably don't) then calling a native C/C++ library from C#/VB.NET is usually the more popular choice.

So really, C# and VB.NET are pretty much interchangeable by most .NET developers and their limitations are pretty similar so whichever syntax you prefer is probably a good enough choice. C# is more popular however so there are perhaps more code examples around the internet if you need them.

That said... I really like C++/clr since I can write in something very similar to C# and thus get the safety of a 100% managed language but then seamlessly utilize native C/C++ code directly without swapping between languages or loading in external libraries. I wish Microsoft would port that compiler to platforms I actually use though :'(