So all this talk about shaders has me curious. I know shaders are used in 3D games for special effects, but what would be some applications of shaders in a 2D game? I'm straining, but for the life of me I can't imagine any (non-gimmicky) use cases for them.

Fast efficient cave lighting, Bloom lighting, gray-scaling the screen for flashbacks, particle effects, advanced GUI objects (like the health globes of Diablo II), water, ice, invisibility cloaks, fire, a "speedup" or "warpspeed" effect, and lot's more.

You can use them for any kind of color or geometric transformation, any at all. Like, if you wanted hue shifts, or to go black and white, or to add some kind of ripple effect (water, or a screen transition, or anything else).

In those screenshots I posted, they are being used for color masks, defining the screen coordinates, and coloring primitives. If you think of the parameters to, say, Rectangle(), the shaders are defining what those values mean. You could just change one line, and the x coord would mean the y. Or the red color channel. Or rotation, or whether or not to do alpha blending, or whatever. The default shaders I wrote just imitate the fixed function pipeline and allow you to use raster coordinates.

Considering an only slightly gimmicky use....

Take the default fragment shader. If, say, you wanted to lower the lighting, and make it look like night. You could use a different shader that looks like this:

Code: [Select]

#version 120

void main(void){
        gl_FragColor = gl_Color/vec4(0.5, 0.5, 0.8, 1.0);
}

If you imagine a color to be a vector of four floating point numbers, each representing the luminosity of a channel (1.0 is like 255, 0.0 is like 0 in 32-bit color), this would cut the red and green channels in half during drawing. So it would look blueish. The point being, it would be pretty slow to post process these kinds of effects (even the trivial example above!) in software. And also much less elegant.

And besides, if you want to use OpenGL that isn't ten years old, you need to use shaders. I'm setting it up so that if you don't want to learn GLSL, you don't have to, either. The default shaders work the way it did previously, you can just pretend it isn't there and you will be fine. But you can write your own shaders and switch between them if you want to.

EDIT:

I've added hardware image cloning, and an alternative software method that will be used when it can't be done in hardware. Makes image cloning much faster, but also much more elegant (only a single function call, no buffers for pixels in system memory). The extension it uses is very common, and really should exist for your GPU if you have OpenGL 3 or greater (guaranteed to exist if your card is OpenGL 4.3 or greater).

How do I find out what version of OpenGL my card supports? I just built a machine with an AMD A10-6800K CPU so I'm curious what level of support the integrated GPU will give me.

You can check out GPU Caps Viewer, that can tell you detailed things about your GPU. In linux land, there is always glxinfo.

I can tell you that an A10 supports at least 4.2. My laptop's A10 supports 4.3.

Just reading through the TurboSphere API for the first time. I like it, it somehow seems more tightly-plotted than the Sphere API, if that makes sense. Also, I like the, um, how to describe it, formatting style(?) you use. Like, "var font = new Font("filename.extension")" instead of "var font = LoadFont("name.ext")" That's the way most programming languages do it, it's more intuitive for people coming from other programming languages.

I noticed that some of TS's API functions, however, have fewer parameters than the comparable Sphere ones. Just curious if those were deliberate choices and there's different ways of setting such options, or if you just haven't gotten around to adding those features yet. For example, the Sphere Polygon primitive has [invert] as an optional parameter, the TS doesn't.

Oh, also, are there system default fonts/windowstyles/arrows/etc. in TurboSphere? I'm guessing not, 'cause I'm guessing, as the name implies, TS is meant to be fast, and having default stuff like that would probably slow down execution. Just curious.

I've been trying to convert to Linux lately. I'm definitely gonna use TurboSphere as my primary Sphere engine in Linux. Though I'll probably wait 'til the first full release. I've got enough problems programming in the relatively-stable Sphere 1.5. I'm not brave enough to use an alpha anything just yet :p

I've been trying to streamline the API, although I really haven't done too much in that respect. Most things that are missing (especially the map engine) are missing because they just haven't been added yet.

I have, however, tried to generalize the API more, and to make it look more like JS. For instance, the proper constructors for engine objects, some overloaded functions like `Surface`, etc.

Defaults can actually improve execution time. Since more is known about them, certain optimizations can be made that would be expensive or possibly counter-productive if applied to any arbitrary situation.
GetSystemFont, GetSystemTTFFont, GetSystemWindowStyle all exist. GetSystem(Up|Down)Arrow has been added to the bleeding edge, but not the last release. The API document is about 95% of what exists in TurboSphere. The other 5% is some stuff I forgot to put in, and some stuff that is secret 

For the polygon's invert, that's something I do want to add (it's actually the same technique that makes the 'complex' primitive). It's just that it is something much easier to do with Sphere (software/non-buffered hardware primitives, monolithic engine) than with TurboSphere. I'll get around to most of the Sphere API eventually, I've just partially focused on adding things that make other things possible so far (i.e., Image.transformBlit makes Image.rotateBlit possible by recreating it in script, so Image.transformBlit is more important to add). By the same token, you could use Polygon to do the same thing as an inverted Polygon, so it's lower priority than a lot of other stuff.

Hey, what is the overall time for TS to run this, I'm just curious:

Code: (javascript) [Select]

function Alert(text) {
    Rectangle(0, 0, GetScreenWidth(), GetScreenHeight(), CreateColor(0, 0, 0, 0));
    sys_font.drawText(0, 0, text);
    FlipScreen();
    GetKey();
}

function TestRawSpeed() {
    var t = GetTime();
    for (var i = 0; i < 10000000; ++i) { }
    t = GetTime() - t;
    Alert(t);
}

Sphere: 564ms
SSFML: 19ms (29.5x faster)

I get 20-21ms in TurboSphere on my Laptop. For comparison, Sphere 1.5 on my laptop gets 2771 (on Wine, mind you).

Also, TurboSphere now comes with a command-line SPK unpacker. I'll probably end up packaging it with tsconf, since I'd like to give it an FLTK graphical frontend. I'd also like to make it into a full SPK editor, but that's a ways off.

To use the spkeditor:

Code: [Select]

./spkeditor
options:
-x      Sets to extract mode. No other modes yet, unfortunately.
--if=[] Specify SPK File
--of=[] Specify Target Directory

Sweet, it seems for that example TS is 131 times faster. v8 is really fast!!

Hey so, do you have a good Windows port ready?

I can't really do that until the new year. I need my desktop's Windows install (as well as its MSVC) to do that, and I'm on holiday out of town right (and until the end of the first week of January). I'll actually probably be out of touch during that time, too.

Of course, you could try compiling it, too. I've added that guide that details what the entirety of compiling TurboSphere, including compiling all of its dependencies, on Linux and Windows x86 and amd64. But given I haven't tried compiling the source on Windows in about a month, it probably will have some issues that need to be resolved (I know at least the SPK code will, I haven't added the Win32 code to create directories yet). And then, of course, it will probably still have a few bugs that will need to be ironed out.

I'd like to get tsconf working properly with shaders while I'm away, and ideally add the FLTK frontend to my spk unpacker. And file adding and removing from spks. And get TS fully working in OpenGL 3.2. Well, some of that will probably happen. When I have no internet, I tend to be forced to actually work on things.

Also, I tested, and V8 isn't actually optimizing the loop away (also, very strangely, running a loop over 256k times seems to make the V8 hi-optimizer cut out for the loop's condition+iterator!). Makes me wonder, does Jurassic optimize the loop away?

Jurassic has very few optimizations in it, sadly. It most likely doesn't optimize the loop, besides running it (with boxing) as if it were a .NET for loop. In C# .NET I get 3ms. So pure .NET is still much faster.

Actually, I'm not sure TS and Jurassic are going to be much different speed-wise. When Jurassic compiles JS to CIL, the .NET compiler does optimizations of it's own too. That said there are certain JS to .NET optimizations not being made, like static casts and static function generation.

For example: if the var of a for loop was only ever going to be treated as an int, then treat it as an int rather than a double. In .NET a double for that for loop example, runs at 11ms, which is considerably slower than the 3ms of the int, which is closer to the speed of the compiled version. I'm surprised yor v8 version isn't much faster (in the single digits). But ultimately I'm surprised how dang slow Sphere handles that. I would have thought - even for an older interpreted language - a simple for loop would be pretty fast (like a hundred ms, not 500 to 2000 depending on the computer).

BTW I'm running this on a rig with a 3.3ghz i5 processor.

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.

I've got the FLTK frontend, SPK creation (not direct editing yet, though), and xz decompression as an alternative to zlib (although such a file must be made by hand right now) all working. I'm thinking it would have been nice if Chad Austin had left more reserved space in the SPK header--or any at all in the file headers themselves! It would be really nifty if you could specify the compression technique on a per-file basis.

I've also got TurboSphere set up to unpack SPKs into temp directories to run games from them. Ideally I'd use an in-memory fs for that, but that'll take more work.

I've exposed putting raw data into audio streams through ByteArrays. This means you could use JS to make any kind of sound-chip emulator (or any kind of effect, theoretically).

I've exposed putting raw data into audio streams through ByteArrays. This means you could use JS to make any kind of sound-chip emulator (or any kind of effect, theoretically).

You mean like my nwavedit demo or like my SN76489 emulator?

Precisely. Well, ideally precisely.

I'm having some trouble getting it to work perfectly, but that's an issue with me not quite being sure how this part of Bass works. I've got it reading sound data from wav files fine, with the data being pushed by JS rather than through a direct Sound object. Theoretically, you just need to push PCM sample data to it. I think it could also use FFT data, or ogg files, or anything it can play normally, but I'd expect PCM to be the simplest to craft in JS.

It needs more tweaking, but it's a pretty simple thing to add. And I think it has a chance of being quite useful. You could even stream music off the network with this (that's probably the easiest thing to do with it right now).

While I'm here (internet is very poor in rural Alaska), here's what the new TurboSphere Shader API looks like:

Code: [Select]

//Shader object:
shader.source //A string representing the shader's source. You can modify this, but changes only take effect if you subsequently make a new shader program using this object, or call shader.compile().
shader.name //A number representing the OpenGL name of the shader. Read-only.
shader.compile() //Compiles the shader. This is automatically done with ShaderProgram(), but you can check the validity of the shader using this. It throws JS errors.

//Creating shaders.

var f = new FragmentShader(source);
//Creates a fragment shader from source.

var v = new VertexShader(source);
//Creates a vertex shader from source.

//Compiling GLSL programs

var p = new ShaderProgram(frag, vert);
//Creates a shader program from the shader objects 'frag' and 'vert'.

var p = new ShaderProgram(file);
//Loads a shader program from a 'shade' file.
//See https://github.com/FlyingJester/TurboSphere/blob/master/bin/Release/system/shaders/system.shade
//And also https://github.com/FlyingJester/TurboSphere/tree/master/bin/Release/system/shaders
//For what that looks like.

//Setting and getting shaders

UseShader(p);
//Sets 'p' to be the current GLSL shader.

UseCompositeShader(p);
//Sets 'p' to be the current GLSL shader used for compositing (when compositing is enabled).

var p = GetSystemShader();
//Gets the system shader program. This is the one used by default.

var p = GetSystemCompositeShader();
//Gets the system shader used for compositing. This is probably, though not necessarily, the same program as the system shader.

var p = LoadSystemShader(file);
//Loads the .shade file 'file' from the system/shaders directory.

I'm still working on setting vertex attributes and uniforms from script. See https://github.com/FlyingJester/TurboSphere/blob/master/bin/Release/system/shaders/system.shade and https://github.com/FlyingJester/TurboSphere/tree/master/bin/Release/system/shaders for what .shade files look like. There will be more parts to them, once you can set uniforms and vertex attributes, use geometry shaders, etc., from script.

I could've sworn one of FBNil's last SoundEffect API changes was the ability to craft a sound from raw sample data...