It's two things:

1. A large texture usually in a power of 2 format (but for 2D games it does not matter).
2. A list of rectangular bounds for each image.

Drawing an image means drawing portions of the one large texture to screen. This is really fast since you are sending one texture to the GPU even if you draw hundreds of unique images from it. Imagine using it for each character in a font or image in a spriteset, or tileset... Now you see the speedup.

Ah, so it's basically just a fancy word for a sprite sheet.  I guess it threw me off seeing the term "texture atlas" used for this concept, seeing as my very first exposure to sprite/tilesets was with RPG Maker, which uses the "single image tileset" as its native format (compared to, say, Sphere's formats which store the images independently).  So because of that when I see the word "tileset" or "spriteset" I automatically imagine it as a single image, without needing a separate term for it.

Apparently a lot of what I am doing is done in software for 8000m series NVidia cards, though. It was faster to just cache things than to use atlases before.

But it should be even better when I set up string caching.

The fewer GL state changes (and calls in general), the faster. I'm not sure how you've been doing it, but I've been uploading the textures first thing and just leaving them all resident in graphics memory until shutdown or when the JS-side object is freed. But still, this means only one on-GPU memory access, and many fewer state changes.

EDIT: As it turns out, even if you try and change the state to a new texture, as long as it is the same as the previous texture there is only a miniscule performance hit (as opposed to the monumental one of actually changing textures). At least with the AMD fglrx OpenGL library, but given the abysmal quality of fglrx I'd be shocked if this wasn't totally standard.

On the one hand, I've been playing texture binding fast and loose in TurboSphere and never unbind a texture, just bind a new one when I need a texture (unsafe in theory--I've never been bit by it, but it is faster). I imagine this may not be the case if I actually unbound each texture at the end of each procedure. But still! Why was I never told about this!?

So here's a question.

If I added vector-graphics support, would it be useful? I'm mainly thinking about rotating and zooming images. It would certainly not be used nearly as much as raster images, but I can think of cases where I ended using a bunch of procedurally generated graphics to replace a raster image, and a vector image would be at least as useful.

By vector graphics support, do you mean engine API to load vector formats like SVG and blit/transform/whatever?

Yes.

Probably just using the same API as images, but without the ability to manipulate the data in any way (at least to begin with), not even turning to surfaces or images. Mainly it would be blitting, rotate and zoom blit, and blitmasks.

I will soon update the V8 used by TurboSphere to 3.21. Once I do, I believe I will begin the arduous process of backporting about six months of work to Windows. I need to work out why there are so very many crashes in Windows right now (or at least there were last time I checked, but I doubt that changed), and almost none in Linux. A very frightening state of affairs, but considering that TurboSphere was once quite stable on Windows certainly not an impossible task. Plus, one of the most significant problems on Windows I was able to directly trace to SDL2, which has finally been properly released in between then and now.

The new version of V8 will have the advantage of being able to seed the builtin random number generator (and redefine the entropy source!), and the new version also contains the functions needed to gracefully and elegantly change games while running, and to properly handle termination on errors (instead of only terminating the specific script that threw the error, as TurboSphere does now). Hopefully the release will support startup games--I've already modified the engine to allow for it, I just need to have the right functions from V8 to do it.

I must say that in the space between 3.14 and 3.21 the API of V8 has been vastly improved. Many utility functions for embedders have been added, and it's beginning to resemble the functionality that (from what I gather) SpiderMonkey's API has.

I've added Abort and Exit. I don't know why those weren't some of the first functions I added...I guess I was too excited by using SDL and SDL_ttf, and wanted to see something more interesting.
I've also added the rawfile and bytearray functions, and added a couple utility functions to T5, several TTF functions, more sound functions (and a reworked sound plugin), proper RequireScript and EvaluateScript functionality, reconfigurable game() and game.sgm names via config file, the ability to point TurboSphere at a file to be used as the game.sgm in addition to a folder holding a game.sgm, fixed most crashes relating to trying to open unavailable resources, and a bunch of graphics primitives. I'd need to go through the current TS API page on the wiki to know exactly what is new.

RawFile and ByteArray are now fully implemented, complete with MD5-hashing.

I'm still waiting for V8 3.21 to be branched. It seems the new version will finally support bitwise negation! It also looks like more work has been done to get V8 to compile with Mingw, and compilation with MingW64 has been achieved. I'm excited!

All MapEngine related resources can now be loaded and accessed through script. Tilesets use texture atlases. Scripts embedded in maps are now read and compiled by V8 upon loading the map. So the MapEngine is back to the level of functionality that it had when CodeBlocks bugged out on me over the summer.

Images and surfaces can now also be saved as PNGs and TGAs (with or without RLE compression). Looks good.

I've update TurboSphere on GitHub to reflect all the new stuff. It won't work for Windows just yet, I still need to backport the additions to T5 and the scriptfs plugin first. But it works quite nicely on Linux (and theoretically OS X).

https://github.com/FlyingJester/turbosphere

Awesome work, dude. Really need to play around with this more, but alas, time...

I'm working on a GUI configuration and information tool.

I'd like to use Byuu's Phoenix, but it seems any guide whatsoever on compiling it has vanished since Byuu's site was reborn. Just guess what seems to always pop up when I try to google it!. I'd really like to use C or C++, because that would make it quite easy to list the script functions that a given plugin provides, as well as use T5 to read and write the config changes (which woudl automatically ensure that TurboSphere and plugins could read the resulting configuration.

I may end up creating a new shared library with Java bindings to call from the plugins, but I'd rather not do that--this doesn't really deserve a new library, although I wouldn't mind adding Java bindings to T5. It makes me wish I knew more about GUI programming in a language other than Java or Visual Basic.

It wasn't Wayback Machined? Boo.

I'll come up with a quick Windows MinGW+MSYS compilation guide shortly. I pretty much just copy the same Makefile and Makefile.win I made between projects since I came up with one that works.

Update: here's a thread I just wrote also has a link to byuu's latest projects' sources.

I'll have to give that a try.

I don't think I mentioned this, but on Linux x86_64 you can place the AMD libm shared library in the same directory as the TurboSphere binary, and TurboSphere will automatically use AMD's libm for its software graphics math instead of the system libm. It still works perfectly fine without amdlibm (you'd never even know it could use it unless you looked at the source), but I have found a slight speed increase from using it on my AMD laptop.

Interesting things happen when you being using integer division, rarely-used TGA features, and OpenGL glReadPixel together.