For some super useful cross-platform abstraction, I highly recommend the nall (and phoenix for GUI) libraries by byuu. Even command-line apps benefit from it!

@Radnen: GetFileList() defaults to the save directory and I haven't given it the ability to move to another directory just yet. Within that limitation, it works fine for me. Filesystem access isn't done yet (and it's one of the things I'm working on at the moment).

@Neo: I've seen Phoenix before (and I always take Byuu's stuff very seriously). I'll have a look again
Also, are we ever getting the long lost [js] tags back?

EDIT: Just saw your other post. Sweet! It's been a long time since we had that!

EDIT EDIT: I've added a TurboSphere Function List. The one of SourceForge is not entirely factual, but I rewrote it here while consulting the one and only true authority on what functions are in TurboSphere right now, the TurboSphere Source Code (tm).

Binaries for TurboSphere 0.2.2 are here!

New:

- GetFileList works as expected now.
- WindowStyles now draw their backgrounds, and support all the background modes from Sphere 1.5.
- Fixed a GradientRectangle bug where the rectangle is one pixel narrower than specified.
- Fixed Line bugs where when the x's or y's are the same it is draw one pixel off.
- Added File.read, write, flush, and close. Long live T5!
- Fixed a couple bugs dealing with some primitives changing the clipping rectangle back to the whole screen if it was previously set as something else.
- WindowStyle loading and drawing is marginally faster.

Known Issues:
- Negative windowstyle.drawWindow widths or heights cause hard crashes.
- Passing a string with a '\' in it to filesystem functions (especially GetFileList) may cause errors (but hopefully not crashes).
- TTFFonts still leaky.

GetFileList is something I'm worried about. It has a good chance to cause crashes. But I've given it a bit of testing, and it seems pretty resilient so far.

64-bit Windows Binaries have arrived.

This release (which is otherwise identical to win32 0.2.2) contains a couple more libraries that allow jpegs and tiffs to be used as images.

Nice, I think it might be even faster. Now, could you get started on the text functions?

Font.drawTextBox() and Font.wordWrapString(). If you first do the latter, the former would be easier. Also add Font.getHeight() and try to fix Font.getStringWidth(). I'll attach the font it wasn't quite working with.

I've already got the backend for wordWrapString going. I've been working on the fonts in general lately.

I'm curious to see where getStringWidth isn't working right. At this point I kind of suspect it has to do with my implementation of rfn reading not being quite accurate to how the editor(s) create them (it was derived totally from the internal/font.rfn.txt doc and the system.rfn file).

OK, I've got getStringWidth fixed. It was a silly mistake, and was only visible from script, which is why I didn't notice it while making up the wordWrapString guts.

In lieu of all these problems, like my experience with getKeyString, I've made an executive decision. The use of V8 is not helping make TurboSphere fast, reliable, or stable. In fact, I have come to the realization that using a scripting language is just a limitation to game making. So, I will make TurboSphere use the FAME library instead of V8 or even a JS engine at all. FAME lets us use a much more tried and true language for making games. That is, 68k assembly.

The 68k processor was used in the Sega Mega Drive (aka Genesis), Commodore Amiga (which was groundbreaking in terms of graphics and sound), and the Neo Geo, which is still in use today. To best facilitate the creation of games from the 16-bit and early 32-bit generation, the best tool would be the same one used in the games of that time period.

By simulating a machine using this processor, and exposing the host machine's graphics and sound hardware, games can be made with the elegance of the era Sphere is best at reproducing, and still provide the graphical horsepower of a modern computer.

To see a working proof of concept of the new TurboSphere:Link!

I have a general question about turbo sphere. To be honest I did not follow the development of turbo sphere for a while, but now I realized it is really worth a try to do something with it. But I learned from the past that it is a bad idea to rely completely only on one engine. ( No update for Kyuus Sphere 2 for ages and I was really confident to continue my game with it :/ Currently it seems it was a mistake going so early in that direction )
So I think about writing a good stable code foundation for Aquatis in JS. It has some pros:

I can reuse some old code parts from the old demos.
If I keep my code clean enough, it will be easy to port to other engines using JS.


For the graphics layer in turbo sphere: How are the graphic plugins implemented? Is there still a GL implementation? Is it possible to boost performance by combining draw calls by drawing a lot of rectangles using the same texture? For that a drawTexturedRectangle function would be necessary, right? The low level implementation could then sort rectangles by texture and draw them all at once.
This would help with particle systems and self implemented map engines or similar stuff...

Or I got something completely wrong^^

Feels nice to have the forums back, btw


Haha, first login and I got fooled xD

Hey Metallix! Long time no see.

There doesn't exist a proper GL back-end yet, although I do plan on making one (in conjunction with SDL 2.0, when that is finally released). It's very possible for one to be created, with the new plugin system.

Limiting the number of blits (and certain primitives) doesn't help much with speed in TurboSphere, unlike Sphere. Since I'm using SDL's 2D at the moment, the speed of any blitting is very much dependent on the number of pixels to be changed. There would be times that blitting onto a surface and then blitting that surface to the screen would be faster. For example, when there is a lot of overlap of the primitives or textures being blitted to the surface, and the entire group will need to be blitted again.

That might change later (and probably will with other graphics back-ends), but that's how it works right now.

And I would consider TurboSphere pretty safe to target, since by design it is meant to be very close to Sphere. Any Sphere game code should be pretty easy to use in TurboSphere, and the opposite should also generally be true. But at the moment, I would also say that if you intend to eventually TurboSphere, just keep using Sphere for now. The only things that are different (besides TurboSphere still lacking a majority of Sphere's functions) is that TurboSphere objects use true constructors. But even then the arguments to, for example, "new Color()" is the same as the arguments for "CreateColor()".

lol at the F.A.M.E. thing, that was really quite funny.

BTW, since you mentioned that objects are created with new, e.g. new Color, does that mean their prototypes can also be extended?

Re targeting - it's my expectation that TurboSphere will reach at least parity with Sphere v1.5 API- and performance-wise soon (I would hope midsummer at the latest, but this is essentially a volunteer effort by one person and real life does get in the way), and once that happens I will be more than happy to give it a proper go on Mac (Snow Leopard, mainly b/c Lion and later piss me right the fck off) and eventually recommend using it as the engine to package over basic v1.5.

Re TS API - you can make the API whatever you want, as long as there's a shim of some sort to existing API. The shim can even simply be a system script that gets packaged with the thing if you don't want to (or can't) build in the aliases easily.

Haha Jest, good one on the FAME library.

BTW, since you mentioned that objects are created with new, e.g. new Color, does that mean their prototypes can also be extended?

If you can't, I meant you to be able to.

Although now that I think about it, I do believe that for a long time I haven't had the tying logic for the constructor and the prototype (and so I think the prototype has some horribly mangled name in JS). It interfered with something I had when...something was introduced in V8, and I never put it back. Thanks for reminding me, it's really quite simple to do.

So, what happens if you do one of the following?

Code: (javascript) [Select]

var c = new Color(0, 0, 0);

Abort(typeof c) // ???

Abort(c instanceof Color) // ???

Abort(c.toString()) // ???