I'll just put this here.

If you're curious what happened to the missing versions between 0.3.1 and 0.3.5, they were released silently as source on github, and only worked (reliably) on Linux.

Nifty Things Realistically Planned for TurboSphere, Version 0.3.6:

Fat Binary Plugins. C# editor plugins and C/C++ TurboSphere plugins, and for your convenience, all in the same DLL. I think I now know how to do this.

Separate all the threadable surface functions into surface-thread operations. The only non-threadable surface functions I can think of are converting to an image, saving, and blitting (another kind of converting to image).

A C#-based proof-of-concept plugin.

A FLTK- (or Phoenix-...we'll see what happens) based graphical configuration utility. It can already read what functions and variables a plugin contains for use script.

Tung's startup game will function correctly!

Testers Needed!

I present you with a still slightly buggy version of TurboSphere for Windows. Get it at http://flyingjesterentertainment.webs.com/ts-0.3.5a.zip.

All those promises in the post above are not in this build (except for partially the last one). I need to just stabilize things on Windows first.

It needs a lot of testing. Like, a lot. The included test game shows two problems currently. The first is that the surface worker thread never enters independent mode, so it doesn't actually work in the background, only when needed right away. Which defeats a part of the purpose--it can still perform reorderable operations out of order, but it cannot also work constantly to ready surfaces ahead of time. The second problem is that image saving isn't working due to issues with linking to libpng from SDL_Image. This causes a crash at the end of the test game (where it would normally save the MJ map it draws).

You can hit 'j' to see the Majestic Map Engine in action in TurboSphere, comma and period to see the circles at different radius sizes, M and N to switch back and forth between MIDI and OGG playback, and Y to test the Abort() function.

I recommend running from the command prompt to see all output. You can specify the SGM or directory to find the SGM file to run as a parameter. If it properly crashes for you at any point, please let me know. Ideally with information about what you were doing, and what function triggered the crash or just an example script that crashes it.

Alternatively, you can post an issue on the GitHub page.

I fixed the bug that causes crashes on saving an image or taking a screenshot. The quick fix was to disable PNG saving, since I need to be more sure about linking to the same version of libpng as SDL2_Image to do things properly here.

I also fixed a bug (stroke bad feature) that stops TS 0.3.5a from working on some Intel GPUs. Seriously, Intel has bad OpenGL support compared to NVidia and AMD. They don't support a lot of fairly standard features. I'll make a new release with that and a fix for the screenshot-crashing bug tomorrow or the next day.

I've got PNG saving working on Windows, using the same libpng that SDL2_Image uses. Turns out that it's easier to make a .lib file to go with a lone .dll than I thought.

I'm still working on the threading issue, but I've got a good idea what the problem is and why it is happening.

Also, I need to remove the GetLocalName function from the test script, or just fix that function. It's a lot buggier than I thought at first.

Hmm, the program crashes almost right away for me. First time I started it I heard some music, but after not even a second I get a runtime error. Subsequent runs crash almost right away.

Here's the not likely to be helpful nonsense it outputs.

Code: [Select]

Probleemhandtekening:
  Gebeurtenisnaam van probleem:	APPCRASH
  Naam van de toepassing:	turbosphere.exe
  Versie van toepassing:	0.0.0.0
  Tijdstempel van toepassing:	525a2ed1
  Naam van foutmodule:	v8.dll
  Versie van foutmodule:	0.0.0.0
  Tijdstempel van foutmodule:	5258cbe5
  Uitzonderingscode:	c0000005
  Uitzonderingsmarge:	0014957a
  Versie van besturingssysteem:	6.1.7601.2.1.0.768.3
  Landinstelling-id:	1043
  Aanvullende informatie 1:	0a9e
  Aanvullende informatie 2:	0a9e372d3b4ad19135b953a78882e789
  Aanvullende informatie 3:	0a9e
  Aanvullende informatie 4:	0a9e372d3b4ad19135b953a78882e789

Something with v8 once again, hmm.

Also see attached screenshot in case you can notice something wrong there. (Note: pic reduced to 256 colours)

OK, that's something that I haven't seen yet. The supposed cause being V8 means it's because of a call from script, so not directly related to the surface thread issues.

I actually think this is related to the call to GetLocalName, since that hasn't shown up in this shot, but everything else has. Plus I've been having issues with that on Windows. I'll try and fix that, and make a new release with that and all the other new fixes in it in a bit.

For me everything seemed okay, until it crashes on ESC in that second phase of the test. Seems like the save path contains some invalid characters (win 8.1, 64 bit).
Also when I checked the code it seems that you can only enter that second phase by pressing Q. But it somehow goes to that mode when I move my mouse outside of the game window...

That is strange that you see invlid characters in the path...but either way, it would have crashed since it isn't properly linked to libpng.

The main loop exits after 10,000 frames, and records how long it took to draw.

EDIT: I've updated the TurboSphere API page to more accurately reflect 0.3.5a.

OK, TurboSphere 0.3.5 is out. It fixes the problems with the surface thread not locking, which fixed a lot of the freezes I was getting. It also very almost quits gracefully.

BEWARE: You will usually need to kill this version from the task manager to close the command window. It hits deadlock when it tries to fully exit. As you can probably tell, the issue is not totally resolved, but I am working on fully fixing this.

I believe that both the crashes that DaVince and Metallix were getting are fixed (I was only able to reproduce the problem Metallix had, and it is fixed for me, but I believe I know what was happening for DaVince and fixed that as well).

@Metallix: That's two errors at once. The garbage-path name error is fixed, the other no longer causes a full crash.

I believe I have found a way to allow accessing specific bytes of a ByteArray using index values (and more generally accessing data in script-side objects using array-style access in arbitrary ways). I plan on incorporating this addition in the next release.

I believe that both the crashes that DaVince and Metallix were getting are fixed (I was only able to reproduce the problem Metallix had, and it is fixed for me, but I believe I know what was happening for DaVince and fixed that as well).

Cool. I'll try it out when I'm on Windows. (Could be a while; could not be. We'll see )

@DaVince: No worries, I hope it works better for you this time. Ideally perfectly, but I doubt that given it crashes for me in certain circumstances.

I've made a change that will be a part of the next release:



Exceptions in script will be reported with the correct line number now (that alone is a vast improvement) and in a popup box. Not only is this shiny new eye candy compared to how Sphere does it (and much, much shinier than directing all output to stdout and stderr like TurboSphere did), but the text in the box is selectable. You can just highlight and copy the error, line number, everything and then paste it anywhere you want. It shouldn't be annoying either, since the popup gets focus, and any key press will make it disappear. If you didn't look at the screen, it would seem to act like Sphere 1.5.

I'd like to take this further, and add a 'go to line in source' button that would open an editor to look at the line in the script that threw the exception, but that is much more work, there are two editors I would have to consider (I can't use Radnen's editor on Linux), and I don't think that the original editor has this kind of function built in. So, oh well, a nice thing to dream about.

Nice! Any particular reason you didn't use an actual editbox, though? It's not visually clear that you can copy and paste the text as it is. Also, is that third line indented or centered? Maybe you could remove start-of-line spacing...

any key press will make it disappear

I'd rather have just enter/space trigger the OK button and have everything else do nothing. Makes it not mess up when I try ctrl+C or when trying to select text using the keyboard.

It's more clear on Windows (or so I am told), and even on other Linux set ups. It's an SDL2 feature. That's a pure X11 box, it doesn't look that way for most folks even on Linux (my WM+X set up is sort of hand rolled, fluxbox with a customized theme). To me, that's clearly selectable since the background is dark gray and not silver. I'll see if I can't make it more clear (and see what it looks like on Windows).

You can easily select the text and copy, nothing unusual, it's just that it is set to give the button focus when it pops up.

The third line is exactly what is in the source when V8 gets it. So here, there are two horizontal tabs in it, just like the actual line from Jest_Main.js (that name should appear as the script name, it doesn't here because of reasons). The message box will always be sized to hold the line. I could remove whitespace and/or split it to keep it a reasonable size. It actually might have a maximum size, I'm not sure.

And of course, I can make all this configurable. In fact, I'm especially tempted to since it is an engine feature, not a plugin feature.

EDIT:
It works more like you described now, DaVince. Except for seeming more selectable, that'll have to wait until it gets ported to Windows (next release, since this really shouldn't add any new issues on Windows) so I know what it looks like there.
It also actually displays the script name now. That was the result of one of the oldest outstanding issues in TurboSphere, fixed now.
I actually like how it looks now a lot better. Thanks for the feedback!

TurboSphere 0.3.5c is released!

There are three things that are improved in this version:

1. Fixed a bug where repeated calls to GetLocalName caused crashes (and bad return values of GetLocalName). This fixes most of the intermediate crashes I saw (and all crashes not at startup or exit).
2. Fixed the evil, evil bug causing TS to either crash outright or deadlock upon exiting. This fixes all crashes I was getting on exit.
3. Errors now report the correct line number.

As it turns out, SDL2's messagebox API is not entirely consistent between X11 and Win32, and the text is NOT selectable in Windows. But errors are reported in a much nicer way now.

As far as the crashing and/or deadlocking at exit...I'm shocked by how much of the standard library is not thread safe. But this did lead me to uncover quite a few 'bugs' that weren't apparent in the engine's handling of plugin lifetimes. I feel a lot more confident in the engine's handling of plugins now. TurboSphere will someday soon be able to change games while running--the only bit missing is the upgrade to a newer V8 that will let me gracefully restart V8 (due to new v8::Isolate code and a couple debug features) and not drastically change the architecture of the TurboSphere engine proper.