Skip to main content

News

Topic: Sphere for Mac: Andromeda (Read 17474 times) previous topic - next topic

Re: Sphere for Mac <insert fancy name here>
Reply #15


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.

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #16
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.

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #17
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?

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere for Mac <insert fancy name here>
Reply #18
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere for Mac <insert fancy name here>
Reply #19
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?

Re: Sphere for Mac <insert fancy name here>
Reply #20
synchronicity (damn Google Chrome says that's not a word :(

Asynchronaeity.

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #21
Well, async it is then!

I looked at WebSockets API for ideas. I found this: 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).

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Sphere for Mac <insert fancy name here>
Reply #22
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).

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #23
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.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere for Mac <insert fancy name here>
Reply #24
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.

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #25

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

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #26
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

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere for Mac <insert fancy name here>
Reply #27
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.

  • Rahkiin
  • [*][*][*]
Re: Sphere for Mac <insert fancy name here>
Reply #28
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.  :'(

Re: Sphere for Mac <insert fancy name here>
Reply #29
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  :)