It's also important to note that most GPU's will optimize for shapes that have duplicate vertices, mostly though occlusion and culling. You've got to push unique or semi-unique vertices through to see real performance.

That doesn't really surprise me.  But of course, the GPU is naturally in a better position to make that optimization if it has all the vertex data on hand, already uploaded.  Otherwise I'm still pushing in all those redundant vertices every frame, making the optimization near worthless.

Honestly all this VBO, VAO, FBO stuff... We could be rid of it entirely if PCs would go to a unified memory architecture, the way consoles have been moving lately.  The GPU/CPU boundary is starting to feel more and more like a relic all the time.  Especially when you consider that most CPUs now have a GPU on-die!

So I ended up doing this in minisphere to create a specific type of shape:

Code: (javascript) [Select]

var shape = new Shape(verts, texture, SHAPE_TRIANGLE_FAN);

The third parameter is optional and defaults to SHAPE_AUTO (meaning Sapphire's behavior). This avoids creating a bloated type hierarchy for such a simple primitive, and seems very Sphere-like anyway.

I have a DirectSound version of the TS audio plugin working, as well as optional 32-bit floating point audio when using OpenAL.
I intend to make the OpenAL and DirectSound versions selectable on Windows.

I should note that I'm still warming up for a Windows release, but right now that is limited to getting the audio plugin (which I use in an unrelated project), and libyyymonitor and libfjnet (from Kashyyyk) working on Windows for now.

And boy...I forgot how silly the MSVC export model is

TurboSphere compiles on Windows now. It crashes in SpiderMonkey when trying to run a script, but it compiles and does not have any linkage issues.

In my adventures, I created a tool that can help make import libraries for Visual C++ when you don't have one.

Ideally, I would compile everything with MingW or Cygwin, but doing so is sometimes broken for SM. This is one of those times. I am using libsndfile, SDL2, and SDL2_image compiled with MingW/GCC 4.9.

I would prefer not to use MSVC simply because it is a total trainwreck of a compiler. It has partial support of almost every standard, but not complete or mostly complete support for any of them, not even C++03. It looks to me like it has a gimpy parser. For instance:

• constexpr functions work, but they literally compile an object file and run its code. There is no JIT for it, like GCC, Clang, and even Sun Studio have. Using network shares like I do, this can quickly make some translation units prohibitively expensive to compile.


• constexpr expressions simply do not work. This is a basic part of C++11, and unless you know that the code is fully compiled and run to get constexpr function results, it seems bizarre that constexpr functions work and not expressions.


• inline array and struct initializers for class members are not accepted. The compiler knows what they are, but tells you not to use them.


• You cannot put immediate initializations of members in template classes, even POD template classes. Since each POD template class instance is effectively a unique class, this is fine in GCC and Clang. Sun Studio tells me it will have it as a future feature. I doubt that. It works in non-template POD structs, strangely.


• It takes sometimes hundreds of parsing passes. So you only see one or two parsing errors at a time. It's impossible for any compiler to parse C or C++ in only one pass, but this is ridiculous.


• In certain circumstances, the old C++03 trick of putting a space between closing '>' of nested templates is still necessary.

I'm not saying that GCC or Clang are perfect. And Sun Studio is at best a curiosity (Compiler-level C++14 syntax support, but still no working C++03-compliant standard library, for instance). They have huge flaws too. I'm just surprised to see that, after three major releases since I last left it, MSVC still has so many issues like these.

I guess I haven't had any real complaints because I use all C.  MSVC's C99 support is similarly abysmal, but at least there it has enough to get by for cross-platform work.  I'll take my sized ints and my C++ style comments and that's all I need...

Honestly though, C++ is just a bloated mess of a language.  It's like if someone took C and then asked a Family Feud survey what features they would want to add to it, and then went and implemented every single one.  Even more so with the latest standards.  And that's just the language--let's not even get into the beast that is the C++ standard library.

C on the other hand gives you a primitive set of tools and doesn't hold your hand at all.  If you should happen to stab yourself with a screwdriver, that's on you.  It's still a better situation, in my opinion, than the huge box of Binford power tools C++ gives you.  MOORREEE POOWEEERRR!

But I digress.  Carry on!

Clang, or MingW would be better for cross platform work. They are actually cross-platform, and Clang and MingW are as powerful, if not more so than MSVC. Particularly since the C compiler in MSVC is considered legacy and was at one point even deprecated.

I've added clipping rectangles to Groups.

Code: (JavaScript) [Select]

var g = new Group(...)
g.clipX = 10;
g.clipW = GetScreenWidth()-20;

// Now when g is draw, it is clipped relative to the screen.
g.draw();

I'm also working up to having actual shaders. Internally, it's fully implemented, but a lot needs to be done for script to get them properly.

I've fixed the text drawing system. And again again, SpiderMonkey is proving better for TurboSphere than V8.

Previously, I was doing all sorts of tricks to limit the number of Images generated. Each Image has an OpenGL Texture, and its lifetime is controlled by the JS engine. In fairly simple tests, repeatedly making up new string Images and then losing them would crash since the GL textures were never released. In some cases, I even could crash OS X by doing this. Sidenote, no laughing at Mac OS X for this. I have found similar ways to crash Windows and FreeBSD+Linux--or at least X11 and Mesa--just as easily and just as reliably. I've yet to crash Solaris, though

SpiderMonkey, however, can keep up with even very large numbers of Images being created. It also ramps up GC'ing when the total number of objects suddenly increases, which works very well in this case. This means it's fine to just make a new image every time you want to draw new text to the screen!

I'd be curious what the results of such a test would be in minisphere.  Duktape's garbage collector is scary efficient.  Ever since I added logging for images, if the image doesn't go away immediately after it goes out of scope, it's gone within 30 seconds.  It blew me away, honestly.

... if the image doesn't go away immediately after it goes out of scope, it's gone within 30 seconds.  It blew me away, honestly.

Or is it rather lazy? Because anything from time, to memory thresholds can cause GC to kick on. I personally don't mind if junk data stays behind for a long time even in GC'd languages since we have so much RAM these days. I think it's only an issue if you get pretty bad memory leaks.

There can be no contention for memory--say the game has been idle a while and suddenly creates a temporary image or two.  Those are finalized within the minute.  Every time.

But yes, with ram being what it is memory isn't really an issue.  The issue is when you're managing more than just memory--in Jester's case, hardware textures.  If the JS engine holds onto scarce resources too long, it can cause issues.

If the JS engine holds onto scarce resources too long, it can cause issues.

I wish the old forums were archived. The original Sphere 2.0 project, headed by Kyuu, started out using V8. When I started TurboSphere, he cautioned me that V8 was unsuitable for precisely this reason. He was right.

I've done a little experimentation, and SM seems to free things that have a very small number of handles very quickly. I think it might depend if all those handles have a single root. I have yet to see a single Image that is lost exist for more than a second, and it is almost instant if I am allocating many objects (which is why I think the GC ramps up with allocations).

I suspect this kind of behaviour has to do with Firefox's reputation of using too much memory. Even though it uses less than Chrome now, and most memory usage nowadays is from using ad-block and its ilk. Mozilla is very sensitive about memory usage now, and it makes sense their JS engine is very efficient at collecting garbage.

I wonder if SM is using refcounting as its primary GC method.  I know Duktape does, and as a result 90% of the time the object will be collected the moment the last reference goes out of scope.  It's really only in difficult cases (circular refs) that things tend to stick around longer.

I believe that SM uses a mark+sweep incremental GC, but I know that they want to change it to be an exact generational GC.

V8 supposedly has a generational stop-the-world GC. You're always reminded when talking to the devs that you should not count on it to run, ever.

...anyways...
So, I enabled the extra warnings flag for SpiderMonkey. It's actually really useful. Stuff like this is printed now:

Code: [Select]

[Engine] Strict Warning in file ./system/scripts/turbo/tileset.js line 198
reference to undefined property i.tex_coords.x1
[Engine] Strict Warning in file startup/scripts/lobby.js line 134
assignment to undeclared variable changed
[Engine] Strict Warning in file ./system/scripts/turbo/font.js line 161
reference to undefined property this.string_cache_size

Everything but Sapphire is working under Windows. Sapphire is having some weird issue where trying to LoadLibrary the binary results in a 193 error. That usually means you are trying to load 64-bit code on a 32-bit machine. But dumpbin claims it is 32-bit, and I do not have a cross compiler on my Windows machine!

A walk through the debugger even shows that Sapphire is partially loaded, and after loading all of the libraries it depends on, they are then unloaded and Sapphire itself is unloaded. If this was GCC-land, I'd guess that one of its dependencies was 64-bit (it is also a LOT easier to check there). But MSVC import libraries prevent this at link-time. Even with my handrolled tool I used to link against mingw libraries, I still examined the dumpbin headers manually, and everything is 32-bit here.

There is a tool to help check dependency and library loading issues, called gflags. Unfortunately, it's considered deprecated by Microsoft and has been removed from the Windows SDK, and there is no real alternative. I'll have to dig about in my old SDK disks to try and find a copy.

I've also got permission to use the Power by Mozilla logo with TurboSphere!

Okay, real talk: how difficult is it to build Spidermonkey?  Last time I used it Mozilla provided pre-built binaries, which was great.  Now apparently I'd have to build the entirely of Gecko, which is... Daunting, to say the least.