Cool news:)

About the rendering. I could not see rectangles and circles drawn in my game. Font was okay. But it will be solved with the new plugin anyway

It probably has to do with colors, surfaces, and images being broken. The only reason 0.2.3 doesn't segfault all the time is because TS_Color is such a simple structure that as long as the address that is claimed to be a TS_Color is given doesn't hit non allocated memory, anything can be read as a TS_Color. But all colors given as arguments are as good as random colors.

Pretty much, the graphics plugin in 0.2.3 is broken. It doesn't work, and when it does work, it was random chance that it didn't segfault. I'll make a 0.2.4 release soon (tomorrow?). It will have the last version of graphicSDL, I think.

And at this point, I'm a little sad. Using OpenGL takes some of the fun out of making the graphics plugin--it's so useful! I don't have to reimplement every algorithm for every graphics primitive! Count me among the OpenGL believers. About three hours work, and I've already reimplemented about half of graphicSDL, which took over a year to make. And it's hardware accelerated as well.

Haha, that's great!

Maybe I'll try making an OpenVG (or MonkVG) plugin at some point for hardware-accelerated vector graphics. (Vector graphics games are something I've been interested in.)

I've been thinking about vector graphics, too. It would be nice to have them, although I doubt they would be used as often as normal images.

Also, using OpenGL makes TurboSphere much more Turbo. I tried out a naive map engine system, which got about 500 FPS for a (16x64)x(16x64)x(1 layer) map at a resolution of 640x480. It gets over 2000 FPS with the same map and resolution using OpenGL, and I'm just using immediate mode--the map engine sounds like a great time for VBOs, particularly once more map layers are added.

The GL plugin is going quite well.

I originally thought that I would also have to completely replace any code in the other plugins that does blitting. While this is still a good idea, it's pretty simple to keep them the way they are and expose an SDL surface blitting function to them. In fact, I already did that with the graphicSDL plugin, although it was not necessary back then.

Already, I've got blit masking (for any blitting function that works so far), all the old blit functions I had with SDL plus transform and rotate blit, and all the old primitives plus polygons and triangles (and all the gradient versions of them), and all with wonderful hardware acceleration. I see now my impression that OpenGL was going to complicate things was completely incorrect.

Fortunately though, all the time I spent making the functions for graphicSDL actually wasn't wasted. At least some of it will still be used in the software rendering of the SDL_GL plugin for the surface objects.

I take back anything bad I said, directly or indirectly, about the OpenGL plugin for Sphere 1.5, as well.

Does the OpenGL plugin for TS fix the off-by-one errors in 2X scaling mode? That's my only issue with it in 1.5, it causes one-pixel gaps to appear between adjacent objects.

It might, it might not? I will check. I remember that happening, and it was annoying. And if any such problems are found I can surely fix them.

It's of no code relation to the Sphere OpenGL drivers, so I'm going to say (before checking) that it doesn't.

Oh, I misunderstood before. There are no scaling modes yet, but considering how I'm doing this I don't expect it to have that issue.

Going through the code, I found out that I've missed another memory alignment optimization to use with V8. All built in object member functions have easily had their function call overhead cut by three quarters, since we can now rely on their holder objects to be aligned in memory (and treat them as such).

I've actually got the entirety of the Image object and member functions finished now, including saving images (and surfaces) as BMPs. I'm working on getting PNG support for that as well, but saving PNGs isn't a part of SDL or SDL_Image, so that isn't nearly as easy. Ideally I'd like JPEG and TGA support too, but that's not as important.

And except for circles, all the old 2.2.1 primitives (plus a quite a few more) are working, and now all have their Gradient- and Outlined- companions. Once I unify my older surface code with the new OpenGL system and I get the other plugins working with OpenGL, I'll make a release. A big, beautiful, high-performance, amazing release.

Once I unify my older surface code with the new OpenGL system and I get the other plugins working with OpenGL, I'll make a release. A big, beautiful, high-performance, amazing release.

You mean one that I can port Spectacles over to? :-)  That'll be nice, finally being able to get off of the five-year-old 1.5 engine!

Well...no.

There's no map engine yet. I am glad I waited to properly make one until I went OpenGL--I've got some ideas for how I can use all this modern technology, it should be very efficient.

But no map engine yet. Also, no sound either. But both will exist eventually (probably the map engine sooner, too).

The sound I could do without; it's still pretty early in Specs' development process.  But yeah, the lack of a map engine is kind of a dealbreaker.  Oh well, no need to rush, better to take your time and do it right than push out buggy code as a release.  I should know, having had plenty of experience with that--I've been working on the Spectacles Saga since 2006 at least! ;-)  Well, not the programming, but other aspects of it (story, characters, etc.)

As for OpenGL: Isn't it nice that pretty much every processor has a GPU built in now? It's finally viable to make a 2D game that relies on hardware graphics acceleration without having to worry if it'll run on a low-end machine.  Even the cheap AMD APUs like the crappy E2 processor in my all-in-one desktop are worlds better than the onboard graphics of a few years ago. I can actually run 3D games at decent settings on it!

Wooohoooo can't wait for that awesome release Even without mapengine, sound and circles it will be super nice to have something to work with. Proper transform/mask image support makes 90% of a game </hype>

transform and masks now work...and are HARDWARE ACCELERATED. I'll probably get Circles (likely slow ones, but circles nonetheless) working before the release.

I agree, one thing that had been irking me about TurboSphere for a long time is the lack of transformBlits.

For the map engine, as with just about everything else, going hardware with the graphics has actually made it easier. Much easier. And I'm running out of other things to do, so I'm going to have to just go ahead and build it pretty soon!

On another note, I'm kind of thinking that it would be cool to have a way to set the default color mask for images and surfaces. In fact, I kind of already do it that way internally, except that the mask is always full. Just:

Code: (javascript) [Select]

image.setColorMask(color_object);
//and the corresponging
color_object = image.getColorMask();

It would be dead simple to do, and this already exists for fonts and such. So I think I shall add it.

Awesome progress!

When do the network functions fit into your timeline? Those were always one of Sphere's strong points; not many other 2D engines have that functionality (LӦVE doesn't have it, Flash can't do it without some server stuff).

I may do networking over this coming summer. I don't really have any set plan for adding networking just yet, but it does have the advantage of not needing relying in any way on other plugins, so it could be added any time.

I do know that I don't really plan on using SDL_net, unless I look at it and marvel at how useful it would be for TurboSphere.