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

Re: TurboSphere

Reply #360 –
I've almost finished updating TurboSphere to use V8 3.24. At first I was very annoyed at how much the API has changed, but I'm actually glad it did.

A few things that make embedding it easier in TurboSphere:

- The C++ representation of a JS function no longer returns anything. Instead, the argument object is passed in has a new member, which is set to give the function a return value. This makes exporting the functions from libraries with C linkage much easier in MSVC.
- Everything cares about isolates now. This would normally be used to manage different scripts being executed at once--as in, multiple web pages running their own scripts. But it will make it much easier to have TurboSphere manage the lifetime of JS objects when games are changed.
- Everything is UTF8 instead of allowing ascii. This doesn't really help embed it, it just makes things nicer since I wanted to use UTF8 all the time from the start. So now, TurboSphere fully supports UTF8. I could also make it support UTF16 with just a single switch, but I'm not really sure anyone uses or wants UTF16.
- Persistent handles are impossible to use, but locals and handles work much, much better. Which is good, since persistent handles are a flawed thing.

Re: TurboSphere

Reply #361 –
The changes were big enough that it pushed me to revise the plugin tools. Which is shaping up nicely.

I don't know when I will make a Windows release. I was considering just wrapping up what was on Github and releasing it for Windows, but that actually hits a bug in the old version of V8 that only occurs on Windows (there's a simple workaround...but blah!). So I think I'm just going to keep on pluggin away in Linux, and once I get new V8 all settled in, and the new graphics backend all stabled-up, then I will port it all to Windows. I did backport the missing stuff to build the SPK editor already, so there isn't anything completely missing from either platform at the moment.

And just to be clear, the plugin tools are NOT required to actually make a plugin. You could write a plugin without them at all (getkeystring doesn't use them, for instance). I'm rewriting them to make them more suited toward the current version of V8, and to fix several issues that became apparent with the old implementation. I'm much happier with how it looks now.

Re: TurboSphere

Reply #362 –
I'm also cleaning up the build process. With the new Sconstruct, if you wanted to make a plugin, you would have two options:

1. Go rogue and do everything yourself. Always an option :D

2. Add a directory to the TurboSphere source, in plugins/. Then, if you have a sconscript or a makefile in that directory, just running scons on TurboSphere will attempt to build your plugin as part of the build process. This has the advantage of guaranteeing V8 and T5 linkage that is consistent with TurboSphere, automatically directing the preprocessor to the plugin tools directory, and installing your plugin and any libs you are building yourself automatically (to bin/Release/plugin and /usr/lib64/turbosphere on Linux, and to bin/Release/plugins and bin/Release on Windows).

Re: TurboSphere

Reply #363 –
Man, just to break up the monotony of triple posts I'm going to say good work on the plugin interface. Making plugins easier to create is always a plus, and adding it to the build routine is always nice too.

For my Sphere Editor, I made two libraries: the library for the editor and the library for the Sphere components and plugin handling. In this way I can instead make a new blank project that you can check out to make a plugin. However I have yet to do that, but that is theoretically where I'm going with it. In that way you don't need the full code library of the editor to make a plugin, just a small subset of the codebase.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: TurboSphere

Reply #364 –
I'm getting an APPCRASH when running TurboSphere 0.3.5c (newly downloaded). Problem details as follows:

Quote

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   turbosphere.exe
  Application Version:   0.0.0.0
  Application Timestamp:   527f07aa
  Fault Module Name:   v8.dll
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   5258cbe5
  Exception Code:   c0000005
  Exception Offset:   0014957a
  OS Version:   6.1.7601.2.1.0.274.10
  Locale ID:   1033
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789


The console gets to the [ bmpfontGL ] test with Font.drawTextBox then crashes. The actual engine window seems to have everything the startup tries to draw, though. Let me know if this was a thing that's fixed in current sources, though, or if there's a way I can get you more info for it, thanks!

Windows Server R2 Enterprise SP1.

Re: TurboSphere

Reply #365 –
Huh. That's not something I've seen with 0.3.5c before. But I am quite used to drawTextBox causing crashes.

font.drawTextBox uses black magic. In very certain circumstances, I write to an address I know I shouldn't, but using glibc it always works and MSVC it usually works, and it makes things much simpler. It's a very bad idea, I just haven't gotten around to fixing it yet. That and I can't make sense of the madness that is the code for drawTextBox, so I need to just rewrite it, really.

Try commenting out the call to drawTextBox in the test script, if it runs fine then it's the non-standard stuff in drawTextBox that is failing.

Can I see the output on terminal for it failing?

EDIT: At long last, my old dream of having functions with full specified JS call signatures, and object-orienting the C++ representation of JS types is realized with the new plugin tools.
This is how I imagined the plugins to work all along. I just didn't know enough at the time to make it work that way.

Re: TurboSphere

Reply #366 –
The original output I'm getting:

Quote

[ConfigManager] Info: Fixed plugins: 1
[ConfigManager] Info: Fixed plugins as recorded: 1
game.sgm is the sgmname. We are running in / mode.
[ConfigManager] Info: Opening SGM file startup/game.sgm
[Engine] The main script is startup/scripts/Jest_Main.js
[ConfigManager] Info: Successfully opened script startup/scripts/Jest_Main.js
Plugin SDL_GL_threaded.dll is open.
[SDL_GL] Info: STND was 0. Now it is 0.
[SDL_GL] Info: STND was 1. Now it is 1.
[SDL_GL] Info: Using OpenGL version 3.3.0
Plugins:        1
Plugins:        1
Plugin audioBASS.dll is open.
[audioBASS] Info: Initialized BASSmidi as bass plugin 274726912.
[audioBASS] Info: loaded and initialized BASS.
Plugins:        2
Plugins:        2
Plugin bmpfontGL.dll is open.
Plugins:        3
Plugins:        3
Plugin getkeystring.dll is open.
Plugins:        4
Plugins:        4
Plugin inputSDL.dll is open.
[inputSDL] Info: Event state setup succeeded.
Plugins:        5
Plugins:        5
Plugin mapengineGL.dll is open.
Plugins:        6
Plugins:        6
Plugin networkTS.dll is open.
Plugins:        7
Plugins:        7
Plugin scriptfs.dll is open.
Plugins:        8
Plugins:        8
Plugin ttffontGL.dll is open.
Plugins:        9
Plugins:        9
Plugin windowstyleGL.dll is open.
Plugins:        10
Plugins:        10
[ttffontGL] DrawText Info: Binding string Do a barrel roll! to cache slot 0.
[ConfigManager] Info: Successfully opened script startup/scripts/MJ-12.js

Running Script.

Opened a file as a stream.
Opened a file as a stream.
Spriteset is version 3
This is just a test: 8
[ttffontGL] DrawText Info: Binding string Press Q to just give up. to cache slot 1.
[ttffontGL] DrawText Info: Binding string Do a barrel roll! With TTF Fonts! The mjMap's width is 1024 and its height is 1024 to cache slot 2.
[ttffontGL] DrawText Info: Binding string Attack.ogg's length is 59944, Spider's length is 87272 to cache slot 3.
[bmpfontGL] TS_wordWrapString Info: String This is a text box. These things gave me a bit of trouble, but now they work. I tried to make them lightning fast, which made it hard to debug any problems. But some solid reasoning and carefully spent blood, sweat, and tears, and now it works just pretty good. Sometiems cuts the lines a little early, but overall OK. cached to slot 1.


Commenting out drawTextBox doesn't resolve it, unfortunately. I thought it was the GetMouseX/Y calls, since every so often it runs long enough for me to hear a sound until I move the mouse, but even leaving the mouse alone didn't fix it.

I also optimized the GetScreenWidth/Height calls out of the main while loop in my copy to make sure those didn't affect it.

...
What is the following line supposed to signify and why is that value so high?
Quote

[audioBASS] Info: Initialized BASSmidi as bass plugin 274726912.

Re: TurboSphere

Reply #367 –
The bassMidi value is a unique plugin ID that is chosen by Bass. So long as it isn't 0xFFFFFFFF or 0, the number is fine.

Are there any calls to GetSystemWindowstyle? Those are sometimes buggy on Windows (I thought I fixed, that, though).
 

Re: TurboSphere

Reply #368 –
Quote from: Flying Jester – on

Are there any calls to GetSystemWindowstyle? Those are sometimes buggy on Windows (I thought I fixed, that, though).


Only one and that's called way near the beginning of game(). Commenting drawWindowStyle in the loop doesn't fix the crash.

Re: TurboSphere

Reply #370 –
Kinda; I get the following unexpected output when I define the game() function as the above:

Quote

TS_CallGame error: game is not a function.
Game function done running.


Your short while loop is explicitly in function game() {...} so I don't know why that message should even appear. No APPCRASH, though :/

Re: TurboSphere

Reply #371 –
...Oh yeah. I changed it so that `game` is checked first.

Code: [Select]

function game(){
  while(true){
    FlipScreen();
    GetKey();
  }
}


EDIT:


The new plugin tools up and running. Updating the graphics plugin is the big task still to be done.

The new plugin tools and the new usage of V8 in the engine makes TurboSphere able to start different games and restart the current game at runtime. Having looked through Sphere's source, it looks like that sort of thing was a lot easier back when JS was interpreted. And V8 wasn't really meant to do this anyway. Chrome puts each page in its own process, and never reuses a V8 instance. But the new requirement of Isolates and increases 'security' checks (page identity in Chrome, game instance in TurboSphere), and much, much better identity of handles makes it much simpler to do.

Also note that V8 doesn't need or accept the flags to enable typed arrays anymore. That's because they are standard now!

Re: TurboSphere

Reply #372 –
The new version is still coming along. I'm putting the new graphics core into a new graphics plugin, using the new plugin tools. Everything new and shiny!

The new graphics plugin will actually be callable from other plugins a lot like the Sphere video drivers are in Sphere. I needed to see that in action, writing FJ-GL, to see the advantages that a more detached API could provide. The API will be closer to the metal than Sphere's (the plugins still must agree on OpenGL), but it will be more useful than what I had before.

I've added the ability to dynamically switch between multi-threaded and single-threaded surface rendering. It doesn't really have a good use, but I'm working on adding more threading, and it will be important in other places and other threads to be able to do that. While I'm at it, I've been moving the surface renderer over from my own homemade concurrent queue (which uses a mutices) to use the Intel Thread Building Blocks or the Microsoft Concurrency Library (both options available at compile time), which are atomic spin-lock based (faster, easy to remove busy-waits). Obviously TBB is necessary on Linux, and MSCL is included with MSVC so that's easier on Windows. They are, in the case of concurrent container classes, API compatible.

I've also worked out a file type for scripts that contain embedded V8 compiler data. It's basically IFF-style, lacking a resource map, with specific magic numbers for script text and V8 data. It also hijacks a reserved field to store V8 version data (this is important!). It's extremely simple to read this kind of file, check if there is V8 data in it, and if not generate and append V8 compiler data to it. This speeds up subsequent compilation of large and complex scripts (this is a part of how V8's snapshot works). I'm using this for the new graphics plugin, which defines a couple functions in embedded scripts.

On a different note:
For laughs, I tried to compile TurboSphere for Raspbian on the Raspberry Pi. It looks like all it needs is more OpenGL ES support. SDL2 has code just for the RPi, Bass has an ARM-Linux version that works on Raspbian, and V8 has ARM and Linux as primary targets. TS already has some OpenGL ES support, added during my cursory looks at Android. I've been adding space for it now as I work on the new graphics plugin.

Re: TurboSphere

Reply #373 –
Whoa. That's hardcore modularization, dude!

I look forward to trying out an updated Windows build with Flappy Sphere :)