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 - casiotone
- 1
1
Sorry for recent downtime (not sure how long it was... I should pay more attention). The server ran out of disk space. All good now.
2
I'm planning to do an OS upgrade on the server this weekend (from Ubuntu 12.04 to 14.04). Hopefully nothing will go wrong but there will be some downtime.
3
This has been discussed on github for sphere 2.0: https://github.com/sphere-group/pegasus/issues/9
I think all the current engines should move to implement require as a built-in as soon as possible, and Sphere libraries should begin to be shipped as simple npm-like packages that can be used with require. With a forked `npm` using a custom package index we can make Sphere libraries easy to install and use, with proper dependency management. In short, modern.
We can still shim support without built-in require for backwards compatibility - writing a module loader isn't that complicated, and we're only going to be loading JavaScript.
I have been working with minisphere and Duktape has half of it built in - it performs path resolution and you have to supply it with the module. I wrote a loader that enables use of require('module') that will look for four things:
1. module.js
2. module.json
3. module/index.js
4. module/package.json
The final check is for packages. We open the package.json and find out what the main file is called, then load that. We also have a convenience loader for JSON files.
It will look for files in your scripts directory, then in the modules directory. This is the directory that Sphere libraries would be installed to by the package manager.
Duktape is currently limited and assigning module.exports doesn't work, only properties on exports. It also has limitations that mean we can't load package files from a subdirectory in the package. A replacement is being considered to make it more flexible, but this works otherwise. We can still shim instead of using Duktape until then.
Let's make this the first step to Sphere 2.0. A real module loader and a real package manager.
I think all the current engines should move to implement require as a built-in as soon as possible, and Sphere libraries should begin to be shipped as simple npm-like packages that can be used with require. With a forked `npm` using a custom package index we can make Sphere libraries easy to install and use, with proper dependency management. In short, modern.
We can still shim support without built-in require for backwards compatibility - writing a module loader isn't that complicated, and we're only going to be loading JavaScript.
I have been working with minisphere and Duktape has half of it built in - it performs path resolution and you have to supply it with the module. I wrote a loader that enables use of require('module') that will look for four things:
1. module.js
2. module.json
3. module/index.js
4. module/package.json
The final check is for packages. We open the package.json and find out what the main file is called, then load that. We also have a convenience loader for JSON files.
It will look for files in your scripts directory, then in the modules directory. This is the directory that Sphere libraries would be installed to by the package manager.
Code: [Select]
(function() {
var extensions, fileExists, jsHandler, jsonHandler, packageHandler, paths,
indexOf = [].indexOf || function(item) { for (var i = 0, l = this.length; i < l; i++) { if (i in this && this[i] === item) return i; } return -1; };
jsHandler = function(filePath, file) {
return file;
};
jsonHandler = function(filePath, file, exports) {
var json, key, value;
json = JSON.parse(file);
for (key in json) {
value = json[key];
exports[key] = value;
}
};
packageHandler = function(filePath, file) {
var json, script;
json = JSON.parse(file);
file = OpenRawFile(filePath.substr(0, filePath.length - 12) + json.main);
script = CreateStringFromByteArray(file.read(file.getSize()));
return script;
};
fileExists = function(path) {
var check, checked, entries, parts, testPath;
if (path.substr(0, 3) === '../') {
path = path.substr(3);
}
parts = path.split('/');
checked = [];
while (true) {
testPath = checked.join('/');
entries = GetDirectoryList(testPath);
entries = entries.concat(GetFileList(testPath));
check = parts.shift();
if (indexOf.call(entries, check) >= 0) {
checked.push(check);
if (parts.length === 0) {
return true;
}
} else {
return false;
}
}
};
extensions = {
'.js': jsHandler,
'.json': jsonHandler,
'/index.js': jsHandler,
'/package.json': packageHandler
};
paths = ['../scripts', '../modules'];
Duktape.modSearch = function(id, require, exports, module) {
var extension, file, filePath, handler, i, len, path, script;
for (i = 0, len = paths.length; i < len; i++) {
path = paths[i];
for (extension in extensions) {
handler = extensions[extension];
filePath = path + "/" + id + extension;
if (fileExists(filePath)) {
file = OpenRawFile(filePath);
script = CreateStringFromByteArray(file.read(file.getSize()));
return handler(filePath, script, exports);
}
}
}
throw new Error("Cannot find module " + id);
};
}).call(this);
Duktape is currently limited and assigning module.exports doesn't work, only properties on exports. It also has limitations that mean we can't load package files from a subdirectory in the package. A replacement is being considered to make it more flexible, but this works otherwise. We can still shim instead of using Duktape until then.
Let's make this the first step to Sphere 2.0. A real module loader and a real package manager.
4
Hi guys,
Later today (around 12PM GMT) the server is going to be moved to new hardware. I've been told the downtime should be between 1 and 15 minutes. It'll be closer to the short end as there's not much to move. The site should come back automatically when the server is brought back up, but just in case, I'll be checking on it later.
Later today (around 12PM GMT) the server is going to be moved to new hardware. I've been told the downtime should be between 1 and 15 minutes. It'll be closer to the short end as there's not much to move. The site should come back automatically when the server is brought back up, but just in case, I'll be checking on it later.
5
As a personal project (to get to grips with C++) I've begun my own engine implementation with v8 and SDL...
https://github.com/postcasio/sphereclone
My aim with this is to actually implement a completely new API, while maintaining backwards compatibility by implementing most of the Sphere API in JavaScript.
I currently have Require/EvaluateScript functions implemented in JS, as well as Rectangle and CreateColor. The screen is actually exposed as a surface in the new API, which is set up in the bootstrap script and wrapped by the Sphere API.
Additionally the bootstrap script will be responsible for engine logic like loading games. It will load and parse configuration files and graphical Sphere formats. Speed should be fine with an API function to load bitmap data directly, since the majority of loading time would be spent building images otherwise. The map engine will be built in JavaScript.
A game would be able to specify which version of the API it requires. and the bootstrap will turn off the old functions if the game is developed for the new API. The new API will be as sparse as possible - things that can be done in JS should be. This will allow a great degree of flexibility for games.
So, it will basically be a much lower-level game engine with a JavaScript implementation of Sphere for backwards compatibility.
I've added an Sconstruct file that I've used for developing on my mac... To build, you will need to modify the CCFLAGS and LINKFLAGS variables to point to the right place. Additionally, if you're not using a Mac, remove "-framework Cocoa". I've kept the build process very simple.
What you need (at least):
v8: 3.18.2
sdl: 1.2.15
And scons to build.
https://github.com/postcasio/sphereclone
My aim with this is to actually implement a completely new API, while maintaining backwards compatibility by implementing most of the Sphere API in JavaScript.
I currently have Require/EvaluateScript functions implemented in JS, as well as Rectangle and CreateColor. The screen is actually exposed as a surface in the new API, which is set up in the bootstrap script and wrapped by the Sphere API.
Additionally the bootstrap script will be responsible for engine logic like loading games. It will load and parse configuration files and graphical Sphere formats. Speed should be fine with an API function to load bitmap data directly, since the majority of loading time would be spent building images otherwise. The map engine will be built in JavaScript.
A game would be able to specify which version of the API it requires. and the bootstrap will turn off the old functions if the game is developed for the new API. The new API will be as sparse as possible - things that can be done in JS should be. This will allow a great degree of flexibility for games.
So, it will basically be a much lower-level game engine with a JavaScript implementation of Sphere for backwards compatibility.
I've added an Sconstruct file that I've used for developing on my mac... To build, you will need to modify the CCFLAGS and LINKFLAGS variables to point to the right place. Additionally, if you're not using a Mac, remove "-framework Cocoa". I've kept the build process very simple.
What you need (at least):
v8: 3.18.2
sdl: 1.2.15
And scons to build.
6
Not sure if this has been covered, but I came to the realisation that replacing the Load* functions is quite simple with low overhead...
example (in coffeescript)
In JS you can return another object from a constructor, so all we have to do is fix the constructor of Sphere's object. The fixed object is still accepted by the API, and instanceof works.
in JS
example (in coffeescript)
Code: [Select]
class Color
constructor: (r, g, b, a=255) ->
color = CreateColor r, g, b, a
color.constructor = c
return color
white = new Color 255, 255, 255
In JS you can return another object from a constructor, so all we have to do is fix the constructor of Sphere's object. The fixed object is still accepted by the API, and instanceof works.
in JS
Code: [Select]
function Color(r, g, b, a) {
var color;
if (a == null) {
a = 255;
}
color = CreateColor(r, g, b, a);
color.constructor = Color;
return color;
}
7
Very simple wrapper for coffeescript. This probably isn't the best way (precompiling is certainly faster) but it also includes a simple mostly compliant CommonJS modules implementation.
https://github.com/postcasio/coffee-sphere
https://github.com/postcasio/coffee-sphere
8
(formerly titled "Mooving Sphere to GitHub" ~Neo)
Has anyone considered moving the main Sphere repository to GitHub? SF is basically dead by now.
Has anyone considered moving the main Sphere repository to GitHub? SF is basically dead by now.
- 1