Skip to main content


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rahkiin

I have an idea.

Why build in TypeScript, if we can just make use of the transpilers already out there? I mostly use a grunt workspace setup that transpiles every time I change a TS file. It compiles it to ES5. That would solve everything?

Only thing we need it a set of typings for Pegasus. As Pegasus is just specs anyway, we could make it TS-ish to add nice typings for the implementor.
I split this off from my response on the Plugins part.

Let's make Pegasus async (non-blocking). Node is, indeed, and we should follow this path. No multi-threading (for now), but one big event-loop. Yes, I say event-loop because it sounds a lot like 'game-loop'. (node uses an event-loop).
This might be harder than non blocking without an event loop, but it does solve a lot of issues regarding files and such. I am not sure how this would be designed, especially in a game, but I will look into it today.

If we follow the node.js modules+async path, I think I could implement a full-software (slow) engine by implementing Pegasus on top of Node. This could be used for prototyping. Not really for games, that is too slow. Also, 'npm install sphere-pegasus'.

If we go with Async, I suggest we use Promises. Promises is an ES6 builtin and there is Bluebird and many other libraries for ES5. You can also implement it yourself if you like, which is good fun. Use promises where-ever you can, that is.
As you might have no idea what promises are, I will explain it a bit:

A promise is a promised value. A promise can either reject (with an error) or resolve (with a value).
A quick example: loading a file. That can either fail (file did not exist, system error, whatever) or it can succeed (with the data). Now, in Node-style-async you would thus have the following function:

Code: (javascript) [Select]
function loadFile(name: string, callback: (error: Error, result: any) => void): void
(Yes, this is JavaScript with typings so that is easy)
You call this:
Code: (javascript) [Select]
loadFile("myFileName.y", function (error, result) {
   if (error) {
      console.log("Oh no! An error occurred! EXIT!");

    console.log("All went well, lets print and exit.", result);

This ain't too bad but it is not nice either. Lets say we want to read a file and then directly write it.
Code: (javascript) [Select]
loadFile("myFileName.y", function (error, result) {
   if (error) {
      console.log("Oh no! An error occurred! EXIT!");

   console.log("All went well, lets print and write.", result);

   writeFile("myOtherFileName.y", result, function (error) {
        if (error) {
            console.log("Oh No!: Could not write! EXIT!);
        console.log("ALl went well, wrote the file. Bye.");

This is getting worse and worse.

Also, you are processing errors over and over again.
Lets see what it all looks like using a Promise: a value that promises a result.
Code: (javascript) [Select]
 function loadFile(name: string): Promise

Code: (javascript) [Select]

   .then(function (result) {
       return writeFile("myOtherFileName.y", result);
   .then(function () {
      console.log("All Finished!");
   .catch(function (error) {
      console.log("An error occurred:", error);

Short and nice! WIth ES6/TypeScript this is even shorter (you can compile ES6/TS to ES5):

Code: (javascript) [Select]

   .then((result) => writeFile("myOtherFileName.y", result))
   .then(() => console.log("All Finished!"))
   .catch((error) => {
      console.log("An error occurred:", error);

That is beautiful! What you read is what happens! And no deep tabs.

I hope I convinced you that this is the way to go.

(You might wonder, what does loadFile code looks like?)
Code: (javascript) [Select]

function loadFile(name: string): Promise {
    return new Promise(reject: Function, resolve: Function) {
        // Do stuff
        if (an Erorr happened) {
           reject(new Error("An error"));
        } else {
    }); // returns a promise right-away

For simple function you can also return Promise.resolve() or Promise.reject(). So a stub implementation that always resolves:
Code: (javascript) [Select]

function loadFile(name: string): Promise {
    return Promise.resolve("somedata"); // STUB

If you have any questions of anything, respond!
Awesome, you understand why I wanted modules so bad.

I want to propose a couple of things:

One. Use a very node-ish module system. You can view their code and base the system of theirs. Do it, it is stable, it works well, is used by millions. You can then add on top of it: first search for a system (compiled) module, then search for files in system, then search for local files. (also see my comment on GitHub). If you make sure that the compiled module exports according to the spec, this could be a nice speedup for your system.
Node also supports native modules. They are compiled using Node-Gyp. It allows for example for a native protocol to Redis.

Two. Always make sure there is a full set of system modules available, either native or non-native.

Three: You can indeed replace JS modules with native modules at will. Also, I think adding "aftermarket" Python support is very possible. But we need to think about how. Will we want to exchange sphere-python.dll between TS and MS?

8: I just saw a lot of Futue of Pegasus topics. Ill just make mine.

Hellos and Byes / Hello Again
Yeah sorry, I was off the sphere-grid for a while.
It happens a lot to me, that I just lose interest for a couple of months, and then I just forget about it, until I get emails!

So what will I be doing? I will not be implementing my own engine anymore, as TS also works on OSX.
All I will be doing it working on Pegasus.

So, hi, again!
Lord, I agree. Make something new. But I do think that Pegasus needs to end up with at least the features of Sphere 1.x.

I also DO think we should use CommonJS modules, and also that we should not have blocking calls but use Promises instead (not the callback stuff, only for callbacks that are actually callbacks: one that will be called 1+ times.)

I'll take a look at it.
Off-Topic Discussions / Re: 4K TVs make awesome displays
Wow, that is one big screen.

I do think I will stick with my tripe screen setup :) I like my screens clean, and 3 fullscreen apps on display at all times does that for me.
Site Comments / Re: Hello?

Yes, somewhere in some TS topic I said that TS is getting so good (and working on OSX) that I could better spend my time working on TS with FJ than doing an engine myself just for OSX (just for me I think :P).
been doing other stuff too (I like to switch a lot between projects, low concentration).

Also, keeping up with V8 for two engines is awful.

We could look more into TS and Pegasus. My engine is just a plaything it seems hehe.

Engine Development / Re: TurboSphere
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.
Engine Development / Re: TurboSphere
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
Hellos and Byes / Re: Hello people
Hello then! Welcome back!
Engine Development / Re: TurboSphere
You actually only ned to enable debugging, add a flag to wait for debugger, and handle debug messages (depends on how you do synchronization). I did it toally in 10 lines or less.

The actual debugging can be done using d8, or writing your own program that uses the debug protocol, that still works.
Engine Development / Re: TurboSphere
Wow this is awesome!

Makes me reconsider my mac engine: I could just fork/pullrequest TS and write plugins... currently i only use my engine to experiment anyways. I don't see myself writing a graphics engine as well as yours!

If i find the time, ill run it on my mac tomorrow.

Feature request: V8 remote debugging (allowing it. Can use d8 to debug).

I might cease working on the engine and continue on my IDE instead and a builtin debugger is a must-have!

Keep the work up!

// Rahkiin
Projects / Re: Spectacles: Bruce's Story

I am at my parents with my Windows PC now, and I played your demo... Wow. It is awesome. I like the music and the gameplay, although I have no experience with it so I fail in battle xD (I know nothin of combos).

Keep up the good job!

Let's just say this project helped me get that job. :P

Then I think it is time from a story by Radnen! :P
I love when hobby leads to work.
Engine Development / Re: Sphere 1.5, 1.6 beta
Almost all code in either in unix (fixing warnings) or in mac yes. And other code is safeguarded with preprocessor directives. I would like if someone made sure I did not screw up tho. :) There is always rollback ghehe.
There were problems in shared code too so I had to fix those. And the buildsystem is shared per definition.