I'm running a 2.4 GHz A10 (I'm going to guess this is somewhat similar to a 2.0 GHz i5?). And I am using Wine, although the only two things that seems to slow down with Sphere is startup time and the non-GL drivers.

The A10 is roughly equivalent to an i5, yes.  The machine I just built has a 4.1 GHz(!) A10-6800K and I can tell you that thing is fast.  The i7 is better for anything excessively CPU-bound (like video transcoding), but I've found that the AMD chips have better iGPUs and are less expensive, so I tend to gravitate towards them.

If you want to use OpenGL, AMD integrated graphics is lightyears ahead of Intel. Mostly because Intel seems to think that you don't actually need to implement the entire core OpenGL profile in order to claim compliance, so they are missing rather useful features (like proper vertex arrays as late as SandyBridge).

I've updated TurboSphere on github. The shader objects are exposed and updated the default shaders to no longer rely on deprecated projection stack variables. I've made the surface thread properly sleep when not doing anything, so TS doesn't burn down two cores at idle. I've also tweaked the V8 usage, which removes some overhead (it was causing bumpy CPU usage, even at idle, keeping stackframe info valid in case of fatal internal errors). This puts simple rendering loops to the technical maximum for TurboSphere, 2000 FPS. Until I fix the rest of the OpenGL usage, that is the hard limit on FPS (at least on AMD machines, haven't tested on NVidia in a while).

I suppose it helps that AMD has the entire ATI legacy behind them. Intel seem to build their graphics hardware in-house and thus only really have their dismal motherboard graphics (which, it should be noted, was also notorious for not implementing stuff--in Direct3D, no less!) to build on.

If you ever try to set up AMD GPUs on Linux, you can see the ATI legacy alive and well. A vast majority of their tools and drivers are copyrighted AMD, but branded as ATI still. The only case I can see of a Unix tool being rebranded as AMD beyond something very superficial is the new amdcccle, which 'replaced' aticonfig. But it can't do a lot of the things that aticonfig can, and so you still need aticonfig (mainly for generating the default x.org file). AMD doesn't seem to have really built too much new stuff, just improved older ATI work (at least in software, to be sure).

Anyways, I've exposed screen width and height as uniforms to shaders. That means the default shaders don't use the deprecated projection stack. Only the addition of vertex attribute definition, and they will be fully OpenGL 4.1 (at least) compliant.

Edit:
It seems like the best changes always result in the least interesting screenshots. Anyway, TurboSphere, fully OpenGL 3.3 compliant. That, along with the minor change to the V8 usage, has made things pretty Turbo!
I have to rewrite small parts of just about every graphical function, but it's a good opportunity to make the primitives less redundant, and to fix some of the stuff left over from back when TS used software rendering (I'm thinking of the WindowStyle plugin mainly).

Kind of funny, TurboSphere went through software rendering, immediate mode, collected pointers, and now uses vertex arrays and fully buffered graphics data uploads. That's an awful lot like the general history of graphics rendering API techniques, right there. And I can say with certainty, that each change improved both speed and elegance.

Awesome! Good work. I bet you've learned a lot about all of these rendering types, too.

I have learned a lot. I would certainly say I've learned enough to know why it's done the way it is now!

And it certainly hasn't been wasted time, either. The things I learned from software rendering are still quite applicable to the surface code directly--not to mention that it was a valuable learning experience about data transformation in general. The immediate mode and pointer-buffer coding was useful because it taught me about how some things should look when you are using modern, flexible (i.e., write it all yourself) OpenGL, and because you can see where a lot of more subtle bottlenecks are more easily that way.

Apparently, it's also OpenGL 4.3 compliant, I'm just not really sure how many computers out there can do 4.3 (for instance, my laptop can do 4.3, but my much more powerful desktop can only do 4.1). I think I'll leave it using 3.3, since that's pretty common.

Attached is a copy of the TurboSphere SPK (no gui) extractor, win32 binaries.
That copy of T5.dll in the same directory as turbosphere.exe will make older TurboSphere binaries very angry, though.

I've updated the Sphere system scripts that are distributed with TurboSphere to actually run on TS with no extra modifications. I've also added the long-fabled compatibility script (sphere15.js, a system script) that makes the new TurboSphere objects constructable using the old Create* and Load* functions.

I should have the FLTK (gui) SPK extractor win32 binaries up tomorrow or the next day, and some new, slightly unstable TurboSphere win32 binaries up a few days after that.

New stuff for the upcoming (0.3.6?) TurboSphere:
* Typed Arrays finally enabled!
* Fully OpenGL 3.3/4.3 compliant code (which is really fast!)
* Shaders exposed to script
* Many graphics functions will be missing I need to fix a lot of them up to work with OpenGL 3.3
* Running games from SPK files
* Fully updated system scripts for TurboSphere
* New Sphere 1.5 compatibility script included as a system script
* Fixed PNG saving

So, I have no idea how fast TS is now, but the version on my computer is very slow. Showing some strings and a windowstyles brought it to 270fps. But even then - for that version - I was expecting better performance. I really want to know how much you've improved it by, and I'm sure it's going to be quite a bit! See, I thought you were mulling over a few fps here or there like I am, but it seems you have really revamped your graphics backend.

Also, have you started the map engine yet?

What version do you have? All the 0.3.5 on up are pretty similar (and about 80% performance of what it is now, although initially loading images takes a little longer now than it used to).

The test script get's about 1000 fps on my laptop (showing two windowstyles, blitting three surfaces without converting them to images, playing a midi, writing several strings using both TTF and BMP fonts, doing zoomed, masked, and rotated blits). WindowStyles should actually be medium speed, they do some silly things, but only have a single draw per component by using greater-than-one texture coordinates. They will, however, get a bigger boost from the new graphics backend and fleshed out spritebatcher (atlasing their components makes perfect sense).

If it is 0.3.5, you can try disabling compositing in engine.ini (set it to zero). That kills performance on AMD machines, I noticed, though not as much on NVidia. Setting the scale has a small effect (TurboSphere in 0.3.5 is either cpu limited or fill limited, depending on what the scripts do). If you aren't getting over 1000 fps on the test script with a Radeon 8750, GeForce 550 ti, or better, I'd like to know more about what is happening there. I get over 1000 fps on my 550, right around 1000 on my 8750.

The new graphics backend is still only about a 20% improvement of the final 0.3.5. I'm adding it because, for one, it uses OpenGL that isn't nine years old, and for two it makes the sprite batcher (which will power the map engine in particular) much, much faster.

You can open maps and spritesets in TurboSphere (a spriteset sprite is rendered through the Sphere API in the 0.3.5 test script), and calling MapEngine will draw the map (but slowly, it's just a test of map loading). I have all the code to load maps and spritesets, and some code that I will use as reference for the actual map structure. But really, it's just prototype stuff. Nothing optimized, nothing really the way I want it to be, just feeling out what it should be like.

I have kind of been stuck with the backend, though. Mostly because fully updated Arch Linux can't use proprietary AMD drivers at the moment (it has Wayland compatibility in the X server, which crashes fglrx). So since the weekend I've only been able to use Mesa drivers. Which are slow.

It might be veryold, I don't see a version number anywhere - not even in a readme. It's definitely 0.1.* though.

I'll try a 0.3.* version.

Dang. I was just about to finish a download and the file's server goes offline. Welp.

Does it have an SDL_GL_Threaded.dll plugin in the `plugin` folder, and does the executable have the actual turbocharger logo as its icon?

Without the threaded graphics plugin, it's pre 0.3.x. With the turbocharger icon, it's either extremely new (the threaded plugin will indicate this), or extremely old.

The latest release is on SourceForge. It's not really what I even have as stable on GitHub (which is still well behind what I currently have), but it should be relatively close.

0.3.0 does not work. Well, it does for a few seconds but crashes straightaway. And I can't seem to download anything else from sourceforge.

There is also a copy on FJE at flyingjesterentertainment.webs.com/ts-0.3.5c.rar.

Looking at 0.3.5c (the latest Windows release), I've been really terrible about making binary releases. That's a pretty old build, from just before I started using shaders.

I haven't really been making binary releases that often anymore because most of the changes are not visible. It's similar to when I was building the plugin system. Lots and lots of coding, much of it untestable until it's all done. And in the end, it all looks the same as when started. It will mean that the final product will be faster and more stable, and be finished sooner. But the change, in and of itself, has no noticeable effect.

In this case, it's actually worse from an outside perspective. All that works graphically in the bleeding edge branch of TurboSphere on GitHub, and I mean all that works, is image.blit and Rectangle. But oh-me-oh-my-oh, image.blit and Rectanlge are as absolutely efficient as they can be. Now I need to finish the automatic texture atlasing in the sprite batcher, and image.blit will be done. Then I can make all the other primitives work just like Rectangle, and make the changes for the rest of image and surface drawing functions.

Then I will have TurboSphere doing all the things it did before I started. That's why I haven't made any releases in a while. You could see what I have now, but you would wonder where the entire Sphere API went, and why calling the wrong function segfaults it.

In 0.3.5 I get this error: glGenBuffers is not present in OpenGL Library.

And The 7-zip log was full of issues when extracting your .rar file. It still managed to extract the files though.

That's probably because it was packed using unrar.

Are you using an Intel graphics card? I know that NVidia and AMD drivers have glGenBuffers. That's a pretty basic 3.x function, and almost always present in 2.x. I would say that it is necessary, but if you don't have an Intel card, I'm not really sure what to say about that.

EDIT: Does it say anything about what version of OpenGL it detected (usually appended to a vendor string)?