You make me want to work on my sfml variant again.

Neat progress btw, I love the idea of using a msgbox for error messages. I can't easily do that in SphereSFML without adding some nasty dependencies, so if I were to do that it would be more of a custom message popup box. But errors still won't be selectable.

It's not too tough to add what TS has (on Windows and in C++ at least, just a small Win32 call). But to make the text selectable seems to be a ridiculous amount of work without bringing in GTK, QT, FLTK, or something similar, which I do NOT want to do with the main engine.

I've commited all the new changes to TurboSphere on Github. It's good to see the engine being at least very close to as stable on Windows as it is on Linux. I'm still getting some weird crashes related to V8 calls before script execution starts, but I'm not too worried. Either the cause will become clear in time, or the change to a newer V8 will make it clear (or just fix it without me knowing why).

I've been working on the map engine (again, I know...I keep saying, it's one of the most sophistocated and complicated parts of Sphere), and I've made some decisions that I think will make it much easier to develop it for TurboSphere--easier for me, anyway. I'm seperating out the functionality into a tiling and display engine (this will probably be the basis for sprite batches later, and be more tied to the graphics plugin), an entity and person engine (which will have stronger ties to the input plugin), and a physics and obstruction engine (possibly pathfinding, and exposing obstruction/hit detection features to script). I'd like to at least make it possible for other plugins and scripts to call just these parts of the map engine without needing to invoke the whole thing. The biggest reason I want to do this, really, is that it will help me make sense of the whole thing and build a cleaner architecture and implementation. It's too overwhelming to tackle the whole map engine as one piece!

I also like the idea because it will make the whole system less monolithic. You would, for instance (and purely theoretically at this point), only need to replace the physics and obstruction engine to have the map engine work for sidescrollers, or (very very theoretically) only replace the display and tiling engine to make it 2.5D (hardware 3D).

I like the fact you split the functionality up. I did the same with my engine but did not expose its functionality in code.  Splitting up the tiling I think is a great way of making it flexible. I want to add an isomorphic engine to my tiler. But right now I've been focused on emulating default sphere. It gets hard when trying to get the systems to agree after you,  say teleport to another map. Even vanilla sphere gets it wrong. I know from having done the ld comp and noticing all kinds of strange behavior with how maps load depending on how you call the teleport code.

Good ideas, Good progress!

If you are still interested in developing sphere-sfml (no judging from me about any hiatuses! I've spent longer stretches away from TurboSphere than I'd like to admit), maybe we should make a new 'Feature Request' thread, but more new-engine oriented. Of course, for a lot of new features, editor support would likely be important as well.

Once again, the map engine seems to prove the biggest obstacle to progression of Sphere. I personally hate how monolithic vanilla Sphere's implementation is myself; it doesn't even split the updating and rendering to separate threads!

I still dread how much work it would actually take to make a usable map engine in the Web Sphere variants :/

Once again, the map engine seems to prove the biggest obstacle to progression of Sphere. I personally hate how monolithic vanilla Sphere's implementation is myself; it doesn't even split the updating and rendering to separate threads!

I still dread how much work it would actually take to make a usable map engine in the Web Sphere variants :/

To be fair, splitting updating and rendering into separate threads tends to be harder than it sounds.  You don't want to render in the middle of an update, which means you have to synchronize constantly, losing most of the benefits of multithreading.  From a compartmentalizing standpoint it makes sense, but it most cases it doesn't actually improve performance and may in fact hurt it--especially in a multi-core environment where the constant synchronization bottlenecks both cores.

I'm not really sure how much threading would add to the update and rendering threads. I haven't tried, mind you. But it's complicated enough for me already.

Conceptually, using modern OpenGL or DIrectX would achieve something similar to threading the render script. And that's what I plan to do, and why the map display engine will also function as a sprite (or any kind of drawing, really) batch engine.

The configuration utility for TurboSphere is up on github. It requires T5 (included in TurboSphere) and FLTK 1.3. I'll put win32 binaries up once I actually make them.

Currently it only handles the video configuration (just fullscreen and video scale) and some TS specific configurations. The TS-specific stuff you probably will never want to change--it's the default sgm name, the startup folder (that you may actually want to change for releasing games--but TS doesn't care about that value yet), and the "game" function name used in script.

So I forgot, are you going to store graphics options with the game files?

I want to propose a standardization for a .sg2m or .sg2 or whatever format that is a second version of the sgm. Built precisely to hold this kind of data:
1. Author
2. Description
3. W x H
4. 2x or 1x (scale)
5. v-mode
6. language
7. etc

But notice my engine can't have the same v-modes your engine has, or another engine uses a different language. So, we should use XML or some kind of non-binary (scalable) data type that can store these properties. Kinda like this:

Code: [Select]

<game>
    <details>
        <name>The Awesome Game!</name>
        // ...
    </details>
    <sound>
        <volume>100 or 1 or 255</volume>
        // ...
    </sound>
    <graphics>
        <scale>2</scale>
        // ...
    </graphics>
    <input>
        <up_key>42</up_key>
        // ...
    </input>
    <networking>
        <use>F or False or 0</use>
        // ...
    </networking>
</game>

(notice the above is a sketch)

Then we can expose methods through code so your game can modify it's own data. This way you can put custom stuff in there. Or you can modify existing stuff, thereby making it possible for games to do interesting things to their own sgm (without the engine wiping it).

I know we tried this once before, but we didn't take into consideration the configuration options stored separately into the sgm. (Which is why I propose an sgm 2.0 type format).

I'm a little unsure if I really want XML in particular. I would like to use an INI-with-sections format (which TurboSphere already uses), but a more modern markup language may be better. I'll have to think about what I really want for that. XML in C++ is not all that much fun--but it could certainly be worth it. Maybe BML or SGML...or XML, I'm not really sure what the best option would be yet. It is hard to go completely wrong with XML.

The way I worked out the per-game scale and filter idea in was for each game to optionally have its own engine.ini and system.ini files whose values would override the main ones. But that is fairly ugly--it's designed to be simple if you were a Sphere 1.x user, not to be a good idea on its own merits. And I think that I removed the code in TurboSphere that checked for this at some point. TurboSphere gets some of this information from the engine.ini file (note that the one included with TurboSphere has stuff Sphere wouldn't use), but this is NOT an ideal solution. Just what organically happened as I developed TurboSphere.

I'm all for a new S2GM (Sphere 2 Game Meta?) format. I'll give this whole thing some thought.

As far as values to hold, here's what I'm thinking:

1. Author
2. Description
3. WxH
4. Scale
5. v-mode (what is this?)
6. launguage
7. Known usuable Sphere version
8. Things to disable (plugins, networking, maybe other stuff)

It would be good for the possiblity of engine-specific and version-specific settings and setting overrides.

5. v-mode: in Sphere you could choose a filter. I think that's a better word, haha. (though I don't think sphere-sfml will have this anytime soon, but it is possible via shaders (and be nice and quick too)).

I wanted xml or the like so it could grow naturally. If we lock it down to a "this must be this" format like aegis did for all other sphere types then we lose the ability for each engine (namely yours and mine) to add their own unique things to it without breaking it for the other engine if you so choose to switch. So a modable, organic settings file for each game.

For SGM v2 I'd personally like to have the extension .sph or .sphere on the game file. XML, BML, or INI format is fine by me but it should stay consistent and DEFINITELY have the SGM format version tagged in the file somewhere for later extension.

I'll start an official Future of Sphere thread for discussion.

(edit: done)

Interesting idea. I also like INI more for this; it's easier to read and modify even for non-techies. Maybe look at dosbox.conf for a nice example of a well-constructed INI file.

Regarding v-mode, I would name it video-filter instead. v-mode is too reminiscent of the v-blanking or v-sync functions, if you ask me. Also, a fullscreen option of course.

Just thinking about it, I would like to expose things like the resolution and scale values in the SGM file to script, both for reading and writing, so they could be edited and saved in game (saving your resolution and scale is pretty standard for games, after all). Same for v-sync, and probably the filter as well.

I will probably do this by extending the 'game' object (the kind returned by GetGameList) to have these values in read/write mode, and adding some function like GetCurrentGame() that returns the current game.

I have fixed what I consider the longest standing and most severe flaw in TurboSphere.

I don't know if anyone has seen this happen, but TurboSphere does NOT validate engine-defined object types. You can segfault 0.3.5 by passing anything as a parameter for a Color, Image, Surface, etc., that is not what TurboSphere expects. Except for Colors, actually, since they are so small that most any object passed that has associated C++ data can be read as a Color.

But doing that sort of thing would cause a segfault 99% of the time. Or at least it did. It doesn't now.

I've improved the graphics plugin performance. I've removed two of the mutexes (the ones that control how the surface rendering thread operates) and replaced them with atomics for signalling. This improves performance by about 10%, and fixes the recent issues I've had with slow startup on Windows (as in 500 ms before, not even noticeable now).

I could really improve performance by caching the hardware textures that surfaces generate when you blit them, and reusing them if the surface has not been modified since the last blit. The simplest way I can think of to do that would be for the surface thread to mark the surfaces as 'dirty' if they are the destination of any operation it performs, and the function that blits surfaces to the screen generate a new hardware texture for the surface if it is marked as 'dirty' and then unmark it, and to just use the surface's cached hardware texture if it is unmarked.