I'm waiting for a new version. I wonder what exciting changes you made!

One version on my computer segfaults each time I enter it, but the v0.1.6 one worked.

Finally tried out TS 0.3.0 today (on Windows 7)... It displays some blue rectangles. When I press enter twice I get to the animated testing environment with the music and everything, but then it crashes after a few seconds, showing Windows' "turbosphere.exe no longer works" dialog. The terminal that opens in the background also locks up, but doesn't seem to be showing any special error messages...

This is on a system that has an Intel Sandybridge 3000 GPU and also an NVidia GT540M (with latest drivers). Not entirely sure which one it used for the test, and if it's the cause of the crash.

This is on a system that has an Intel Sandybridge 3000 GPU and also an NVidia GT540M (with latest drivers). Not entirely sure which one it used for the test, and if it's the cause of the crash.

If you have a dedicated nVidia GPU, it would have used that.  The way Sandy Bridge is set up, the on-chip GPU is automatically disabled if you have a dedicated graphics card, they can't be used at the same time.  I don't remember if they changed that with Ivy Bridge...

Well, that's not a great sign, particularly since I've been working on something all new for the graphics plugin (that I probably won't actually end up using!).

You can try commenting out the fn.drawTextBox, that used to (still does?) have some problems on Windows, and usually does not cause immediate crashes, but crashes after a few seconds. I've actually fixed a couple of possible issues with it in what will become 0.3.1.

It does kind of make me wonder that you are getting an OpenGL 4 context, too. I've never tested that, although I expect that if TS 0.3.0 works in the slightest that's not the issue--it would crash pretty much at startup.


In other news, I may or may not end up using it, but I've written a new version of the graphics plugin that runs the software drawing routines in a separate thread. It runs pretty much identically fast as the non-threaded version most of the time, but when I added the functions to draw Majestic 2D maps (and didn't call any functions that would force the thread to finish operations for until it was already done), it removed the lag to do the internal blits completely (about 200ms--though that was a very low stress test).

I've got it prioritizing drawing operations for when a surface is properly needed (such as a blit tot he screen or a call to getPixel), correctly walking operation dependencies, and varying the CPU time ceded based on how many operations remain to do (so that it doesn't burn up my dual core, mostly). I'm surprised how easy it was to do it, but I must admit I worry about an increase in complex and hard to diagnose bugs it would introduce--I've already been a bit stumped by a crash it causes in the Nvidia glx core, although the crash is very deterministic--I need to find out what exactly is causing it.

This is on a system that has an Intel Sandybridge 3000 GPU and also an NVidia GT540M (with latest drivers). Not entirely sure which one it used for the test, and if it's the cause of the crash.

If you have a dedicated nVidia GPU, it would have used that.  The way Sandy Bridge is set up, the on-chip GPU is automatically disabled if you have a dedicated graphics card, they can't be used at the same time.  I don't remember if they changed that with Ivy Bridge...

Well, no... Both run, the display output goes through the Intel GPU, and NVidia's output is actually passed to that. The laptop can switch between which GPU to use for every piece of software I run. It's an option in the software, even. NVidia calls this Optimus technology.

The only issue is, I updated my drivers yesterday, and ever since then the option "run with GPU..." has disappeared from my right-click context menu. I think it was running through the NVidia GPU since I set that one as the default one to use, but I didn't know if that setting was still the same after the update. That's why I said "not sure". (Note: it was still set to use the NVidia graphics.)

I'll play around with the graphics settings for a bit.

EDIT: whelp! It crashes, regardless of whether I set the preferred GPU to NVidia or integrated graphics.

FJ, try the attached test. For me, the following happens:

I see the text and press on a key.
I press 1.
It crashes.

Maybe it has issues loading some image formats? Since that's the only difference in the screens once you press 1, 2 or 3... In any case, it doesn't seem very graphic driver related since it crashes with both the Intel and NVidia card. (Though it hangs for a second before it crashes on the NVidia one while it's instant on the Intel one.)

On another note, TS crashes if I drag game.sgm onto the executable. I need to make it a startup game before it will run.

@DaVince
That's weird, I seem to remember reading that you couldn't use the SB GPU at all if you had dedicated graphics hardware, unless you disabled the latter in BIOS.  Maybe I misread and that only applies to the QuickSync feature (HW accelerated video transcoding).  Now you have me curious, I'll have to go look it up again...

Well, I have a notebook. It seems nonsensical to me to have discrete graphics AND dedicated graphics when one is specifically intended to save on battery and the other one is specifically intended for when you need the GPU power. Although you *can* disable the discrete graphics in the BIOS if it supports it (mine doesn't).

Also, I've successfully been selecting and switching between which GPU to use for what software. But in TS's case, it doesn't seem to run on either.

Huh, just looked it up and there are conflicting reports; apparently it depends on the motherboard.  Some will disable the Intel graphics when a card is plugged in, others will even allow them to work simultaneously, i.e. for multi-monitors.  Good to know!

On another note, TS crashes if I drag game.sgm onto the executable. I need to make it a startup game before it will run.

I designed it to work with the editor--I didn't realize Sphere took the SGM. TurboSphere takes a directory, which is what the old editor passes the engine. I can easily add the ability to start with an SGM as well, though.

That test you posted doesn't segfault on Linux--GetSystemWindowStyle has been known to crash on Windows. But on Linux, it works, and there's another issue with WindowStyle.drawWindow that I'll take a look at. It complains that argument 2 is not an integer...which it is. Very interesting. EDIT: Fixed that issue.

Also, you are using LoadImage. That is not defined by default in TurboSphere--the image objects are properly undefined in your script. LoadImage has been replaced with new Image()--same thing with all the other Sphere objects, too.

Did you try removing the drawTextBox from the Jest_Main.js script in the included test game? I doubt it is the GPU, I've actually tested 0.3.0 with an AMD integrated GPU, and the only strange thing was that the affine transformations went form opposite corners--which will, whether it is properly a bug or not, be fixed in 0.3.1. And I've removed all the stuff that used to cause the problem of only NVidia and theoretically certain ATI cards being able to run TS.

You can try running the...performance monitor? It's something in the 'computer--*right click*->manage' menu, and you can see what processes run on what GPU--I can see which of my SLI cards runs TurboSphere from it.

A lot of these crashes seem to be things that happen more often or only in Windows. Which is not unexpected, I rarely use Windows, and so I don't debug on it very often. I'll need to have a look in Windows to get a lot of this sorted out.

Well, I wanted to get 0.3.1 out a while ago. But Visual Studio 2010 is horrendously broken on my Windows machine. It can't even uninstall itself, after a couple minutes of trying a dialog pops up that simply says 'The operation cannot be completed', same as if I try to run VCexpress. If I try and invoke it from the command line, it's like half of its standard library is simply gone. I then tried to use MSVC 2008, just in the interest of getting the code compiled at all. But that hit the snag that V8 can no longer be compiled with it, and unlike before with the Scons file for V8 you can't compile V8 without having a fully operational Visual Studio--unless you have the professional version which contains the tools to compile an sln file from the command line.

So I managed to get V8 3.19 compiled with MingW (which wasn't too bad, actually) using a friend's machine (which has MingW working, I can never seem to get it running right), ran DLLtool on it to get an MSVC compatible .lib file.

Then I learned that whatever is breaking my MSVC 2010's standard library is doing the same to 2008 (a little, anyway). I no longer have (or somehow can't use) the header files that contain the functions I need for the plugin interface or to compile T5 on Windows! And neither the 2008 or 2010 installer seems to be able to repair this.

So I guess I'll give in and also install MSVC 2012--if it can install on my machine. This is a good example of why I rarely make binary releases for Windows.

Honestly, you have got to be prodding with the wrong sticks to screw up a MSVC install. I could try installing it with my vs2012 if you want. I just need to know the steps: a 'compilers guide'.

BTW, how much of the engine do you have finished?

I don't think it is MSVC that properly broke, I think it has something to do with .NET (although I can't explain the missing or broken header files that way). This started happening after I had to re-install .NET for a game.

The 'compilers guide' is pretty simple--but I need to upload the source for 0.3.1 first (I can get on that tomorrow, the internet is too slow where I am now to do so), the GitHub source contains most but not all the changes so far.

1. Compile V8 using their instructions (I include instructions for downloading it using SVN, just be sure the branch is 3.19) and put the headers in the TurboSphere root. The command to get the right version is

Code: [Select]

svn checkout http://v8.googlecode.com/svn/branches/3.19 v8

2. Get SDL2, SDL2_image, and SDL2_ttf. Put the headers for all three in a folder called 'SDL' at the TurboSphere root.
3. Get Bass and BassMidi, put the headers in the 'plugins/audioBASS/include' directory.
4. Using the MSVC command prompt, enter

Code: [Select]

scons --install_libs=y --build_plugins=all buildplugins libinstall

All libraries, DLL and LIB files, go in the TurboSphere root directory. Bear in mind this might not work right out of the gate, I haven't tested the source for 0.3.1 on Windows yet.

As far as how much is finished, without going through everything and finding hard numbers:

Graphics: 80%
Audio: 80%
File I/O: 50%
WindowStyles: 90%
BMPFonts: 80%
TTFFonts: 70%
Map Engine: 5%

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. That includes time spent making test cases for the API as-I-go. These tests are simple and pretty much just run to make sure I have 2 things:

1. The item has been implemented. ie: I'm not missing something small. When say, 'fonts' are 100% done I mean they are 100% done. But not necessarily 100% tested.
2. For some items, to test if the item works. I could not possibly do this for everything. But for some things I just do basic get/set tests and sanity checks. Most common one: does toString() return "[object correct_name_here]"? Why I care about that above so many other things I can't really say...

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. I think C# is way easier to read (and write, I mean header files? Come on!) than C++, but then again it may just be due to the fact I spend so much time in it.

If Jurassic were mono-compatible... Ah that'd be the day. It's not too far off. It's just missing a single feature that the mono team hasn't implemented yet. It's really not an OS limitation but a mono-implementation one. <sigh>.

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

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.