Couldn't you just check if engine64.exe exists and run it if it does, otherwise just run engine.exe?

Oh, I see you want to detect if other engines can run in a 64bit version of windows? I'm not sure there. But as FJ said we can create a name scheme or I can simply add a new field and you can choose the 64bit version of the engine.

I might do that... But then there is a default engine (32bit version). I guess I can also make it choose a default engine at startup. Ugh, so many ways to handle it!

Don't worry guys, I already did it.   I used FJ's method, it just tries to run engine64 first.  If Process.Start throws an exception (meaning either engine64.exe doesn't exist or the machine isn't capable), it catches it and runs the 32-bit engine instead.

There's a separate text field in the Paths tab now for the 64-bit engine path.  Like with config.exe, it will be filled in automatically if engine64.exe exists.

System.Environment.Is64BitOperatingSystem was added in .NET 4.0: https://msdn.microsoft.com/en-us/library/system.environment.is64bitoperatingsystem(VS.100).aspx

System.Environment.Is64BitOperatingSystem was added in .NET 4.0: https://msdn.microsoft.com/en-us/library/system.environment.is64bitoperatingsystem(VS.100).aspx

Oh, ha, I didn't realize that, thanks!

I've discovered an problem with the version on Dropbox.

* Create a new spriteset
* Add a new image
* Select it for one of the frames
* Delete the image

You get an OOB warning dialog, and more importantly you can't seem to recover the spriteset. It just has a red X/image missing icon on the frame until you close the sprite editor.

Not updating the image indices/references when an image is deleted? =)

Hm, I can't seem to reproduce this with the latest build from GitHub.  It replaces the frame with a valid image (specifically the first one).  Maybe it's been fixed since then...

@Radnen: I sent another PR for the 64-bit engine support, this time I did it on top of your changes so there should be no ugly merge conflicts.

Feature request: Ability to create folders at top-level directly in the IDE.  Because currently, a right-click on the project node only gives you global options (Game settings, Editor settings, Open in Explorer).  I'd do it myself, but I hate working with GUI code if I can avoid it.

Added, and your changes merged in well enough.

That was quick!  Now I'm working on updating IrrKlang to 1.5.  They have a 64-bit build now!  Too bad it's not in NuGet...

Part of the dependency reorganization was to try and utilize NuGet better so there's less stuff to download/require for any future code editors. And to possibly aid in plugin creation, I mean I removed the strict dependency from Weifen Luo. This also means, going forward, we don't have to use the dockform suite if a better alternative shows up. The plugin's don't care, just the editor needs the overhaul and a remapping from the plugin dock styles wrapper to the actual dock styles.

I want to do so much to this editor, but I've just been busy with work and playing awesome games like the Witcher III. And watching tons of TV shows and movies to get caught up on. And I've even been taking the time to work on a novel, adding programming to that is a bit too much for a single week.

Okay, that idea isn't going to work (updating IrrKlang).  I can't figure out a way to include both the 32-bit and 64-bit DLLs in the same project and get VS to automatically reference the right one when compiling.  In a C/C++ project this is easy, just change the library path, but the .NET languages use the braindead References system instead.  The only workaround I can think of is to create separate project files for the 64-bit build, but with all the plugins that would be a mess.

Okay, that idea isn't going to work (updating IrrKlang).  I can't figure out a way to include both the 32-bit and 64-bit DLLs in the same project and get VS to automatically reference the right one when compiling.  In a C/C++ project this is easy, just change the library path, but the .NET languages use the braindead References system instead.  The only workaround I can think of is to create separate project files for the 64-bit build, but with all the plugins that would be a mess.

I haven't used VS > 2013, and never for managed builds, but...

Couldn't you have single projects for each plugin, then two solutions for the editor, one for 32-bits and one for 64-bits, each sharing the projects for the plugins? It's kind of inverting how projects/solutions are supposed to be used, but if it works.

I'm also curious, how important is 32-bit for this project? I'm not saying 32-bit is bad or anything, just wondering.

The problem is assembly references are tracked per-project (not per configuration) and VS only lets you add one reference with a given name.  If you then try to compile for a architecture not matching that one reference, you get errors.  Making a second solution isn't enough--you need separate .csproj files as well.  On the plus side, it's only the one plugin (sound picker) that would need this treatment, but I don't feel like being the one responsible for making a mess.

As for that last question, if it were me I would probably opt to go 64-bit only for the editor.  But it's not my project, so I can't make that decision myself.  I'm only an elected official a contributing developer after all!

I wouldn't mind going 64 bit but there are libraries that don't support it. I'm not sure which, but perhaps it was the dock suite? I know scintilla has the same issue with 64 vs 32 bit build, but I think for that one AFAIK you just include the base 64/32 bit DLL and the linked/referenced one I think is set as multi-target. In fact, does the multi-target build option make things worse or do you still run into the issues?

I'm also surprised you can';t set different references per build type.

I choose 32bit since it was the most compatible against most computers.

Edit:
I looked into it and people are saying you either hack it into the .csproj or you simply create multiple projects. But doesn't VS allow you to create a shallow clone of the project? I know I did this when I was playing around with XNA to target the PC or Xbox. The Xbox project was basically a shallow copy of the main project. If I modified the main code it'll use the new version, so nothing is copied twice. All it did was use a new reference list and build architecture, and XNA API mode was set to a compatible version just for Xbox/Devices. But the code was the same. If I wanted xbox specific code I'd use #if directives.