Dude, I have an Nvidia 550Ti, it supports open GL 3.x I have had no issues with GL anytime in the past. (check out the cpu-z by clicking the link in my signature). It only did that in the plugin mapengineGL.DLL, I removed the offending file and now it says:

Uncaught ReferenceError: GetSystemFont is not defined
Error occured in script TS Test at line 30:
var fn = GetSystemFont();

I have to admit that is certainly a very informative error message!

That's odd that glGenVertexArrays isn't found, I test all my Windows builds using an NVidia GTX 550 ti!

That's bmpfont error very strange...I actually don't know why that is happening. The only reason that should happen is if bmpfontGL.dll wasn't being loaded right. Does it mention that plugin on startup in the terminal?

It'd have been more informative if I had realized that it wasn't reporting script names properly before I released 0.3.5c.

$ ./turbosphere.exe
game.sgm is the sgmname. We are running in / mode.
[Engine] The main script is startup/scripts/Jest_Main.js
Plugin SDL_GL_threaded.dll is not open.
Error: 1114
Plugin audioBASS.dll is open.
Plugins:        1
Plugins:        1
Plugin bmpfontGL.dll is not open.
Error: 998
Plugin inputSDL.dll is open.
Plugins:        2
Plugins:        2
Plugin networkTS.dll is open.
Plugins:        3
Plugins:        3
Plugin scriptfs.dll is open.
Plugins:        4
Plugins:        4
Plugin ttffontGL.dll is not open.
Error: 127
Plugin windowstyleGL.dll is open.
Plugins:        5
Plugins:        5

Running Script.


Game function done running.


Context exited.

Plugins:        5
Plugin Closed:  0
Plugin Closed:  1
Plugin Closed:  2
Plugin Closed:  3
Plugin Closed:  4
All Plugins Closed.
Fatal Error
Uncaught ReferenceError: GetSystemFont is not defined
Error occured in script TS Test at line 30:
var fn = GetSystemFont();
Segmentation fault

So that's weird.

Well, that explains it. No BMPFontGL, no GetSystemFont. And no SDL_GL_Threaded (wtf?), not much of anything. And you say the rar had a bunch of errors...I'll see about repackaging it as a zip or tar.gz or something.

EDIT: Here it is as a 7z: http://flyingjesterentertainment.webs.com/ts-0.3.5c-win32.7z. Windows has some serious issues with zips made on Linux, so I'm kind of limited. This 7z is a mirror of the SourceForge download.

Zip is a standard format that's been around forever. Unless Linux is using some exotic compression method (readable: not deflate) then every zip utility known to man, including PKZIP, should be able to extract it. Unless you're using some of the enhanced zip features first introduced in winzip (e.g. 64-bit)?

7-zip says it cannot open that as an archive. I wonder if others can? Maybe there was an issue with either your upload of it or my download. I do commonly see a "no data received" error when trying the download link. Then sometimes it works and takes forever to download (though I have a fairly fast connection). Weird.

Edit:
for your original archive, 7-zip gave me these errors:

0 Unexpected End of Archive
1 <Filepath>
2 CRC failed in 0.3.5c\zlib1.dll'. File is broken.

I presume other files were broken too.

What is happening here?

I would get it if it was just FJE that was being weird, that host is fairly bad about downloads, but SourceForge too? I can download all three, and they all can be extracted fine over here. That should work.

@Lord English: It's Windows that is being non-standard. WinRAR, unzip, 7z, and every other utility can open them fine, but the built-in zip utility in Windows throws a fit about zips made in Linux. Or pretty much zips made with anything but itself.

No matter what browser or what host I use (SourceForge or your site), or archive I pick 0.3.5c cannot be extracted. :/

I am downloading files correctly. I just tried downloading some archives of mine and they all work and extract just fine. So, I don't know exactly what is happening with your files. I wonder if it is anti-virus related?

It really might be. All the executables and libraries are UPX compressed, and the engine executable has a 'hacked' icon since I have no idea how to use scons to give my executable one. And it doesn't help that there are a pile of libraries and a couple executables that the anti-virus program has almost certainly never seen before.

Re app icons - you need a properly formatted resource file for Windows executables to have a custom icon. My sample phoenix app has one you can copy from.

But how would I use that with Scons? I've used resource files to give programs icons before, that's how the older releases had the turbocharger icon, but I have no idea how to use them with Scons, they just seem to be ignored.

I didn't try all that hard, mind you. I had used the resource hacker before, so I knew how simple it was to do it that way.

EDIT @Radnan: You could try using the bmpfontGL.dll, SDL_GL_threaded.dll, and ttfffont.dll from the 7z copy with the rest of the rar copy. But that is a pretty jagged solution.

OK, I'm going to compile the source from GitHub for Windows. It has some of the improvements from the bleeding edge--particularly fully modern shaders, command-line configuration setting, and a slightly newer V8 version. Then I'll begin working on getting the bleeding edge ported over to Windows.

@Radnen, Re no glGenBuffers: Are you using the NVidia branded driver or the one that Windows installs automatically? The NVidia one has a new OpenGL library, and I'm not sure that the MS distribution of the drivers has an updated OpenGL library from the Windows default one (which is OpenGL 1.1). That's the only reason I could think of that a 560 ti would not be capable of vertex buffers. I don't check against extension lists, I check for exposed functions in the OpenGL library itself.

The other possible issue is that your card or drivers or OpenGL library won't open a 3.1 context. Without that, TS ends up with a 1.1 context, which will cause this kind of issue. I find this a suspect reason, though, since you have a 560 ti, and my 550 ti's can do it. The driver for a more advanced card should have at least as high an OpenGL context capability as older cards. Or so I would assume?

I run Dolphin emulator in OpenGL, I would know if I didn't have a 3.* context. :/ I'm using official nVidia drivers. It could be that the DLL was messed up in the unzipping? But then again it wouldn't even load if that were the case. I really don't know why it said that.

I downloaded a tool called OpenGL Extensions Viewer and it says I indeed have access to glGenBuffer. I get a 100% feature test pass on my gfx card. Now, what's interesting is my on-board graphics is only OpenGL 1.1 compliant. Are you sure TS is using the correct rendering device? There is a difference between choosing the first device and choosing a supporting device.

TS uses whatever SDL2 uses. On my laptop with dual, dissimilar GPUs, it uses whichever one the drivers use for display 0 in GLX. I assume it is similar in Windows, whichever GPU WGL will give it as a default. SDL2 does have more advanced support for choosing version of OpenGL, which I use to specify a 3.1 context. I don't know if it will try using other devices if the first one can't do it.

All a file needs in order to be successfully loaded by TurboSphere as a plugin is a valid executable library header that specifies the symbols Init, GetFunctions, GetFunctionNames, GetVariables, and GetVariableNames. It will, of course, fail quite spectacularly if those symbol definitions are lies.

This is too perfect of an error for it to be corruption. I'm going to assume I made some typo in the GL funciton loading code somewhere, and it's saying that glGenBuffers is missing when it's really something else completely. It would still have to be something a 550 has that a 560 doesn't. Quite possibly the NVidia texture cloning extension I use, which apparently has been superseded by a a core function, so an older card would have it but a newer card might not. Originally, I assumed that, since my AMD 8750, 8550, NVidia 8800 and 550 ti all had the NVidia variant, and only the 8550 had the GL variant, I could safely use the NVidia version. I recently changed that to try and get the NV function, then if that fails the GL function, then fall back to software if that fails. I don't think that change made it into 0.3.5c.

SDL uses the first device instead of the default device. byuu ran into a similar problem when writing multi-monitor support recently into higan. If I were on my laptop I'd link that thread.