Well i never got really deep into Visual C#, but the lack of auto-indenting and other little things made me cry. Especially on the C# classes, i was like “LET ME USE SOMETHING ELSE PLEEEEEASEEEEE”
It’s a matter of taste, actually; Some people hate Eclipse for being slow and bloated.
And the last line of my previous post was obviously a joke 
VS has a nice debugger. As an editor, it’s badly stripped. And don’t get me started on build configurations.
It’s really hard to compare Eclipse and VS, primarily because the experience using them is vastly different depending on what language you’re using. ‘Eclipse’ usually just means Eclipse for java dev, which is pretty damn slick. Eclipse for C++ is a whole other beast.
Similarly for VS. The VS C++ debugger is great, but the VS C++ code editor is abysmal. It’s clunky to navigate, it’s code completion and syntax highlighting is often flat out wrong, and it has an annoying tenancy to lock up the whole app when it scans the code. Everyone ends up resorting to something like Visual Assist to make it usable. VS C# on the other hand is a completely different beast - the editor is much more functional, but the debugger is IMHO worse (and worse than Eclipse’s Java debugger).
Of course like most MS tools it also really depends on what the rest of your environment looks like. VS is great if you’re living and breathing the MS stack all day, but will kick and fight if you ever try and use it in a different way or with different tools. Eclipse, Netbeans, etc. are much more comfortable in letting you integrate different tools and plugins. So even comparing the two versions with relevant languages, your experience varies hugely depending on what other stuff you’re doing.
TL;DR version: saying “Eclipse sucks, VS is much better” (or the reverse) is a nearly worthless statement unless you also qualify what languages, toolset, environment, source control, app and functionality you’re developing with/in.
Alright, but now I have a really serious question for you.
When you create a new game - will it be Java or will it be directly done in the other languages to get your broader platform support without having to do porting work first? Seems to me that continuing to use Java for PC stuff at this point in time will just be extra maintenance that is not necessary 
It will be Java, because that’s what I’m good at and it gives me all 3 platforms that make me enough money to live on (Win, Mac, Lin). I’m totally disinterested in console development because of the daft hoops you need to jump through not to mention the incredible expense. And designing a game that works on touch platforms that is also going to work on the desktop is just laughable.
Cas 
I think one way to approach mobile for someone like PuppyGames would be to create companion apps/games for your desktop games. I’m not sure how exactly that would fit into your current line-up, but i’ve seen a few big fish doing that recently. If your games had some kind of persistent state to them, say inventory, an avatar, etc., a companion app could offer you managment facilities for that. Alternatively, if your main game has some kind of in-app currency, you could have a small mini-game mobile app that allows you to earn a bit of that on the go. When you return to your game on the desktop, your freshly earned currency is ready to be spent (or you do it in the mobile app :D).
Yeah, we’ve genuinely looked into ideas along those lines. But of course then we’re basically writing completely different software for phones so my general premise still stands - you don’t write desktop games and port them to touch - if you’ve managed to port it then you’ve probably got a game that simply won’t sell on the other platform type.
The only game we’ve got that will work, even vaguely, on a phone is Titan Attacks. For bonus points someone can try and say why the other games won’t work.
Cas
Ya, i don’t think that you can simply take a desktop/phone game and port it to the other platform. Tablets are a different story though, some genres work on both tablets and the desktop.
Looking forward to see how well Mono/MonoGame perform on all those target platforms.
I’m not very sure that tablets are a different story really. The problem is fourfold: touch, form factor, performance, and expectations/situation. Touch is the same problem on both phones and tablets - it’s surprisingly different from mouse and of course totally different to a game that uses keys as well to good effect. Form factor again radically changes the nature of a touch interface. Then there’s the crappy (relative) performance of these devices and finally there’s the situation and expectations that users have when using the device. Mostly it seems that people gaming on touch devices are extremely casual. Getting their attention for any length of time is hard.
Cas
I do tend to wonder about the level of “immersion” you can expect from a game on a 10" screen where the player’s own hand is constantly popping into view.
No immersion at all.
Have a close look at the games that are succeeding. Very interesting.
Cas
Mono is nice but it is noticeably different of Microsoft .NET implementation, it is very well explained in this article (still true now):
http://codebetter.com/patricksmacchia/2009/01/19/mono-vs-net-framework-public-api-compatibility/
C# bindings for the OpenGL API are really slower than JOGL 2.0 and LWJGL, Microsoft .NET itself has never been faster than Java, that’s why Quake .NET is 15% slower than the original version whereas Jake 2 is faster. I understand that some people need to use C# on some platforms that doesn’t support Java yet but C# is not Java, OpenJDK is extremely close to Oracle Java and anyway Normen has tried to make JMonkeyEngine 3.0 work on iOS with AvianVM and JOGL ;D Java can go everywhere with some small efforts.
hmm “small efforts”… fine if you have infinite time, money and patience, are very clever, and know what you’re doing. I have none of these attributes.
Cas
That link is nearly 4 years old - go start a new thread if you want to argue the merits of each language / IDE / Framework, eh? 
Anyway, here’s some WIP screens in various states of brokeness…
Looks like a pretty cool process.
Just curious, did you ever consider using some of the existing solutions for Java to C# conversion ? like using IKVM and just implementing a LWJGL clone in .NET.
Also how are you handling platforms that don’t have OpenGL, some sort of OGL->DX converter (like Angle)? or some other method?
Do you plan to release a general conversion tool so other can use it? (whether commercial or free).
You know there have been a few successful attempts of running Java on iOS, it’s not pure science fiction.
Ok but there is a difference between whining about who stole what from whom and just asking people to respect the right of paternity.
It would be fine to have a nice tool chain to do that easily, it would allow to go on coding in Java while targeting platforms supporting C#.
Cheers - been a bunch of hard work but ultimately satisfying when you get the game running. I looked at IKVM way back in the day but found it wasn’t going to work for some reason (probably the closed nature of consoles but I forget now). If you want XBox then it’s got to be XNA Game Studio (or pain of XBLA) and if you have XNA you may as well go MonoGame for the other targets.
I’ve delegated the few OpenGL calls that Cas uses to Direct X - it’s a custom solution and while it’s pretty basic it works well enough. Not sure what the plans are to be honest. I doubt there would be any value in it for others unless you were using the entire Puppy tool chain. But there’s no reason the various libs couldn’t be bunged on Github or whatever.
Back when I looked into it, IKVM required the full CLR runtime, whereas to get on XBox you were restricted to the Compact Runtime. So you can use IKVM to get something working with XNA, but it’ll only work on desktop, not XBox (which is kinda the point).
…and here’s a little YouTube of it in action…
d7eGZmGPw84
What’s that running on?
Cas
