Spherical forums

Sphere Development => Engine Development => Topic started by: Rahkiin on March 06, 2014, 07:31:02 pm

Title: Sphere for Mac: Andromeda
Post by: Rahkiin on March 06, 2014, 07:31:02 pm
Hi all!

As I have been writing in my hello-post (http://forums.spheredev.org/index.php/topic,1144.0.html), 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.


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:


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

I have a couple of questions for the community:


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
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Radnen on March 06, 2014, 07:56:07 pm
Oh, I got an idea! This may add a new dependency, it may not, but could you add SQLite support? I can think of various things such as item and monster databases for RPG games. It seems to make the most sense. I myself may add such support in my engine, but the more projects with that support the better.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 06, 2014, 08:11:39 pm
There is actually an SQLite library (libsqlite3.0) within OSX, so it would not add a dependency.

Can you suggest some API for it? Would you want to go very DB, Table, Row -like style, or more like this:


Code: (javascript) [Select]
database.query("select * from players") => [{'name':'Rahkiin','score':10},{'name':'Radnen','score':1}]
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 06, 2014, 08:14:33 pm
I just discovered that my own V8 JavaScript bridge has more features than JavaScriptCore has to WebKit :( This is quite bad... My bridge cannot be trusted memory wise though...

Code: (javascript) [Select]

var c1 = new Color(255,255,255);


Can't now actually be called when simply doing this in ObjC:

Code: (objective-c) [Select]

context[@"Color"] = Color.class;


Which is ridicilous (the fact it was not implemented). It is now, with single-init acceptation, but come-on.... Even I implemented it more awesome. It would actually look at the number of arguments :D

I will find a workaround...

EDIT: Fixed in nice and easily, with a nice hack :)

// Rahkiin
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Radnen on March 06, 2014, 09:25:00 pm

There is actually an SQLite library (libsqlite3.0) within OSX, so it would not add a dependency.


Good, it's been awhile since I've looked at the internal 'dependency' list for OSX, I thought SQLite was in it, which is why I recommended it.


Can you suggest some API for it? Would you want to go very DB, Table, Row -like style, or more like this:

Code: (javascript) [Select]
database.query("select * from players") => [{'name':'Rahkiin','score':10},{'name':'Radnen','score':1}]



If you can do it like that code piece it would be great, I've always liked object-relational approaches. But that's for getting data back, how about storing data?

Code: (javascript) [Select]
database.insert("table-name", { 'name': 'Test', 'score': '15' });


And correct me if I am wrong, but doesn't SQLite use a single table?
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 06, 2014, 10:08:07 pm

If you can do it like that code piece it would be great, I've always liked object-relational approaches. But that's for getting data back, how about storing data?

Code: (javascript) [Select]
database.insert("table-name", { 'name': 'Test', 'score': '15' });


And correct me if I am wrong, but doesn't SQLite use a single table?


You are wrong. It is a single database, single user, single process, single thread. But multiple tables.

Selection will indeed be the easiest. I think your insert idea will work.

For update, I think the easiest approach is this:

Code: (javascript) [Select]

database.update("users",{'name':'Radnen'},{'score':15});

This code snippet updates the user Radnen in the table users, giving you a score of 15. So: update(tablename,whereCond,update). Maybe update(table,update,where) is better.

OR

We could take a functional approach, like I have used in CodeIgniter (http://ellislab.com/codeigniter/user-guide/database/active_record.html):

Code: (javascript) [Select]

database.where('name','Rahkiin').orWhere('name','Radnen').get('users') => {/*...*/};
database.where('name','Rahkiin').update('users',{'score':15}) => 1 /* affected rows */;
database.delete('users',{'name':'N E O'});


// Rahkiin
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Radnen on March 07, 2014, 12:10:05 am

We could take a functional approach, like I have used in CodeIgniter (http://ellislab.com/codeigniter/user-guide/database/active_record.html):


I like the functional approach because it reminds me of my Link library. :)





You are wrong. It is a single database, single user, single process, single thread. But multiple tables.


Oh, that's good to know. I thought everything went into one giant table, but I guess it's just a single user database. But I know for a fact SQLite is multi-threaded; or can be used in a multi-threaded app since I have seen that before.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Flying Jester on March 07, 2014, 02:19:09 am


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



Please don't make me set up Bonjour on my Linux.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 07, 2014, 07:53:11 am

I like the functional approach because it reminds me of my Link library. :)

I just saw you made an update on that. So will make a design for it then.


Oh, that's good to know. I thought everything went into one giant table, but I guess it's just a single user database. But I know for a fact SQLite is multi-threaded; or can be used in a multi-threaded app since I have seen that before.

Ok, multithreaded then, but MT is messy :) I myself don't use multithreading at all because I use kqueue (libdispatch -> RunLoops).


Please don't make me set up Bonjour on my Linux.


There are all sorts of tools to help you with that :P http://www.mono-project.com/Mono.Zeroconf (http://www.mono-project.com/Mono.Zeroconf) and http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-320.10.80/mDNSPosix/ (http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-320.10.80/mDNSPosix/)

But I am not forcing you to also use it in your TurboSphere. It would be cool though.


// Rahkiin
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 07, 2014, 10:14:34 am
The SQL functional approach:

Code: (javascript) [Select]


var db = new Database("/path/to/db.sqlite");


class Database {
/**
* Creates a new database object given the sqlite file
*
* If file is not found, a file is created
*
* @param path path of sqlite file
* @return Database. null on failure
*/
function Database(path);

var tables; // Array of Strings

/**
* A function to make an empty query or a query with
* given SQL query.
*
* @param sql SQL query
* @return Query
*/
function query([sql]);


/**
* Gives the number of rows in given table
*
* @param table tablename
* @return Number with number of rows
*/
function countAll(table);

/**
* Truncates given table
*
* @param table Tablename
* @return true on success, false on failure
*/
function truncate(table);

function createTable(table,fields);
function dropTable(table);
//function renameTable(table,newName);
//function addTableKey(table)
//function addColumn()
//function dropColumn()
//function modifyColumn()
}

class Query {

/**
* Adds column selection. If never specified, '*' is used.
*
* @param columns 1) An array of column names, 2) a column name. Multiple possible.
* @return Query
*/
function select(columns, ...);

/**
* SELECT MAX(field) portion of the query
*
* @param name of the column
* @return Query
*/
function selectMax(column);

/**
* SELECT MIN(field) portion of the query
*
* @param name of the column
* @return Query
*/
function selectMin(column);

/**
* SELECT AVG(field) portion of the query
*
* @param name of the column
* @return Query
*/
function selectAvg(column);

/**
* SELECT SUM(field) portion of the query
*
* @param name of the column
* @return Query
*/
function selectSum(column);

/**
* Runs the selection query and returns query result
*
* @param table Name of the table. Can be omitted when from() is used.
* @param limit Limited number of rows
* @param offset Offset within the result
* @return Result
*/
function get([table [, limit [, offset]]]);

/**
* Specify the table to select from
*
* @param table Name of the table
* @return Query
*/
function from(table);

/**
* Adds a where condition
*
* Using multiple where() calls results in an AND concatenation.
*
* @param key column name
* @param value value of the column
* @param object Object containing multiple column/value combinations
* @param custom_query A custom where query such as "name='Joe' OR score='15'"
* @return Query
*/
function where(key, value);
function where(object);
function where(custom_query);

/**
* Same as above but with OR concatenation
*/
function orWhere(...); // Same as above

/**
* Adds a join portion to the query
*
* @param table name of the table to join
* @param condition Join condition. If none specified, a natural join is used.
* @param type Type of join. Possible values are left, right,
* outer, inner, left outer, right outer.
* If none specified, defaults to SQLite default.
* @return Query
*/
function join(table[, condition[, type]]);

/**
* Adds a WHERE field IN (item, item) portion joined using AND
*
* @param column Column to compare to
* @param values Array of values
* @return Query
*/
function whereIn(column, values);

/**
* Adds a WHERE field IN (item, item) portion but joined using OR
*
* @param column Column to compare to
* @param values Array of values
* @return Query
*/
function whereIn(column, values);

/**
* Adds a WHERE field NOT IN (item, item) portion joined using AND
*
* @param column Column to compare to
* @param values Array of values
* @return Query
*/
function whereNotIn(column, values);

/**
* Adds a WHERE field NOT IN (item, item) portion joined using OR
*
* @param column Column to compare to
* @param values Array of values
* @return Query
*/
function orWhereNotIn(column, values);

/**
* Adds a LIKE clause, joined with AND
*
* @param column name of column
* @param value value to match for
* @param wildcard Wild card option: before, after, both (default)
* @return Query
*/
function like(column, value [, wildcard]);

/**
* Same as above, but with column-value object
*/
function like(object);

/**
* Like the like() function, but joined with OR
*/
function orLike(...);

/**
* Like the like() function, but as NOT LIKE statement
*/
function notLike(...);

/**
* Like the notLike() function, but joined together with OR:
*/
function orNotLike(...);


/**
* Adds a GROUP BY portion
*
* @param column name of a column
* @param columns array of column names
* @return Query
*/
function groupBy(column);
function groupBy(columns);

/**
* Adds DISTINCT keyword to the query
*
* @return Query
*/
function distinct();

/**
* Like the where() function, but then HAVING clause
*/
function having(...);

/**
* Like the having() function, but joined together with OR
*/
function orHaving(...);

/**
* Adds an ORDER BY portion
*
* @param column Name of column
* @param direction ORDER BY direction: either asc or desc
* @return Query
*/
function orderBy(column[, direction]);

/**
* Adds LIMIT and OFFSET clause to query
*
* @param limit Number of rows to return
* @param offset Offset to start from in result set
* @return Query
*/
function limit(limit[, offset]);

/**
* Performs an INSERT query
*
* @param table name of table
* @param data Key-value object containing the data in column-value order. If not supplied, set() is neccesary
* @return Number with insert id, or 0 if no insert id, -1 on failure
*/
function insert(table[, data]);

/**
* Sets a value for insertion or update
*
* @param column Name of column
* @param value value for column
* @param object key-value store
* @return Query
*/
function set(column, value);
function set(object);

/**
* Executes an UPDATE query.
*
* Can be used with WHERE etc clauses, and with set()
*
* @param table name of table
* @param data key-value store of data
* @return Number of affected rows, 0 on no change, -1 on failure
*/
function update(table[, data]);

/**
* Executes a DELETE query
*
* Can be used with the WHERE etc clauses
*
* @param table Name of the table
* @return Number of deleted rows, 0 on no deletion, -1 on failure
*/
function delete(table);
}

class Result {

/**
* Get the full dataset in an array
*
* Array-item per row. A row is a key-value object.
*
* @return Array of objects or null on failure
*/
function result();

/**
* Returns the result as a single row. If result has more than
* one row, only first row is returned.
*
* @param row Number of the row to return, default 0
* @return Object with key-value data
*/
function row([row]);


/**
* Gets the number of rows in the result
*
* @return Number of rows
*/
function numRows();

/**
* Gets the number of fields (columns) in the result
*
* @return Number of fields
*/
function numFields();
}


Comments so far?

// Rahkiin
Title: Re: Sphere for Mac <insert fancy name here>
Post by: N E O on March 07, 2014, 05:05:07 pm
How many sugar methods will be in the Query class, as many as possible or just the most common functions used for filtering?
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 07, 2014, 05:36:53 pm
In my post above, I actually just looked at the CodeIgniter manual. And it is all of them.

It includes nearly all possibilities for the 95% of all queries, and 99% of queries used by not-advanced DB users. (These are just guesses). Some are kind of sugar yes, such as whereIn(), whereNotIn(), orWhereIn(), orWhereNotIn(). In implementation this can be a single function with some arguments to change the behaviour. But when method chaining it is nice to have it like this, instead of a whereIn(...,'not','or') and whereIn(....,'not','and'), etc.

We could of course remove some or restrict some. For example, instead of allowing both where(column, value) and where(object), we could restrict to where(object) because JS has these short notation for objects: where({column:value}). That would make the list of 'aliases' smaller.

Since I had a more advanced DB course, and as I, when doing real database stuff, do many joins and advanced stuff, I often write my queries by hand using transactions, sql switch cases and that kind of funny stuff. I would never use orWhere(), orNotLike(), notLike(), etc, myself because then it is easier for me to just write the query. But I am not sure about the less advanced game developers around.
The advantage of all these methods is that they should protect against attacks by escaping values etc.

On an update on my engine: currently tackling an awful problem in the JavaScriptCore that is shipped in iOS7 and OSX10.9: trying to hack around it now, or else import JSC from the WebKit repo. (If I have to import, I will not be able to do any iOS testing or publishing until there is iOS8 with an updated JSC).

// Rahkiin
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Flying Jester on March 07, 2014, 05:56:01 pm
A Bonjour plugin for TurboSphere would actually be cool. Makes me wish I had a newer Mac to build it with.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 07, 2014, 06:00:17 pm

A Bonjour plugin for TurboSphere would actually be cool. Makes me wish I had a newer Mac to build it with.


How old is your Mac that you can't? A PPC?

Is there need for UDP transfers? Isn't it very useful for most games? Not sure how useful it is in the games made in Sphere.

// Rahkiin
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 07, 2014, 07:34:25 pm
Even though the JSC ObjC API should be mature, it is not. The changes made since the release of OSX and iOS are quite major (security, memory and correct functionaility wise).

Result: I can't have correct classes :D
Temporary solution:
Code: (javascript) [Select]

var fs = new __FileSystem();
FileSystem.createDirectory("a");


Constructors need an underscore prefix...

Be right back, crying in a corner...

(edit - fixed code tags ~neo)
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Flying Jester on March 07, 2014, 07:45:45 pm


A Bonjour plugin for TurboSphere would actually be cool. Makes me wish I had a newer Mac to build it with.


How old is your Mac that you can't? A PPC?

Is there need for UDP transfers? Isn't it very useful for most games? Not sure how useful it is in the games made in Sphere.

// Rahkiin


G3 900 MHz, Mac OS X 10.3.9, and proud of it :)

TurboSphere will never work for machines with CPUs that can't run Android. It's the curse of Google V8.

The networking aspect of Sphere is actually more used than you'd think. It's very nice to have raw BSD sockets exposed to JavaScript.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 07, 2014, 07:50:16 pm
Awesome!

The current networking in Sphere can only do simple TCP sockets. So I wonder, should I design an interface to add UDP transfer? Then networking has TCP, UDP and Bonjour for zero-conf.

I have been able to use v8 on my mac :) Built myself and I have an ObjC wrapper on top of it, also working. (But untrusted by the developer. Me). Also, V8 is used in Google Chrome, so it also works on Windows and Mac OSX.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 07, 2014, 10:23:17 pm
Speaking of networking:

On OSX and iOS, networking is all event based. So I open a socket, add it to the runloop and I will get an event when the socket opened, when i can write to it, when there is data, when there is an error, etc.
The current sphere socket is very POSIX like: blocking.

There are three options:
1) An async networking API. Has many advantages for both me and the performance of games. Using it gets harder though. Async API can be build with anonymous functions.
2) A blocking API, by using wait loops (awful, especially on slow networking devices like mobile phones)
3) An advanced async API with a Blocking API on top (using queues etc).

Going async is also useful when adding UDP later. But what are the thoughts on this?
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Radnen on March 07, 2014, 11:51:20 pm
Well, for example, XNA has async menus and actions, it's not necessarily networking but threading in general. I'd go for anonymous functions and async API any day. Don't worry if it's too hard, you are likely going to be a pro scripter by the time you add networking to your game and we can always write tutorials.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: N E O on March 08, 2014, 01:52:08 am
I've been playing with Firebase recently, so lately I've been partial to its inherent asynchronicity (damn Google Chrome says that's not a word :(  ). The only real problem I see with async is basically the same problem as threading, that is, conflicting simultaneous writes to any given piece of data at any given time.

If you start off async but add some sort of locking mechanism or something to voluntarily render it blocking that should theoretically be worth the extra programming effort, right?
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Flying Jester on March 08, 2014, 01:59:07 am
synchronicity (damn Google Chrome says that's not a word :(

Asynchronaeity.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 08, 2014, 08:32:59 am
Well, async it is then!

I looked at WebSockets API for ideas. I found this: socket.io (http://socket.io). It is somewhat a way higher API tho, more into the actual object-data sent. I think it is an awesome approach for most networking games (to use objects, strings, arrays and numbers as data, and not some complex ByteArray that most often contains a series of strings anyways).
Title: Re: Sphere for Mac <insert fancy name here>
Post by: N E O on March 08, 2014, 01:08:00 pm
The Sphere networking API IIRC was primarily designed to let the server handle processing the data given. That's probably the main reason Sphere networking client code sends raw bytes (which is what a Sphere ByteArray is).
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 08, 2014, 01:34:41 pm
Alright. I am now looking into Node.js and its APIs. Is all event based and I think it quite fits for Sphere. Especially the modularisation. After I have modularisation I am continuing on networking API.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: DaVince on March 08, 2014, 02:29:59 pm
Pretty extensive. With all those (planned) improvements I just hope you can make it cross-platform, as I'm primarily a Linux guy myself. :)
(Also, Sphere for Mac, eh? You should call it Smac!)

Also noticed you gave push access on the Git repo for this, but... I'm definitely not apt at C languages and not a very good coder all around. (It's very hackish and usually "written for my own purposes" stuff.) So not sure I'd be contributing to that.

As for features... Could you look into reviving/improving the SPK format? There's been some talk on the forums around this (either the TurboSphere or Sphere-SFML thread) and I've always found the idea of a package format useful and interesting.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 08, 2014, 02:36:25 pm

Pretty extensive. With all those (planned) improvements I just hope you can make it cross-platform, as I'm primarily a Linux guy myself. :)
(Also, Sphere for Mac, eh? You should call it Smac!)

Troubles are that some frameworks are not available in GnuSTEP (the Foundation etc for Linux). I will make 'Smac' work for OSX and iOS at least. Windows will be big troubles because, well, its Windows. As said, it is Objective-C, and that is all pretty mounted to Apple. (There is GnuStep as I said, and there is ObjFW but that is not very usable for games).


Also noticed you gave push access on the Git repo for this, but... I'm definitely not apt at C languages and not a very good coder all around. (It's very hackish and usually "written for my own purposes" stuff.) So not sure I'd be contributing to that.

Yeh that is because I want you guys to see the code, and the repo is private. I can either add your there or not add your at all. :) One day I will make Jarvix and organizational account so I can do more options on that.
I think I will push 'making the code publishable' forward on my todo list.


As for features... Could you look into reviving/improving the SPK format? There's been some talk on the forums around this (either the TurboSphere or Sphere-SFML thread) and I've always found the idea of a package format useful and interesting.


I read about the SPK format. A screwed up ZIP library? I never used it or saw anyone use it and the code in the Sphere repo looked tiresome so I walked past it. We can definitely look into packages.
I am currently working on Javascript modularity. That can work together with packages containing resources...

// Rahkiin
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 08, 2014, 02:56:50 pm
Bah, I seem to talk way too much in this topic. :)

I wanted to give you guys an update on a Bonjour API I designed. I have not implemented it yet (pending modules) but I tested it.

Code: (javascript) [Select]

net.Bonjour {
// domain defaults to "", which results in .local
// type defaults to "_game._tcp"
function Bonjour([type, [domain]])

var type; // String
var domain; // String

var state; // 'publishing', 'published', 'discovering'
function isPublished(); // Boolean

// publish a new service with known type and domain
// name defaults to "" which causes the system to use the computer name
// if no callback is supplied, no notification made about the status
// cb = function(error, status)
function publish([name],port,[cb])

// discover services with known type and domain
// cb is function(error, Bonjour.Peer);
function discover(cb)

// resolve a name to a host and port
// cb = function(error, host, port)
function resolve(name, cb) // to host+port

// Stop publishing, resolving or discovering
function stop();
}

net.Bonjour.Peer {
var name;

// resolve the peer to a host and port
// cb = function(error, host, port)
function resolve(cb)

// returns net.Socket, not connected but intialized
// only connect() will then be needed.
function getSocket();
}


This is not definite! It is just to give you an idea of what the result of such Bonjour API would be.

Usage is very easy:

Code: (javascript) [Select]


// Game that will host:
// Create a server
var server = new Server();
server.listen(12345, function(error, status, peerSocket) {
if(error)
throw error;
if(peerSocket) {
console.log("New Peer with address "+peerSocket.remoteAddress);
} else
console.log("Listening!");
});

// Publish the service
var service = new Bonjour();
service.publish("My Awesome Name",12345,function(error,status){
if(error)
throw error;
console.log("Published service!");
});


// Game that wants to play:
var service = new Bonjour();
service.discover(function(error, peer) {
if(error)
throw error;
console.log("Server found: "+peer.name);

// Assume we want the first hit, to omit a UI now
// stop the service
service.stop();

// connect to the peer
var socket = peer.getSocket();
socket.connect();

// ... do whatever
});


Roughly, this creates a listening game server, a client that finds the server automatically and connects to it. No IP address passing, no port number stuff. :) That's the idea, at least :P

// Rahkiin
Title: Re: Sphere for Mac <insert fancy name here>
Post by: DaVince on March 08, 2014, 04:44:32 pm
SPK is just a Sphere-game-in-a-file type deal that didn't seem to get much traction. Possibly because it had some bugs, or it closes off the source, etc. We were considering supporting a new type of SPK that's basically just a zip or tarball or something instead. In any case, the Sphere engine is able to open SPK files directly, which was the main advantage to it.
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 08, 2014, 07:02:31 pm
I have good, and bad news.

To start with the bad news: I am getting seriously annoyed by JavaScriptCore and its ObjC API. it is very incomplete and I can't do many things I want to do. Because its binary is delivered on the system, running it myself gets messy.
So I am deciding to pick up my L8Framework again: My ObjC wrapper of V8. I have more working functionality in there. I just need to fix retain cycles and do much profiling to find and solve bugs and so on. But I might find them while working on Sphere.

More bad news: Until I can make it work with JSC, it is not possible to have an iOS version :(

The good news: I can lower my system dependency from 10.9 to at least 10.8.
Also, it might theoretically be slightly possible to port my project to linux (using V8, a ported L8 and GnuStep).

Blugh.  :'(
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Harry Bo21 on March 10, 2014, 02:22:13 am
Would I be right in thinking Isomorphic, Is 2d images converted to the Isometric perspective?

If that is the case, Is there a chance we could have both?

Alot of people reuse old resources, I have a lot of Isometric stuff, would prefer it not to be redundant  :)
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 10, 2014, 02:24:49 am
Could you post those images here / send me the images in a PM so I could, later, use them for testing etc?
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Harry Bo21 on March 10, 2014, 02:30:20 am
Once I get home, sure :)

Quote
You should call it Smac!)


I really like this! And if you make it cross platform. Smac for Linux, Smac for Windows

I like that a lot :) (DaVince always has the best ideas)
Title: Re: Sphere for Mac <insert fancy name here>
Post by: Rahkiin on March 10, 2014, 10:00:50 am

I really like this! And if you make it cross platform. Smac for Linux, Smac for Windows

I like that a lot :)


Positive comments. I think the name is easy pronounceable, rememberable, has an origin and is funny (due to that too greasy 'meat').

Smac it is :)

'Sphere for Mac for Windows', Smac for Windows. This does get complicated :P
Title: Re: Sphere for Mac: Smac
Post by: DaVince on March 10, 2014, 01:53:44 pm
I mostly just said "Smac" to be funny, but if you actually want to use it... Well, no one's stopping ya. :P
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 10, 2014, 06:06:44 pm
I figured that I should keep 'Sphere' in my name, or I need to change all class names, framework names and code of my whole project.

xD
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 10, 2014, 06:20:37 pm
MacSphere would be more classic.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 10, 2014, 06:25:41 pm
Yeah, fits better indeed. Trouble is, that I might try to get it running on Linux some day.
Although, I do not see the use of running it on Linux as there is TurboSphere for Linux, right?
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: N E O on March 10, 2014, 06:58:01 pm
Eh, I guess we'll have codenames for internally referring to the Sphere projects.

As a point of consistency, the official name of the official "vanilla" version of Sphere, whether on Windows, OSX, Linux, iOS, Android, whatever, is the Sphere Game Engine, or Sphere for short. Sphere also refers to the working API and formats for devs to use when making their projects, therefore a Sphere-compatible project is a project that should work on all variants/forks of Sphere itself and all engines claiming to be Sphere-compatible because it doesn't rely on enhancements to either API or formats not available to the "vanilla" Sphere engine.

Vanilla Sphere is the codename of the official version of the Sphere engine; the current Windows Sphere, Mac Sphere, and Linux Sphere all share this codename so we've been using Mac Sphere and Linux Sphere to refer to the *nix variants and just Sphere to refer to the original Windows variant. Vanilla Sphere on all platforms uses Mozilla SpiderMonkey for JavaScript and attempts to use native OS capabilities for I/O when possible and falls back to SDL otherwise depending on the OS. I wouldn't mind calling the shared codebase of OSX and Linux Sphere's "XSphere" though ;) A slew of devs over the years have done work on vanilla Sphere at various points.

TurboSphere, or TS for short, is Flying Jester's (mostly) Sphere-compatible engine with non-standard enhancements (though I wouldn't mind useful enhancements being folded into vanilla Sphere) using V8 for JavaScript and explicitly using SDL for I/O. I'm not aware of any particularly different codename for it since we've been referring to it as TurboSphere, Turbo, or TS.

Sphere SFML, or SSFML for short, is Radnen's Sphere-compatible engine done in C# with Jurassic for JavaScript and SFML for I/O. No other codename to my knowledge.

Web Sphere is the codename of the official version of the (currently incomplete) Sphere implementation for web browsers. It has multiple variants based on the framework(s) being used for the I/O shim.

casiotone started work on a Sphere-compatible engine but it's not complete.

I'm not aware of any other active Sphere-compatible engines in progress before Rahkiin's entry into the field. Personally, as I've said once or twice before on this board I would love for one or more of the newer Sphere-compatible engines to actually succeed vanilla Sphere since it seems that the barrier to entry for adding to or even maintaining it is becoming harder to overcome as time passes. Radnen's editor is already fast becoming the de facto replacement of the vanilla Sphere Editor for new and old users alike and the only thing really preventing outright replacement is its primarily Windows construction.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 10, 2014, 07:21:45 pm
@Rahklin: That's not an unfair assessment of TurboSphere...sigh.

Just to add to what Neo said...because I can't resist an opportunity to eschew obfuscation of the goals of TurboSphere!  ;D

TurboSphere is many things. It's full of shininess--it has a very flexible plugin system, a threaded graphics system, support for a huge variety of filetypes (all Sphere filetypes, all of Sphere 1.5's supported audio/graphics, and additionally can use Modular music files, Midi soundfonts, vector graphics, PostScript-style bitmapped fonts, and truetype fonts), uses bleeding edge versions of V8 and SDL 2. SDL2 forms the basis of its software rendering backend--which is highly asynchronous, and supports surface operation reordering, and performing them out of order and in parallel.

But it's also supposed to be fast. That's why I started it, good ol' Sphere 1.5 was getting too slow, particularly in a couple pseudo-3D tech demos I wrote and some pathfinding systems that Radnen and Beaker (among others) wrote. And it is fast, breaking through the limits of Sphere 1.x all over the place. Sphere-SFML may be faster, though. It seems like, in raw JS power and some graphics benchmarks, TS beats Sphere-SFML, but there are cases where Sphere-SFML is faster. It really depends on what you are doing and how you do it.

TurboSphere is supposed to be cross-platform. All native C and C++, with Unix and Win32 backends. It's just that I don't use Windows very much, and don't own a V8-capable macintosh, so it tends to be tested and developed in Linux, and released for Windows on special occasions.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 10, 2014, 07:26:40 pm
Too bad, I think my runtime will not be able to succeed Vanilla Sphere, for a single reason: portability. I won't be able to port my runtime to Windows. I might be bale to port it to Linux though. That would make it the only native *nix runtime.

That of course does not mean it, or TS, can't be the new standard. I add a lot of modern-age functionality, paradigms, etc to my engine. Also I try to keep it modularised so it can be used for other projects. (For example a file viewer). TS is plugin based and also has new functionality. We could look together in a 'Sphere 1.7' or 'Sphere 2.0'. Not a runtime, but rather a 'Standard'.

The Vanilla code is indeed messy. :)

For a code name, I named my repository JSphere, as J is the first letter of both my company's name and my name (not a coincidence. Or is it?). I could go with that codename.
In my code all over, I have been using plain Sphere  ;D Now I know I should not as I am not part of the Sphere Group and it is not the official engine, but when I started the project I assume 'Sphere' as the collection of the JS library and the file formats. Not as the runtime itself. (Concept vs Object).

So I guess this is it now:

Vanilla / Vanilla Sphere = Official engine
TurboSphere / Turbo / TS = Flying Jester's engine
Sphere SFML / SFML = Radnen's engine
JSphere = Rahkiin's engine
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Radnen on March 10, 2014, 09:26:29 pm

Sphere-SFML may be faster, though. It seems like, in raw JS power and some graphics benchmarks, TS beats Sphere-SFML, but there are cases where Sphere-SFML is faster. It really depends on what you are doing and how you do it.


Yeah, well I realized the JS engine really isn't the bottle-neck most of the time. SFML uses GL underneath and so technically can be just as fast as your code graphically. Plus it does depend on your hardware. Now, you are using V8 so I suspect that hand-written 3D engines or other pieces of code that does a lot of on the fly calculations will perform faster in your environment. My engine is really tailored to be faster under normal Sphere use: the map engine, menus, and other such things. Yours might be on average faster on an all-around basis. Oh and I couldadd plugin support to my SSFML, it's just a matter of time. But these plugin's would be more along the lines of functional additions where you write the code in C# and use the plugin to expose it to the engine. In this way custom battle systems and map engines can be made apart from the core engine. It'll still remain with it's largely monolithic graphics and input backend.

@Rahkiin: don't worry about portability too much. If you can target mobile devices (iPad or iPhone) with your engine then I'd say that's a huge win. It turns out that cross-compatible engines are messy to write and hard to maintain. Jest can attest to that by trying so hard to make sure TS works across *nix and Windows. It's hard! I have the stability in my engine since it's only for one OS. Since there are a lot of indie game developers, especially XNA users, this was my motivation to make Sphere for Windows. I have looked into Mono for SSFML, but it seems Mono is an incomplete library (still) and does not support some features that .Net has which are crucial to the operation of my engine. My Sphere Editor on the other hand has a shot at being cross-platform under Mono. I just need to find the time to do any conversions or research in order to make it work. But then that really requires me to coordinate among people with different OS's, which is a huge pain.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 11, 2014, 07:12:35 am
@Radnen Thanks for the tip. I will then focus completely on the Apple devices with my Sphere software (I will probably make L8 work for ObjFW). My editor will also be very native with all kind of special Mac stuff, much like Xcode. But that is for later.

I switched my project completely to L8 (V8) now that I made a lot of updates to the framework. Still have to do some major profiling, some caching and some tiny features but that's it. Then I can go on with the runtime.

I might update L8 later to be fully compatible (API) with JSC so that I can use JSC on the iOS version (iOS8).
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: alpha123 on March 14, 2014, 11:01:57 pm
I suggest just keeping it Mac-exclusive. You can't really have a native Mac app that's portable; Apple's frameworks make sense on OS X and not really anywhere else (plus they're not really implemented anywhere else).
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 14, 2014, 11:52:31 pm
They could make sense on FreeBSD with GNUStep =P
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: alpha123 on March 15, 2014, 01:34:58 pm
FreeBSD FTW! ;D

GNUstep is kind of a joke though. I think I looked at it once and sort of lost interest once I realised they'd only implemented to like OS X 10.4 or something similarly old.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 15, 2014, 05:58:14 pm
OS X 10.3.9 FTW!
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: N E O on March 15, 2014, 06:45:52 pm
OS X 10.4 was the first to offer an Intel-powered variant; if they've reached that stage and the code has already been optimized I reckon the only thing left really is compatibility hacks to simulate those versions after.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 16, 2014, 06:10:46 pm
GNUStep is not an implementation of Foundation/Cocoa/AppKit for the GNU OS. It is rather an implementation of the NEXTStep libraries. At about 10.4 and later, when OSX became more and more popular, new stuff was added to OSX which was never part of NEXTStep. It is also a lot of work to get it all working if you need to write something for many distro's and platforms, and you have to rely on GNU :P For example, Apple uses kqueue for async stuff and GCD (libdispatch, which is open source).
I am not really going to put time in GNUStep. If it doesn't work, it doesn't. I do allow Pull Requests :P

Talking of open source: the Sphere Vanilla does not state any license, other than the defaulting all rights reserved. Does it have any open source license?

OSX and iOS are not so far apart. They both run Darwin, have Foundation, Cocoa (Touch), and many of the frameworks. :)
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 16, 2014, 08:22:00 pm
Sphere 1.x is GPL2.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Fat Cerberus on March 16, 2014, 09:53:06 pm
Like Jester said, GPL2.  The license is actually included, it's in the docs folder.  legal.txt states it's GPL and the actual license is in gpl.txt.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 16, 2014, 10:37:15 pm
Hmpf. I don't think I am in violation much. I did not copy any code :) Not really anyways.

Currently still working on L8Framework. Now, to make it more like JSC, and I was working on a debugger (thought that would be nice). But for the time being, D8 can be used.
This week I want to continue on the runtime itself. Probably pushing graphics more forward, cuz that is hard :P
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Radnen on March 17, 2014, 01:32:26 am

Hmpf. I don't think I am in violation much. I did not copy any code :) Not really anyways.


Don't worry about violation; I doubt any legal action will happen even if you stole everything. Unless you make millions, of course. :P

I think it's safe to say Vanilla Sphere is so old, it's kinda public domain by now. Software even lightly maintained depreciates very, very quickly. There have been far more better engines made since. All we can do is use it's legacy as inspiration. I even repurposed some code from it, especially for my map engine just to make sure things ran the same between my engine and it. In fact I'm amazed how simply programmed the monstrous map engine was.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 17, 2014, 02:11:14 am
I intentionally do NOT use any code directly from Sphere, but that's because I want TurboSphere to be BSD/Zlib licensed. The exact reasoning is so that you could integrate the steam API library into a plugin, and sell such games on steam. The idea being that Valve might be more discerning than I am about the license of Sphere, especially since I plaster the name `Sphere RPG Engine' over all of the TS documentation and provide links about it.

Of course, since I do not take any code from it at all, TurboSphere tends to support less than Radnen's projects do, like only reading the newest versions of the Sphere resources. My tools also tend to make ever so slightly malformed or strangely formatted resources--my SPK editor makes hard to decode SPKs, with the file map at the end instead of the start, for instance, and my ttf-to-rfn converter makes rfn files that contain tons of extra blank characters.

So I guess that's what happens when you don't borrow code =P
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Radnen on March 17, 2014, 03:41:21 am
Well, I can't copy paste C++ to C# code. Plus I argue the point of code in general, which is basically used to implement an algorithm and the algorithm, specifically the person command-queue must be made compliant so things like Lord English's Scenario work between my engine and Vanilla Sphere's. So while I say I "took code" I really just copied an algorithm. If Valve wants to get into a legal dispute with me I'd say let them. Because I'd also like to put their API into my engine. The GPL doesn't or at least shouldn't cover "ideas" like the person command queue. I'd wager, unless you have solid copy-paste proof (ex: revealing comments were copied over), I'd say it's nearly impossible to tell.

Thankfully the Sphere Engine brand wasn't trademarked or we'd pay royalties for the use of the name. lol
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 17, 2014, 04:48:30 am

Well, I can't copy paste C++ to C# code. Plus I argue the point of code in general, which is basically used to implement an algorithm and the algorithm, specifically the person command-queue must be made compliant so things like Lord English's Scenario work between my engine and Vanilla Sphere's. So while I say I "took code" I really just copied an algorithm. If Valve wants to get into a legal dispute with me I'd say let them. Because I'd also like to put their API into my engine. The GPL doesn't or at least shouldn't cover "ideas" like the person command queue. I'd wager, unless you have solid copy-paste proof (ex: revealing comments were copied over), I'd say it's nearly impossible to tell.

That's why I mention that my implementations differ in the resulting files (which are still technically compliant).
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 17, 2014, 10:08:00 am
And API's are not copyrightable :) And I agree about algorithms. The BSD license makes it so much easier :P
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 22, 2014, 06:44:31 pm
I have designed most of the new JavaScript library. Everything except Surface and Map (so I actually only did half of the whole library :P).

I've put it all in a gist. On the left side the 1.5 function, on the right my functions. When I add functionality that did not exist, the left side is empty.



I would appreciate it if you could look in it and give comments :)

//Rahkiin
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 23, 2014, 10:04:03 pm
If you aren't worried about breaking direct compatibility:

Lose the ByteArray object and use native JS typed arrays.

A Delay() method that at least partially sleeps the engine would be cool. It makes your engine appear nicer, since games don't just take 100% of the CPU time they can.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 23, 2014, 10:19:40 pm
I don't have TypedArray support in L8 yet, so I can't handle them when writing to files :P But I will look into that as an improvement later.

I am probably breaking compatibility already, because I am introducing Game.init(), loop() and exit(). These would be defined by the game and called by the engine upon start, run and exit. The loop() function is called repeatedly. I need to do this because everything has to run on the main thread, and because my engine is Async, the JS code can't be blocking.

I will definitely add a delay function. System.sleep(double seconds) good?
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: DaVince on March 24, 2014, 11:47:44 am
Sphere actually has a really convenient function SetFramerate() which FlipScreen() seems to always rely on. It basically adds the right amount of delay. Would be nice if you could add that in there, since it completely removes any worry about having to use timed loops to get 60 FPS for example.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 24, 2014, 04:54:49 pm
My rendering loop will already be tight to the framerate of the display using CVDisplayLink, so it is already limited. But ill look into it.

FlyingJester, Radnen and I talked yesterday (today? err) about making a new incompatible sphere runtime. It came to mind when I found that GetKey() is very hard to implement for me, because it is Blocking and my whole runtime is non-blocking.
The 'Sphere 2.0' would have the OO API much like mine (shims can make them functions again) and graphics will work differently with vertices and masking and matrices (plus utility functions for applying rotations etc). Also, everything would be async and a game state manager would be built-in. It creates a much more responsive engine and game.
JavaScript like while(1) is what I walked against when writing my engine and in web-sphere.

I think it gives opportunity.

Due to the impossibility of a while(1) game loop in a sphere game for my engine (even if I don't redesign it), makes it already incompatible. So it is not a loss :P

// Rahkiin

Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Radnen on March 24, 2014, 04:59:38 pm
It also makes games going between web-sphere and desktop-sphere easier since the web works like what Rahkiin proposes. I could write the web-frontend (finally) and have it work. I think the fact the Sphere 2.0 API being largely incompatible is brilliant. Otherwise there is no way of easily converting a sphere game to web or to a non-blocking engine like Rahkiin proposes.

It'll simply bring Sphere into the 21st century (finally).
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 24, 2014, 05:04:00 pm
We just need to design it :P On IRC, that is.

Ghehe, just thought about it: the API is 11 years old (2003, nobody uses 1.6..) and what was in that year? There was no google! It was 4 years before the smartphone appeared. There was OSX 10.2 and Windows XP was just released, together with Office 2003. Chrome did not exist, everybody used Internet Explorer. It was that time! And I was 9... 2 years before I started programming.

Just some perspective.

// Rahkiin
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 24, 2014, 08:34:08 pm
I support this idea.


2003, nobody uses 1.6..


I use 1.6 beta 4. Of course, I am the only one using Sphere natively on Linux (probably in the entire world).
But it's not like 1.6 changed much about the API.

Also, I used Netscape back then. Because I'm just a brown-coat or something =P
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: N E O on March 24, 2014, 08:54:42 pm
The JS-based API is technically a little older than 2003. For reference, I found Sphere in late 2003/early 2004.

Ideally I'd like to see 1.6 finalized on all three platforms first before the massive API shift that is intended to be "Sphere 2.0." kyuu previously attempted to similarly make such a Sphere 2.0 by himself and he quickly got fed up with it, switching from a JS scripting engine to Squirrel and opting instead to create a new engine. I don't want to see another quick flame-out due to an engine update attempt and lose another good programmer to the programming equivalent of insanity ;)
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 24, 2014, 09:10:07 pm
Yes well, as far as I know, it the non-graphics will look a lot like my current design (and implementation), like networking and input and file system. I had not started on graphics yet.
We either do this together, or I have an non-compatible sphere engine for OSX alone :)

Finishing 1.6 and then doing 2.0 doesn't sound like a good idea to me. 1.6 has a userbase of 0 and has functionality that none of the other engines has, like particle systems.

// Rahkiin
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Flying Jester on March 24, 2014, 10:36:07 pm
I'm with Neo.

I use 1.6, as does (or did) Radnen.

Finishing 1.6 means we will have an engine that is about twice as fast as 1.5. I've tested, and there are some cases where it is orders of magnitude faster than 1.5.
It also will take monumentally less work than any of the new engines will to finalize 1.6. I've already got Corona and Audiere working with new compilers and new thirdy-party libraries, I have 1.6 running stable on Linux.
I've created a modernized (as much as possible) graphics backend for 1.6, which works on Windows and Linux, and (since I borrowed a little code from SphereGL) I am confident has no show-stoppers in it. At least, no more than SphereGL does.

I can say from experience that the issues facing 1.6 going gold are not that severe.

That leaves only the handful of bugs in 1.6. Most of them could easily be solved by someone who knows more about the map engine than I do. In fact, many of the bugs also exist in 1.5, and are simple fixes. We (and by we, I kind of mean myself and anyone else willing to touch the 1.6 source) just need to identify the bugs, find where they are, and either fix them or mark them as `won't fix'. And I really, really don't think many should be `won't fix' issues.

The particle system is one of the planned plugins for TurboSphere. So is the sound effect generator. A lot of thought and work went into those APIs, and although I know almost nothing about the particle system, I really like the sound effect API.
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: Rahkiin on March 24, 2014, 11:05:29 pm
I am totally fine with you (Radnen and FlyingJester) updating your engines to support 1.6. But I have not an engine that does 1.5, so I am not going to implement first 1.5, then also 1.6, with all problems I have with those APIs due to async stuff, only so I can then work on 2.0 that has not the problems I have with 1.x :)

// Rahkiin
Title: Re: Sphere for Mac: <insert fancy name here>
Post by: N E O on March 25, 2014, 03:02:50 pm
The particle system stuff, however powerful it is, is possibly the most complicated API added for 1.6; the SoundEffect and SFXR stuff looks simple in comparison.

I'm fine with 1.6 having a staggered release depending on when system-specific issues get resolved. Previously one of the stopping points was that neither Rhuan nor myself was able to go in-depth on the Mac builds (there were issues either with updating zlib or updating SpiderMonkey, can't remember off the top of my head) so OSX compatibility held up 1.6's improvement for a long time. If Sphere 1.6 compiles on MinGW especially I will be ecstatic.
Title: Re: Sphere for Mac: Andromeda
Post by: Rahkiin on April 14, 2014, 12:33:11 pm
I would like to make a small notice:

Sphere for Mac, before also called JSphere (by me alone), is from now on called: Andromeda. And it implements the Pegasus API. (They are both constellations :D)

// Rahkiin
Title: Re: Sphere for Mac: Andromeda
Post by: Rhuan on October 18, 2014, 11:14:29 am
Just a note on the mention of what happened with 1.6 and osx I believe the issue was that 1.6 depended on a newer version of spider monkey which was not PPC compatible at all some of its source was actually in assembler if I recall correctly and I didn't have the knowledge to even know where to start porting that (well the starting point would have been to spend months studying...) I'm sure an intel mac port of 1.6 wouldn't be too tricky but:

I still only have a PPC Mac and so can't help with newer versions. (I have a work computer I'm not allowed to install my own programs on but that otherwise does everything I need hence buying a new computer would be for fun/hobby purposes only and it's a lot of cash for such)
Title: Re: Sphere for Mac: Andromeda
Post by: Rhuan on October 18, 2014, 11:22:55 am
Yes double posting... But significant change to previous post.

I have 1.6 running on my old PPC mac.

Can't remember when I compiled it successfully or what dirty hacks I did to the source to make it work, it must have been years ago.

The binary is universal so should run on Intel.

Said mac has no internet connection anymore though so I can't think of a way to distribute it.

Did I really not share it with anyone way back when?


I've also just found what I think is the Xcode project I used to compile it, but it throws a 1000 errors if I click compile now... :(
Title: Re: Sphere for Mac: Andromeda
Post by: N E O on October 18, 2014, 01:13:50 pm
Said mac has no internet connection anymore though so I can't think of a way to distribute it.

Did I really not share it with anyone way back when?


I've also just found what I think is the Xcode project I used to compile it, but it throws a 1000 errors if I click compile now... :(


Zip it up, put it on a flash drive, bring that flash drive to your work Mac, then send it to me and I'll upload it to Spherical. Send me that project source as well.

I don't have any working compiled copies of 1.6 Mac from you or compiled myself, otherwise I'd have put them up when I restored Spherical. I think you gave me some XCode project that was an attempt at 1.6 but I never got it to successfully compile on my Intel 10.5 Leopard MBP at the time.
Title: Re: Sphere for Mac: Andromeda
Post by: Rhuan on October 18, 2014, 02:34:00 pm
I'd have to buy a flash drive then use a friends computer to email it. I might do at some point but it won't be soon.

The reason for the project not compiling seems to be two fold:

a) loads of hard coded locations for dependencies (and I've moved stuff around)

b) at least one dependency I deleted to save disk space... :(

Also I've looked it over and it may not have some of the features 1.5 should have as I think it still uses JS 1.5.