@Radnen
Which feature is missing for Mono compatibility, out of curiosity?

System.Reflection.Emit.DynamicMethod dynamicMethod

Hmm, I don't want to sound rude, but my theory is correct, C#/Mono type languages do seem to make you more productive. I have more implemented than you for having put less time into it.

No, I totally agree. I knew there were easier ways to do this that would also get done faster. I chose C/C++ because of the promise of ultimate speed and efficiency. But I always knew the price was that it would take far more time and effort to achieve that.

My reasoning (that I still stand behind, in the long run) is that I should spend more time making the engine, since that extra effort will eventually be seen as higher performance and lower resource requirements.

But I have to say, the C++/SDL/v8 learning curve must have been tremendous! And you'll have a native cross platform app that may indeed be faster than mine when all is said and done. 0_0 What I hope to achieve at the very least is a standard to compare engines against. Perhaps not for speed or for cross-platform-ness, but at least as an implementation guide.

Yes, about the first six months of making TurboSphere were just teaching myself how to program in C++ (and relearn what little C I knew before)--and V8 was a jump into the deep end for C++!

I have no doubt that a C# based engine will be easier to make, in the early stages be far less buggy than a native-code engine, and be finished sooner. But I didn't (and still don't completely) trust C#, as a Microsoft language. I was burned when the old VB was killed off, I was burned when Delphi became what it is now. It's nothing against the languages--and it seems like C# is certainly here to stay. It just feels odd to me to write anything in .NET. But that is just a personal reservation.

But yeah, I have to agree with you here, C# is much better for productivity. I was practically raised on C++ but every time I try to go back now and write a native app I give up in disgust.  Mostly due to the unwieldy header file management you have to do, it's just unbelievably clunky to work with.

Mostly I feel this way about MSVC and .lib files, or exp or def...I'm not even sure why there are three choices! I wish it was like GCC with fully PIC and fully public symbols. And to be fair, there are many things I really wouldn't want to use C or C++ for.

But I didn't (and still don't completely) trust C#, as a Microsoft language. I was burned when the old VB was killed off, I was burned when Delphi became what it is now. It's nothing against the languages--and it seems like C# is certainly here to stay. It just feels odd to me to write anything in .NET. But that is just a personal reservation.

To be fair with this though, C# has one advantage that neither of those other two can claim: It's standardized by ECMA, just as JS is.  It's not going anywhere.  Given that standardization, it's very difficult to call it a "Microsoft language" with a straight face, any more than you can call Blu-ray a "Sony format".

But I didn't (and still don't completely) trust C#, as a Microsoft language. I was burned when the old VB was killed off, I was burned when Delphi became what it is now. It's nothing against the languages--and it seems like C# is certainly here to stay. It just feels odd to me to write anything in .NET. But that is just a personal reservation.

To be fair with this though, C# has one advantage that neither of those other two can claim: It's standardized by ECMA, just as JS is.  It's not going anywhere.  Given that standardization, it's very difficult to call it a "Microsoft language" with a straight face, any more than you can call Blu-ray a "Sony format".

Hence: Mono.

OK, the Git source has been updated!

I haven't seen any serious show stopping bugs associated with the threaded graphics plugin, so I've included it and set it to the default (although the old graphics plugin is still included). It is faster sometimes (especially if you script with it in mind), and I've never seen it be slower.

The SDL2 libraries need are at:

SDL2
SDL2_image
SDL2_ttf

The dev libraries for ttf and image should come with the dynamic library for freetype and the necessary format libraries, respectively.

I know C# has been standardized. That doesn't stop Microsoft (or anyone else, actually) from adding nonstandard extensions, even proprietary ones. And if Microsoft stopped supporting it (which seems less and less likely, granted) then there would be much less momentum for the language. I doubt it would die, but it may be a dark time.

At the same time, I think that Basic has also been standardized, and Delphi is (or was? I don't even know if it is still being developed or supported) a dialect of Pascal.

All that is just conjecture, and highly unlikely conjecture at that. That's not really why I don't use C#. I just don't prefer .NET. For things that are very unsuitable for native code I usually use Java because of how cross-platform it is.

For things that are very unsuitable for native code I usually use Java because of how cross-platform it is.

I agree with you there.

Will you have latest Windows binaries anytime soon?

Will you have latest Windows binaries anytime soon?

Maybe. I've installed  MSVC 2010 on a friend's computer, maybe tomorrow or this weekend I'll get it compiled.

Alright, I actually fixed MSVC (through a lot of reinstalling .NET and redistributables).

And I see what you mean by TurboSphere being very crashy. It's not like that in Linux, it's pretty stable there. Which is kind of to be expected, I've spent a long time using only Linux and it seems that I've written a lot of code that is less MSVC friendly than I thought.

I see a couple major things I need to solve before I can make a new release for Windows. Image loading is broken, it actually crashes during an SDL_image call (the main one, actually, IMG_Load()). Considering that it works like a charm on Linux, and SDL2 is still in the RC stage, that one might not be my fault. I'll keep trying to figure it out anyway.

Second, and I knew this would be an issue, the map engine (which primarily consists of map-related resource loading functions) relied on being strongly linked to the graphics plugin. That works great with GCC-style libraries, since I just load the graphics plugin first and its symbols are all available for any plugins loaded after it. Not so with MSVC.
That's not MSVC's fault, either though. I've been thinking of making this work nicer, by DLopening the functions I need (or LoadLibrary'ing, as the case may be). That would be a better solution anyway.

Image loading issue fixed. It was my fault, I needed to update libpng, libtif, and libjpeg (my code for loading SDL_image was flawed, it did not test if we got the loading libraries we asked for, only if an internal error had occurred in IMG_Init).

I am now seeing the same crash as DaVince did with 0.3.0 (which works fine for me, strangely). Now I'm just trying to get a proper debug build compiled, I've never properly had to do that with Scons before.

I've got it narrowed down a lot. I think it has to do with a bad matrix setup in OpenGL that is ignored by the NVidia OpenGL library, but causes problems with the Windows library.

But of course, there is a snag. My main dev machine, my laptop, is dying. I ordered the new hard drive it needs. Once I get that, I'll have to reinstall MSVC (which won't be nearly as bad as fixing a bad install!), and then I can be up and running again.

This is what I get for trusting six year old, frankensteined computers.

Well, I fixed my laptop with a new harddrive and shiny new Arch Linux. And lost my old windows disk.

I'm going to just continue developing in Linux until I get back to university at the end of the month, there I can use the internet on my desktop (which has Windows). It's exceedingly annoying to try and fix these problems with no internet--particularly since getting a new download of V8 alone will take several hours where I am now.

On the other hand, I'm working on making a binary distribution for Linux. I've managed to weed out a lot of dependencies from the libraries I use, and I think I can make a universal Linux binary set.

I've added the ability to point TurboSphere at an SGM instead of only a directory containing an SGM, and to change games while it is running. I've also added GetSystemTTFFont(), surface.triangle(), font.getImage(), and a lot more functions to access the map-related resources. I've also improved background surface operations (many more functions are now set up to operate in the background than before). Once I get Wine installed, I'll resume work on the map engine.

Fonts now use texture atlases for all drawing. I didn't do this before because it had little effect on my ancient NVidia laptop. But on my new AMD machine, it vastly improved performance of the test script. I'm excited to see how fast texture atlases plus texture caching in buffers will be!

Sweet, I'm happy you've added texture atlases.

Alright, I'll bite, this has been bugging me for a while... What exactly is a texture atlas?