Skip to main content


Topic: TurboSphere (Read 162557 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
Re: TurboSphere
Reply #435
I would like to think that I do, in fact, have a partial solution to the issue of feedback in asynchronous engines in TurboSphere.

And that is that TurboSphere is kind of semi-synchronous now.

It works so that the render thread or engine thread 'float' back and forth--one can be ahead of the other--although they can be synced at any time. The real trick I've been seeing is that you always perform syncs on the opposite thread than the one you want to have wait. If you want to change the framerate, you need change the input rate. This lets the framerate stay floating, which is what we really want. Since you know that it will normalize to whatever input you give it (ignoring stutter), you can control it from the engine's main thread.

We'll see what happens when I start doing full scene specifications, but I am going to try something similar. A feeder thread that is throttled, and a render thread that floats freely. The feeder thread is basically zero overhead (much less than the render thread, at least), so the same logic should apply. The engine is already designed to handle what happens if the render thread outruns the engine proper, and the entirety of the render system in Sapphire is designed to be thread safe, so another layer of abstraction for feeding the renderer will be no problem. The number one blocker here is making graphics Groups a fully recursive data structure, which means I need to learn more about multi-pass shaders.

In unrelated news: The Sphere 1.x compatibility script for Images is coming along, as is the primitives script. The translation from the old API to the new one is actually pretty simple, it's mostly just giving each Image object a corresponding Shape and Group, and having separate shapes for each primitive.
Which outlines the difference between the old API and the new one--in Sphere 1.x, you give objects temporary states. In Sphere 2.0, both assets and states are unique and individual objects that are used in combination. An image doesn't inherently `blit', it's a texture, a `shape' is just a collection of points with properties, and a `group' is a series of transformations. You need all three to properly make something happen, they are all persistent but mutable, and you can use them in any combination.
  • Last Edit: August 11, 2014, 05:19:03 pm by Flying Jester

Re: TurboSphere
Reply #436
As usual I am very impressed bro, Keep up the good work :)

Cant wait to start using this :)

Re: TurboSphere
Reply #437
Thanks, that's great to hear!

By the way, I can go pretty far with back compatiblity, or I can not. I'm curious how much you guys want.

I am planning on doing most of Images (Blit, ZoomBlit, RotateBlit, TransformBlit), and some primitives (rects, triangles, lines, points, and circles). Those are all pretty simple to do, it won't take too long to get at least a reasonably close facsimile of the Sphere 1.x API working. After that, I was just going to work totally on the new system. Surfaces are mostly unchanged (the spec is closer to Sphere 1.x than what TurboSphere has ever supported in the past). Everything else will be done, for the most part, as Sphere 1.x API first, and then as Sphere 2.0.

Regarding the map engine, I do want to implement the Sphere 1.5 map engine. But I'm planning on doing it in script, using the new API from the engine to implement it.
  • Last Edit: August 11, 2014, 08:09:31 pm by Flying Jester

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: TurboSphere
Reply #438

Regarding the map engine, I do want to implement the Sphere 1.5 map engine. But I'm planning on doing it in script, using the new API from the engine to implement it.

This, this would be neat to see. My Sphere engine has a fast map engine, but it's done in C# and not JS so it has zero extensibility (like the old engine). It turns out you do not need a very fast map engine, but one that is fast enough. I still need to implement the new proposed Sphere shape/group graphics API (was it called pegasus or something like that)? If so I'll see how Jurassic fares in rendering a real time map engine in JS (it shouldn't be that bad, because rendering had been the bottleneck all along).

It also turns out that a games graphics engine is the most crucial thing that needs to be fast. Heck, having V8 for the JS is too much speed since game logic in reality - even for very large engines - is peanuts. But, I will say physics is crucial too and would indeed benefit being more hardcoded into the engine than soft-coded into the script layer (for that V8 would be preferable). That's why I might expose a physics API in my engine rather than provide a script based one. (Box2D for C#)

This project is coming along nicely, however. What progress!
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 #439
Given how large the MapEngine API is, I suspect that in almost all cases a pure script map engine will be at least as fast. If you're willing to extend the native interface a little to accommodate it (I am), I see no reason why it won't actually be faster.

This, this would be neat to see. My Sphere engine has a fast map engine, but it's done in C# and not JS so it has zero extensibility (like the old engine). It turns out you do not need a very fast map engine, but one that is fast enough. I still need to implement the new proposed Sphere shape/group graphics API (was it called pegasus or something like that)?

Pegasus is the Sphere 2.0 API, Galileo is the Shape/Group API. I've left the Shape/Group API very barebones (TurboSphere actually extends it by letting you specify OpenGL shaders for Groups).

Right now, Pegasus is a part of the Sphere-Group repo, and Galileo only exists in the TS subdirectory. I actually need to update the spec. Using it a little, there a couple differences with how it turned out versus how I wrote it.

  • Rahkiin
  • [*][*][*]
Re: TurboSphere
Reply #440
Hi y'all.

@FlyingJester Good work on TS!

Regarding the FPS throttling problem you stated earlier:
If the game uses the FPS to do its physics and timing (every frame walking 1px, or whatever), the frame rate must be predictable.
But as Radnen noted, using FPS as timing is very bad: especially when there is some lag caused by another program or the engine itself.
So we would need some JS-accessible timing functionality for the gameloop.

I have been out of game engine spheredev for a couple of months, so excuse me if above does not make sense at all :P

Re: TurboSphere
Reply #441
Well, I would generally say that it's a better idea to record the delta-time between two events and use that. We should be assuming that, no matter what, it's possible that a section of a game could lag out, and run well below 60 or even 30 FPS. Then you need to decide if you want to be Donkey Kong 64 and adjust your speed, damage, etc. factors, or Castlevania 64 and just slow down. That's totally up to the game, we just need to provide the tools to do these things.

I was having some serious issues with stutter, even when using delta-time and not frame throttling. I've discovered the problem, and its an easy fix.

The main way to get timing in Sphere is GetTime(). This has millisecond precision. The issue is that, with a simple test, Sapphire runs approaching an order of magnitude faster than a single millisecond per frame. That, combined with the inherent stutter of controlling the maximum frame float between the render and engine threads meant that it was basically impossible to make anything operate smoothly. The difference of a millisecond or two is huge when you normally are getting <1 millisecond delta time!

A simple fix is to either change GetTime() to use higher precision, or to add a new, higher precision timing function. It's simple to get microsecond precision on every platform I know of, but I'd like to make a new function that returns seconds as a floating point, which as high a precision as possible. This will usually get nanosecond precision, but it can higher (OS X and GNU/Hurd can return a value based on FSB plus some offset), and occasionally lower (Solaris can only go to tenth-of-a-microsecond in userspace). Making it a floating point and guaranteeing at least millisecond precision would be a very safe choice.
  • Last Edit: August 13, 2014, 01:05:53 pm by Flying Jester

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: TurboSphere
Reply #442
I'd recommend rewriting GetTime so passing a parameter (maybe bool asFloatingPoint, default=false for existing behavior) still returns milliseconds but with the proposed finer grain decimal expansion. That way there's no breakage to existing scripts with GetTime (of which there are a LOT) and it's a simple change in script to get higher precision than full milliseconds.

I'd love to see GetTime return 40526.7275932589... milliseconds ;)

Re: TurboSphere
Reply #443
I was planning on leaving GetTime as it is, and adding a new function (GetSeconds(), perhaps?) that returns a floating point representation of the seconds to whatever precision is possible/reasonable (at least as good as GetTime()/1000).

Re: TurboSphere
Reply #444
Group rotation and non-triangle/poly shapes working!

Plus, since I decided to just work around the issues I'm having with V8, it's all being set using member variables.

I've got frame-throttling working in script quite well. I may just put it in the engine that way.

Using updated SDL2, TurboSphere can fully use Retina displays, without disturbing the coordinate system. The only case where this changes anything is with line-based primitives and points. In those cases, they truly are a single pixel in size (which I think is very pretty, but it would be unexpected if you only tested your game on other platforms). The biggest gain is that nearest-neighbor interpolated images actually look pretty nice.
It's kind of strange...the edgy, crisp-but-jagged look of Playstation 1 and Sega Saturn graphics, combined with a ridiculously high resolution. The resolution is the antialiasing.
I can honestly say I've never seen any game (or even any program) that has this look.

I'll post a shot of Retina-mode when I get a proper scene going that shows it off.
  • Last Edit: August 18, 2014, 02:44:06 am by Flying Jester

Re: TurboSphere
Reply #445
I definitely made the right decision by changing the Input event handling code. Adding scroll-wheel support was only adding 3 lines (plus adding the constants)!
It would be pretty simple to make writing and using user-defined event filters and translators (usually one-line functions) possible from script.
That would be nice because the native hardcoded filters (keys, clicks, joystick buttons, and scrolls) would still benefit from the low overhead of being totally native (which could really matter), but script-defined translators and filters would allow wide-open access to the underlying system to script.

Here's a picture of retina mode. Not the best example (no proper textures), but it looks very nice in motion, and the 1px lines are sooo sharp.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: TurboSphere
Reply #446
Isn't the idea of Retina that the PPI is so high you can't make out individual pixels?  Seems like that could cause such 1px lines to become invisible if the viewing distance is too large.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: TurboSphere
Reply #447
The idea is that something like this (primitives with 1px definition) would approach the look of true vector graphics. Hence the Asteroids theme. You can't make out the aliasing. Well, yes you can, but ideally you wouldn't be able to.
  • Last Edit: August 21, 2014, 05:17:50 pm by Flying Jester

  • Rahkiin
  • [*][*][*]
Re: TurboSphere
Reply #448
The retina thing is why I once proposed to use floating point coords and sizes instead of integer. It does not matter for JS, and storage is the same too, but integer math might be a bit slower.
The advantage is that you can keep 1pt = 1px on non-retina, and on retina, 1pt=2px, like Apple does. also, you can then do 0.5pt = 1px on retina: making it possible to do interpolation and smaller graphics but also keeping non-retina games to work on retina displays.

I think that is what we should be aiming for.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: TurboSphere
Reply #449
So realistically, once TurboSphere is ready for primetime, how much work would I be looking at to port a full-scale game like Spectacles from Sphere 1.x to TurboSphere?  I know you've said you'll have some sort of shim to ease the transition, but with all these changes to how things work under the hood, it seems like porting issues could still easily crop up just due to differing implementation, even if the legacy API is preserved.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub