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.

Topics - Rahkiin

Engine Development / Delphinus: my engine try 2.0
Hi All!

So even though I said I would not write another engine, I decided to make it myself 'easy' and do it with SDL and SM.

The name
Pegasus is an awesome name (wonder who thought of it  ;D) and constellations are awesome. My latest try was Andromeda, a constellation next to Pegasus. Delphinus is also next to Pegasus. One day I will be running out of names...

The plan
Full featured Pegasus implementation.
Fully working on Mac OSX (where I develop on)
Possibility to easily port it to other OSes (because I use SDL).
When it does work a bit I could try to make it work on iOS, but it could never be in the App Store (because of Spider Monkey).
Also, at least on OSX, you package your game as a .app. My engine runs in a .app (and only works there because of dynamic file loading reasons). You put your game inside the .app package folder, change the app icon and name and you are done. Double-click to load the game. ZIP/DMG it and give it to someone else. No need to install anything. A simple, clean game. (I really like this)

I might make a simple tool called 'spm': Sphere Package Manager, for installing and updating -etc- packages for your game. Using a directory in a GitHub repository and linking from that repo to other repos. So no hosting needed (is the plan).

The tools
I use SDL2 for platform independence and for the ability to go all blocking, which is incredibly hard and problematic to do on OSX/iOS.
As my JavaScript engine I use SpiderMonkey (currently the latest released version, 45). This engine supports a lot of ES6 as well which is very nice.
OpenGL, even though I don't know shit about shaders. Will see how this works out.

Current state
I have a basic JS engine setup. There is no graphics yet, although SDL is set up and working. Currently concentrating on making the JS usable.
I have finished a fully-fledged CommonJS module setup, including loading 'packages'. It works really nicely with separated globals per module, module caching and nice module resolving.
SphereFS: everything is sandboxed, including the require()-able modules.

So that is that. No ETA's. Just coding some. When I have/make the time.
Currently hosting the code on my companies Stash, I will move it to GitHub later. Code is now on github:
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!
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!
Engine Development / Pegasus: Sphere 2.0
Dear All,

In this topic, I would like to discuss Pegasus: Sphere 2.0. In the Sphere for Mac and TurboSphere topics have been some messages about this project, and to remove fragmentation, I suggest we talk about it here instead.

What is Pegasus?
Pegasus is a complete redesign of the Sphere 1.x API. It uses modern JavaScript idioms, paradigms and coding style. And it is non-blocking in places where 1.x was very much blocking. This allows for better engines, better games and happier gamers :D


  • More flexible and powerful graphics engine.

  • Asynchronous networking.

  • Non-blocking input handling

  • JSON based sphere file formats

  • More...

Even though Radnen (maker of SFML), FlyingJester (maker of TurboSphere) and me (maker of Andromeda) started Pegasus, does not mean we want to do everything alone!
We invite the Sphere Community to participate in this journey by giving ideas for the new API: what would you like to see? What do you think can be dismissed?
But there are more ways to help: you can write on the API itself by forking the repository and sending pull requests. Or you can send in issues. You can also submit unit tests and tutorials.

Github repository:
Generated API documentation:

// Rahkiin
Hi All!

I have a couple of matters regarding the JavaScript library provided for Sphere:

Today I was coding on my engine, and I came across the Logging API in the function docs on the wiki.
I started to wonder, does anyone use this logging api? Especially more than just the 'print a line to a file': the grouping?

I am adding SHA1 and SHA256 hashing functions for files and raw files. It might be a good addition as MD5 is completely broken. I keep MD5 for legacy reasons.

// Rahkiin
Engine Development / File Formats

@Rahkiin - That is a good idea, as the file format docs that come with Sphere may be a bit outdated (especially the map and spriteset ones). If they're not documented on the forums for some reason, ask Radnen and Flying Jester for their findings on parsing Sphere formats (especially version inconsistencies) since they've worked with them more recently than I have. Lord English may also have a couple of notes after making some edits to Radnen's Sphere Studio. alpha123's worked with the most recent version of vanilla Sphere, but that may have been quite some time ago. The Web Sphere Utilities repo has my code for parsing the formats but it's all in web-compatible JavaScript. Pick your poison ;)

I already implemented all file formats in my engine, by looking at the Sphere code in the sphere repo. I also tested on different files. Is that good enough? I even support all versions available :) (Although I might get rid of older versions later).
Engine Development / Sphere for Mac: Andromeda
Hi all!

As I have been writing in my hello-post, I am working on a Sphere engine/runtime for Mac OSX (very native) and eventually also for iOS, that would actually be allowed in the App Store (yes to any sphere game running on iPhone!)

The plans are to use as many native frameworks to keep compatibility and dependencies low.

  • Window management and input: Cocoa (Touch)

  • Joystick input: IOKit

  • Graphics: CoreGraphics and OpenGL (SE)

  • Audio: CoreAudio, libogg+libvorbis

  • JavaScript: JavaScriptCore (comes native now, in ObjC package!) V8, with my ObjC wrapper called L8!

I build my system using a bunch of frameworks, so I can share code with my development toolkit later on.

A couple of new features:

  • More and better event based networking. And also game announcement and discovery using Bonjour (zero-conf).

  • More object-orientated library (with shim for compatibility)

  • Game libraries for nice packaging for code of others. This might use ES6 modules later on.

  • Game packaging into .apps with custom everything! Publishing your game will be awesome!

  • SQLite 3 Databases

I want to note that Bonjour is also available for Windows and Unix.

I have a couple of questions for the community:

  • Is there anyone who ever used (and is still using) a joystick for Sphere games? IOKit is a PITA.

  • How much is JNG and MNG used in practice?

  • What new Sphere features do you want to see and could I build into Sphere for Mac?

  • What existing Sphere features have you never used?

Radnen has given the idea for base/shallow map system to give more options to advanced users, and isomorphic maps.

Love to hear from you guys!

// Rahkiin
Hellos and Byes / I say Hello, you say...
Hi guys!

I would like to use this opportunity... oh lets cut the formal crap: I am Rahkiin! A 19y old CS student from Delft, The Netherlands.

I came to know Sphere when I had an game-dev assignment in my last year of high school. With three other guys, I made a game I was, and still am, very proud of. For future reference: the game was called Scala World, and was all in dutch. Although we did not know Sphere at all, we were very able to use the Sphere Editor and as I am quite good in programming, I picked up the JavaScript library pretty quick.
We used the map engine for the Pokemon-styled (literally, we used their tileset) game and programatically I added some nice tools, that are worth explaining, I think :)

Obstruction and animation
The roles in my group were divided perfectly: I was the programmer, one mate made the story and quests, another made spritesets and the fourth made the maps. Now I wanted to make the programmer able to do very easy obstruction mapping (non enterable blocks because a bench is there, but also doors you can only walk into (one-direction obstruction) and animation placing (eg, when jumping a ridge). To do this, I added two invisible layers to the map and obstruction tiles to my tileset, and I programmed the tile-based 4-way single-step (like Pokemon) movement with the obstruction layer as obstruction logic. And it worked very well! The map-designer could now create the maps all himself.

I also used the obstruction tiles for random person movement (NPCs). It is much faster than obstruction-segment collision matching.

I did use Map Zones, but just for Quest activation.

Our game would cover the whole building of my school, with every room in it. Most class rooms would just contain some walking students and the teacher assigned to that room/course.
Other classrooms would contain a teacher giving quests, in turn giving either keys or other objects. (The ultimate goal was to obtain the 3 elemental keys, open a dungeon and beat the boss (the master school bully) by answering questions about your adventures in the school).

This all meant we would have a lot of portals between rooms. And I did not want to program each of them by hand. So I created a portal system: blue and orange portals. A door entity placed where the doors are and upon collision, the player is moved to the linked door, in the right map, standing in the right direction. The portals were linked automatically: the portal in the corridor did not need to know the location of its opposing portal. Instead, they just both gave a link-name and a direction the player should be facing when returning. A script opened all maps and looked for all portals. A slow process, but with a portal-cachefile this was only done when changing any portals.
Result of all this in combination with a persistence script I found on the wiki: maps can be linked by placing entities and a small line in the entities touch-code: Portal('PortalName','east'). Even my map-designer could handle that!

I might upload the code somewhere, but I learned much last years and it ain't very clean code anymore (deadlines and all that).

My current activities with sphere are somewhat different from writing a game. I am actually writing a Sphere Runtime for Mac OSX. (I am very Mac-ish these days, although I do have a gaming computer somewhere). I also went to write a native OSX Sphere DevKit, but this is on hold until I have my runtime (I tend to overcomplicate things, so I started with a full plugin-based environment. I think you guys know what I mean :P).

I want my runtime to have a couple of new features and functionalities. But in the end, I also want to be compatible with existing games.

  • UI and input: Cocoa

  • Joystick input: IOKit

  • Graphics: CoreGraphics. However, if this utterly fails I might do OGL (I suck at OGL)

  • Audio: CoreAudio

  • JavaScript: JavaScriptCore (WebKit)

  • Bonjour: LAN game discovery

If you are anything into OSX and iOS dev, you might notice these are all available on OSX natively, including JSC (since 10.9). That is great; what's also great is that even JSC is available on iOS7, so I could 'port' the runtime to iOS. And I think I could even convince Apple to put it in the App Store, because it is JavaScript and a Zip of resource files for a game, not some native code downloaded from the internet...  :D

Also, even though I wrote JavaScriptCore there, I have been writing an Objective-C wrapper very much alike JavaScriptCore for V8 (Flying Jester: I used the new Handle code  ;)), called L8. I do not trust it memory-wise though. And there is a problem is converting the C blocks to functions, and around. Quite a piece of code. So I resigned to JSC. (When I started this project, OSX 10.9 was not released yet).

That aside. The features:

All new class-based Sphere library
(With ECMAScript 1.6 (JS6) in mind, modules yeah!). This means a lot of 'classes', and no more function such as LoadFont(): instead there is the new Font() (create font) and new Font('font.rfn'). This is a lot nicer for me because of the JS-ObjC mapping done by JSC/L8.

Sphere compatibility with a Shim
Of course it should have everything Sphere has, but mostly via a shim.

Game libraries
I want to design the concept of a library for Sphere. Especially with the JavaScript modules (ES6) in mind. Any thoughts or comments are welcome. I think it would clean up a game, especially when using big libraries like Radlib. I am thinking about a folder with an extension (OSX-like), not zipped, but placed in a libraries folder. Then lib-files and your own files will not be mixed.

Native OSX game packages
This I find very awesome: I want to pack the runtime in an .app package and load the game into it. Then add some much more info to the game information file (actually, get rid of .sgm and make some .plist) to also include game icon and such. Then there is this simple .app package, such as with the Blockmap icon, and double-clicking it opens the game directly. Save-files are stored in the user-data location and the app actually shows up with the correct icon in the dock. I would really prefer such package over sending someone a Zip with a bunch of files in it :)
I have no Idea how easy, hard or impossible such thing is for Windows people. (Exe can contain resources though).

My plans
As I said above, I am planning on making the dev environment. Just because I think Sphere is very awesome! I also plan to hang out on these forums.

As far as I can tell, I am speaking to just a couple of people here: Radnen, Flying Jester, NEO, Mooch, DaVince and Lord English. And Harry Bo. But that's cool :)
Please, do not tell me I waste my time here. Don't we all? ;D

So that is me, what i've done, what I do and what I plan to do with sphere. Any comments and ideas are welcome!

// Rahkiin