Now available for Windows

rpgmaker.net/users/FlyingJester/locker/sphere16fj.zip

FJ-GL offers more performance in more situations than Standard32, better optimized performance than SphereGL, and no known bugs.

It does require you to use the specially compiled version of Sphere 1.6, however (It's all included in the link!). But it's better than ordinary Sphere 1.6 anyway. The only difference in the Engine executables are that this version is compiled with MSVC++ 2010 standard libraries, instead of the MSVC++ 2005 libraries that ordinary Sphere 1.6 uses.

Background

So, after getting Sphere 1.6 compiled on Linux, I noticed something. The SDL_GL graphics backend is SLOW. I know that it was always a case of 'It can be fast, treat it nice', but after looking through its source, I decided that was silly. For instance, it draws ellipses and circles on a per-pixel basis.

So I decided to write my own GL-based Sphere graphics backend. FJ-GL! It's almost 200% faster than the existing OpenGL driver for Linux--and I haven't done anything crazy or even all that modern to make it that fast.

I've only compiled it on Linux so far (that's where a new graphics backend is needed most!), but it should compile on Windows as well, once a shim function is written for the InitVideo function there.

I've written it for OpenGL 3.1, because that will run on all my machines. I plan on adding an OpenGL 4.3 version as well.
EDIT: The Windows version only requires OpenGL 2.0

My gfx card can only go up to GL 4.1, so target 4.x cards rather than 4.3.

Anyways, that's great news! This is for Sphere 1.6 and not TS, correct? If so I'd like to compile it for Windows... I wonder if it'll compile and what dependencies I'll need. The Windows SphereGL driver had... issues: things were 1px off, incorrect windowstyle handling, etc.

This is for Sphere 1.5 and 1.6. It will need SDL or SDL2, T5 (included with TurboSphere, I'll include a copy with this when I get to making it work on Windows).

I'm designing it so that it can work on 2.0, 3.1, or 4.3. You don't really get that much in between 3.1 and 4.x. It will only be able to do 3.1 and 4.3 on Windows, too. I can't link to SDL2 without removing the SDL1 code in Sphere's unix setup, and I can't go straight through GLX without breaking Sphere's input handling. And you can't force an OpenGL 3.x or 4.x context in SDL1.

I'm not so sure how much of the windowstyle handling was properly Sphere-GL's fault. I'm getting horrendous windowstyle errors with FJ-GL, but literally nothing else image or surface related seems to be wrong.

I know the off-by-one is Sphere-GL's fault. I know the exact line that causes it.

To compile it on Windows, you'd need to replace the Unix InitVideo shim with one that conforms to the posted spec.

It still needs Bezier Curves and Complex's. Those functions are dummied out for now.

Nice work. Could you include it in your branch of the Sphere git while you're at it?

I will once it isn't so buggy. I need to find out why windowstyles are exploding with it.

I'd also like add bezier curves and complexes first, but those are low priority.

I've fixed the Windowstyle issues. I've also added the base blending modes (same ones Sphere-GL supports) to blits.

EDIT: All blend modes except Average have been added. The Average mode can't actually be done in OpenGL without dedicated shaders, it seems. So now FJ-GL has more blend modes implemented than Sphere-GL!

I had a couple hours today on a Windows machine, and I've added an MSVC 2010 solution to the GitHub repo. I've tested FJ-GL to compile on Windows and be properly loaded by Sphere 1.5, although it crashes immediately after taking control of the window.

I'll need to clean up the changes on Linux and make sure it still works there. Once it does, I will add it to my fork of Sphere on GitHub as a Linux graphics backend.

Alright, I've got FJ-GL working on Windows. Get it at http://rpgmaker.net/users/FlyingJester/locker/sphere16fj.zip.

You will need to install the Visual C++ 2010 redistributable if you don't have it already.

The one issue is that you need to use a newly compiled version of Sphere (such as the one I included), since there don't seem to be any versions floating around that use the MSVC 2010 libraries. That's why I had to include an entire copy of Sphere, and how engine.exe lost its icon. The sphere C++ resource files apparently aren't MSVC 2010 ready, and when I recompiled I had to remove them.

The compressed folder in the link includes the engine, config (stolen from 1.5), all the associated libraries from http://rpgmaker.net/media/content/users/6429/locker/thirdpartymsvc.zip, and T5 from TurboSphere 0.3.1.

I've confirmed this version to work perfectly on Intel GMA 496 (ca. 2007) and NVidia 8800, and I've added several fallbacks for suspect features (including mipmaps, hardware image cloning, and extended blend functions). You really do need OpenGL 2.0, though.

It seems that on older hardware, it's about 2x the speed of Sphere-GL (!), even when dealing with DirectBlits. This is a much larger performance increase than I saw on Linux, but it seems the better your card the closer the two will be. I tested on a brand new card in Linux, I'm testing on ancient history in Windows. Perhaps this is the benefit of optimizing it for Mesa3D before I ported it.

Tung's startup game, Sphere 1.6, on Windows on an Intel GMA 496:
Sphere_GL: 90 FPS
FJ-GL: 170 FPS

It's not quite so good! I think we need more people to try it out.

Huh. That doesn't happen to me. I'm going to guess it's due to pixel format selection.

I'll have to do more testing. Do any of the included test games look like that, too?

EDIT: OK, the shader for GLSL 1.30 was definitely the wrong one (HQx2 gone terribly wrong). Try it now, I've changed it back to what it should be.

It's not quite so good! I think we need more people to try it out.

Green is my favorite color so that's awesome! (Yes, I know it's not supposed to do that, just felt like being a wise-ass )

The wrong shader was being used when GLSL 1.30 was available. It was HQx2 gone terribly wrong. I've changed it to use the correct one.

EDIT: Found another bug, happens when the screen size is changed. Fixed it. It should work fine now.

Good, it works. But the FPS is always a constant 60, so that must be the GL override doing it in the nvidia control. Sphere was never affected by that, neither my sfml version.

I turned off the override and these are the FPS values:
Sphere 1.6 GL: 550
Sphere 1.6 FJGL: 680

Not a bad difference, almost 20% faster.

Glad to hear it worked! 

FJ-GL is non-configurable, at least at the moment. I would actually have to edit config.exe's source to give it a configuration page, and I would have to link with Sphere's win32.lib to load anything from the filesystem. I just leave everything as normal as possible--1x scale (although there is code in there to allow for different scales), windowed, VSync is system controlled.

In Linux, you can configure it. You can choose between Windowed and fullscreen (the code for that doesn't exist in FJ-GL for Windows yet), scale from 0.5-32x, set filtering to linear rather than nearest, and even decrease the number of sides that are approximated to make up circles and ellipses to get a little more performance (at great cost to visual quality, mind you). That last one is important for my Gravity demo, drawing a circle of radius 400 would go down to 1 FPS on Sphere_GL, but it stays up near 100 FPS on FJ-GL. Of course, that's also because FJ-GL actually approximates a circle and uses polygonal rendering rather than going pixel by pixel deciding if it's part of the circle or not.

In Linux, you can configure it. You can choose between Windowed and fullscreen (the code for that doesn't exist in FJ-GL for Windows yet), scale from 0.5-32x, set filtering to linear rather than nearest, and even decrease the number of sides that are approximated to make up circles and ellipses to get a little more performance (at great cost to visual quality, mind you). That last one is important for my Gravity demo, drawing a circle of radius 400 would go down to 1 FPS on Sphere_GL, but it stays up near 100 FPS on FJ-GL. Of course, that's also because FJ-GL actually approximates a circle and uses polygonal rendering rather than going pixel by pixel deciding if it's part of the circle or not.

SSFML does that too! But the configuration for it hasn't been made.

There is an issue with GrabImage, and I presume GrabScreen too. When I render the scene it leaves out many things, then when I toggle the fps ticker, the hidden stuff is shown. And the GrabbedImage is flipped vertically, and a rotate-blitted image seems to fade a lot rather than do what it is supposed to do. Even then still not all colors show up right, the lines are supposed to be white.