Skip to main content ↑ ↓
Topic: TurboSphere (Read 2436713 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: TurboSphere

Reply #585 –
It is super easy on Unix, but a little difficult on Windows.

You don't need to fully build Gecko, although you do need to clone it and run its configure script.

Here is how I do it:


  • Download the MozBuild tools and Cygwin, as according to the Firefox build document. This isn't necessary on Unix

  • Clone https://github.com/mozilla/Gecko-Dev

  • On Windows, add the MozBuild to path

  • From the gecko root, run `./mach configure'

  • cd to js/src

  • ./configure (I enable all the tracing, debugging, and disable some other stuff relating to the NSPR and icu)

  • make (mozmake on Windows, gmake on Unix/not-Linux)



Now your headers are wherever jsapi.h is in js. There is no strong distinction between the Gecko-SpiderMonkey interface and the general embedding interface, so anything in the dist directory is fair game (and any exported symbols in general). You should have built (lib)mozjs-(version).(so/dylib/dll) somewhere in the dist directory.

You will need the mozglue and nspr(4) libraries on Windows, and icu as well. You cannot fully disable icu as a dependency, but I disable a couple features of it so that I don't need all three icu libs.

Re: TurboSphere

Reply #586 –
Ugh, those dependencies hurt.  What happened to the days when you just had to distribute js32.dll and call it a day? :P

Re: TurboSphere

Reply #587 –
That was when you didn't want off-thread GC'ing and asynchronous operations, UTF-8, or JIT.

There is a project to remove the hard dependency on NSPR from SpiderMonkey. This is mostly because SM only makes use of a small portion of the NSPR.

All things considered, two libraries built as a part of the build and supplied with it, as well as ICU (your choice, system or private build) are not bad at all.
The number of dlls in the same directory as a program means nothing.

Re: TurboSphere

Reply #588 –
Hey what can I say, I like my self-contained executables. :)  (plus  I'm OCD so there's that) Mainly I want to avoid a situation like with Sphere 1.x, where the engine and editor are in the same directory and you get to guess through trial and error which DLLs you need to distribute and which can be left out.

Re: TurboSphere

Reply #589 –
I totally agree, but I base what a dependency is on more than just the number of files. I consider Allegro a very heavy dependency. It handles audio, image loading, video, has an entire software renderer...

The same is true of SDL (although less so), and similarly you can compile things out. Someday I want to be rid of SDL2 completely, and call into WGL/GLX/EGL/CGL myself (I've done it before, they have extremely similar semantics). The main thing that stops me now is input handling, which is horrible everywhere except for Cocoa and Android. X input is a total cluster, and Win32 is ridiculously verbose about it, without even offering the kind of flexibility you would think would come with it.

Perhaps one day I will distribute a subset of SDL2, just the input handler imported into a TurboSphere plugin.

I'd rather have three very small dependencies than one all-mighty one. Like using libsndfile and OpenAL, as opposed to just SDL2's audio--why would a sound driver know anything about file types? Why would your graphics library know anything about sound? In particular, why use an audio library when your OS already has one that you're sound library is calling into? That's why I am using DirectSound itself, not OpenAL, on Windows. OpenAL is a part of CoreAudio on OS X, but I do want an ALSA and an OSS backend for the audio plugin, too. OpenAL at least also does 3D audio mixing, which would be very complex using any other backend.

ICU is different in some ways. There is no UTF-8 handling on Windows or some Unixes. Want UTF-8? You need to do it yourself, or use ICU which does it itself. NSPR is silly, though, since Win32 and Posix both have their own threading libraries. Only writing two backends is simple, and I know from experience that Win32 and pthreads are very similar.

Re: TurboSphere

Reply #590 –
Bloat is relative, though.  I cant consider Allegro to be bloat in my case since I touch pretty much every part of it at some point or another.  Plus having a consistent API for everything makes it less likely you're going to make mistakes.  You have no idea how many times I've almost accidentally passed a Duktape context pointer to some completely unrelated library function out of habit.

Also, since I now build Allegro myself, I've compiled out the stuff I don't use (notably, the video codecs and DirectX support).  So I'm very familiar with the concept of customizing my dependencies. :) one of the perks of using open source libraries with liberal licenses. :D

Anyway, I think I've derailed this thread enough.  Carry on! :P

Re: TurboSphere

Reply #591 –
So I figured out the Sapphire issue. If a shared does not expose a shared library main in Windows, no problem, it's not a COM or similar library. But this is an issue when the library is loaded from another shared library that has been LoadLibrary'd. You need to perform a certain call of LoadLibraryEx to get around this.

Excellent error reporting in Win32, as usual :P
 

Re: TurboSphere

Reply #592 –
Quote from: Flying Jester – on

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.




Just wanted to revisit this because I recently read that VS 2015 is supposed to include support for C++11 and C++14.  How complete that support is (the RC is out now), I don't know, but worth pointing out at least.

Re: TurboSphere

Reply #593 –
That's a long time after GCC and Clang, though. C++11 was basically finished in 2008, and GCC and Clang have had support (in some way, under the name GNU++0x) for even longer.

I understand that they will have longer lead-up time, given they don't release as often. But they are trailing by the better part of a decade when it comes to standards support, and they will probably never fully support C99 or C11. Up to and including VS2010, you couldn't even mix code and data declarations.

I've also read that many of my complaints about compatibility are still unaddressed. That post has a lot of back-patting. "Partial Compliance" can also be called "Not Compliant". constexpr still doesn't work right, you still can't have variadic templates (which are very useful!), almost all the new initialization list uses are still unsupported (there's kind of no way to fake that if your compiler doesn't have it, too), and still no UTF-8 literals.

It's better, but from a standards compliance viewpoint, it's still way behind GCC and Clang. It's not a good feeling when you have to change a simple, clear, and concise statement into a more awkward one when you port to Windows.

Re: TurboSphere

Reply #594 –
To be honest I don't find much of C++ to be "concise and clear".  It often feels like C++ code is too verbose to me.  Especially once templates start getting involved.  auto goes a long way towards addressing it, but IMO it's not enough.

Edit: That said, the C99 support seems to be improving as well.  snprintf() is included now, eliminating the need for #define snprintf _snprintf hackery.  Honestly the biggest thing that keeps me using MSVC isn't so much the compiler as the IDE.  In my opinion nothing beats it in that department.  The UNIX Way(tm) seems to be to either do everything from the command line or alternatively, to write scripts to do everything.  If I had to do that on a regular basis, I think I'd go crazy.  I think I've said this before, but I much prefer to spend my time writing code for the app I'm making than for my build tools.

Re: TurboSphere

Reply #595 –
Quote from: Lord English – on

To be honest I don't find much of C++ to be "concise and clear".  It often feels like C++ code is too verbose to me.  Especially once templates start getting involved.  auto goes a long way towards addressing it, but IMO it's not enough.

Edit: That said, the C99 support seems to be improving as well.  snprintf() is included now, eliminating the need for #define snprintf _snprintf hackery.  Honestly the biggest thing that keeps me using MSVC isn't so much the compiler as the IDE.  In my opinion nothing beats it in that department.  The UNIX Way(tm) seems to be to either do everything from the command line or alternatively, to write scripts to do everything.  If I had to do that on a regular basis, I think I'd go crazy.  I think I've said this before, but I much prefer to spend my time writing code for the app I'm making than for my build tools.


It's funny, I feel the opposite.
Once you really grok them, templates are very good. I seriously wish C had templates. They are extremely powerful.
The IDE I find is super slow. Most of my Windows development is almost totally done on a Dell D630. It's super underpowered, but Code::Blocks, Codelite, and Flare (when it doesn't crash =P ) work fine on it, when MSVC doesn't. I understand that it is a good IDE, especially with debugging--lldb is bad!--but it does take a huge amount of resources in comparison to other IDEs.

It doesn't help that CMD.exe is horrendous when compared to any other terminal. I hear it is getting an upgrade in Windows 10, but again I suspect it will be far behind the time compared to Bash, Asn, and the Korn Shell.

I only suffer through this because most folks use Windows.

Re: TurboSphere

Reply #596 –
I won't deny MSVC is slow (you basically need an i7 to get any decent performance out of it), but yes, it's mostly the debugger that I find invaluable.  You can see literally EVERYTHING at a glance, at a level I haven't seen in any other IDE.  The only thing I wish it had?  Time travel. :P. Nothing is worse than hitting a breakpoint and realizing it would be so much simpler to find a bug if you could only step backwards through the execution path...

As for templates, I don't know.  I see the appeal, but I guess I view them with contempt because they're basically a way to mimic duck typing in what is otherwise a strongly (VERY strongly) typed language.  For classes this usually makes perfect sense (vector<> et al say hi, also C# generics), but when I start seeing templates being used to make function overloads and such that's when I scoff.  Too much template code starts to feel to me like Mad Libs as applied to programming. :P

Re: TurboSphere

Reply #597 –
So I just had a question as regards the Galileo implementation in TurboSphere.  I kind of rushed the minisphere implementation so I want to make sure I get it right this time.  In TS, what exactly happens when you call group.draw()?  In minisphere the Group is rendered to the backbuffer immediately like any other primitive (the shapes themselves are batched, of course).  I'm thinking this isn't what TurboSphere does, though, since I've seen you mention "asynchronous" in reference to the graphics system.  I assume it's equivalent to this (Async() in minisphere defers until the next FlipScreen):

Code: (javascript) [Select]
Async(function() {
    group.renderAllShapes(); // fictitious method, renders Shapes to backbuffer
});


Is this correct?  If so, I'll make the necessary changes under the hood for v1.2.

Re: TurboSphere

Reply #598 –
TurboSphere's entire graphics system inherently is asynchronous, and in a fairly different way than what you describe. Long story short, you don't need to do it asynchronously. For TurboSphere (and conceptually for Galileo), FlipScreen simply means you have finished calling the draw operations for a single frame and are beginning the next frame.

Sapphire is based on a set of queues (originally 5 queues, now 3), each representing a frame. Right after you call FlipScreen, so the start of a frame, a queue is chosen and cleared. Any calls to group.draw() then push the groups drawing operation into that queue.
No actual drawing is done on the main thread. A rendering thread chooses a queue to 'draw', and performs all the operations on the queue until an operation occurs that flags the end of a frame (FlipScreen() pushes such an operation). The rendering thread then clears the screen and chooses another queue to draw from.

Considering there are only three queues, and we lock so that we will not draw and render from the same thread at once, this means that we always pick the only queue that is not currently in use. Under perfect conditions, the rendering and engine thread would just cycle through all three queues in order. That's not normally what happens, though.
If the rendering thread takes a long time rendering (which is pretty common), the engine thread will just bounce back and forth between the two remaining queues, clearing and rewriting them.

There have been a couple interesting things I've noticed about this system. For instance, it's vitally important that Sapphire use an odd number of queues. But it has worked quite well. The engine can run at crazy 'framerates', even with large amounts of drawing. The rendering stays responsive since only a few frames can be backed up, and we intrinsically drop late frames without ever having to consciously consider how and when to do so.

Re: TurboSphere

Reply #599 –
Huh.  That's pretty clever, actually.  You basically get frameskipping for free because nothing is ever drawn for late frames, not even to the backbuffer.  The thing that concerns me though is, don't you get frames drawn out of order?  Since you imply the queues are picked essentially at random by the render thread...