Skip to main content

News

Topic: Pegasus: Sphere 2.0 (Read 3268 times) previous topic - next topic

  • Rahkiin
  • [*][*][*]
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

Plans

  • More flexible and powerful graphics engine.

  • Asynchronous networking.

  • Non-blocking input handling

  • JSON based sphere file formats

  • More...



Participating
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: https://www.github.com/sphere-group/pegasus
Generated API documentation: http://sphere-group.github.io/pegasus


// Rahkiin
  • Last Edit: March 26, 2014, 08:22:32 pm by Rahkiin

Re: Pegasus: Sphere 2.0
Reply #1
I've been talking with Radnen and Rahkiin on IRC. We've been speaking of what a more modern API would actually look like.

Here is an example of what I would like to do with the graphics API (the descendant of the SpriteBatcher). I've included a demo mock-up of it.

There are two concepts that are really different from Sphere Classic here. One, that there aren't really primitives anymore, and two that everything is textured. A `primitive' is a collection of vertices, a masking color, and a texture. To be untextured, you would just use a one-color texture. Shapes would be objects, which can be blit (much like images), although their location on screen is inherent to them.

For example, this:
Code: [Select]

Rectangle(16, 16, 48, 48, CreateColor(255, 0, 0));
would be duplicated as so:
Code: [Select]

var s = new Shape([new Vertex(16, 16), new Vertex(64, 16), new Vertex(64, 64), new Vertex(16, 64)], new Color(255, 0, 0), new Image(1, 1, new Color(255, 255, 255))
s.blit();


this:
Code: [Select]

Triangle(16, 16, 16, 64, 64, 64 CreateColor(255, 0, 0));
would be duplicated as so:
Code: [Select]

var s = new Shape([new Vertex(16, 16), new Vertex(64, 16), new Vertex(64, 64)], new Color(255, 0, 0), new Image(1, 1, new Color(255, 255, 255))
s.blit();


And here:
Code: [Select]

LoadImage(...).blit(10, 10);
as so:
Code: [Select]

var im = new Image(...)
var s = new Shape([new Vertex(0, 0), new Vertex(im.width, 0), new vertex(im.width, im.height), new Vertex(0, im.height)], new Color(255, 255, 255), im)
s.translate(10, 10);
s.blit();


While that is obviously more verbose for such a simple example, it makes the API much more generalized, which would make any scripts to simplify it or provide shorthand notations much more useful. It would also be trivial to make a shim that presented a 1.5-like API on top of this.

Shapes can share their textures (which are image objects), although their vertices are unique to each one (identity-wise, not value-wise).
Shapes have member functions like Rotate, Translate, Skew, etc. that are similar to what is provided for Images and Surfaces right now.

This idea has several obvious advantages:

  • This unifies images and primitives

  • All primitives are now one kind of object that has permanence.

  • This makes the API vastly simpler, and removes dozens of now redundant functions

  • This is how computers actually work, while still being very object-based



It makes the API nicer, and gives every single drawing operation many of the advantages of the old SpriteBatcher idea I had. It also makes the SpriteBatcher much simpler and nicer to use.

Moved from the TurboSphere topic ~FlyingJester
  • Last Edit: March 24, 2014, 11:46:08 pm by Flying Jester

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Pegasus: Sphere 2.0
Reply #2
I feel like members from a standards committee are coming together in order to create a new API version, or something. Well, I suppose it's like that but without the "committee" bit. :P

As for your suggestion: it looks pretty complex for anyone just wanting to get something on the screen, but it makes things much more flexible in how things are possible. The complexity is also not an issue if you still have the nice shorthand Rectangle() type functions.

  • Rahkiin
  • [*][*][*]
Re: Pegasus: Sphere 2.0
Reply #3

I feel like members from a standards committee are coming together in order to create a new API version, or something. Well, I suppose it's like that but without the "committee" bit. :P


Haha. We are just the developers of the runtimes for the 3 major platforms (Windows, Linux, OSX). Also, the development of the API is open source and everyone can participate. Currently that is at github.com/joskuijpers/pegasus, but this will be moved to github.com/sphere-group/pegasus.

// Rahkiin

Re: Pegasus: Sphere 2.0
Reply #4
Everyone who uses the forums is on the committee.

The complexity is also not an issue if you still have the nice shorthand Rectangle() type functions.


The more a game begins to work in an object-oriented manner, the less verbose it becomes. Most of the time, all the graphics API calls will be replaced with a Shape.blit() call. With a simple sprite batcher, you'd just call Batch.blit() for entire groups of Shape.blit() calls. You could then imagine the bare-bones function of a sprite batcher simply as:

Code: [Select]

function batch(shapes){
  this.shapes = shapes;
}

batch.prototype.blit = function(){
  for(var i in shapes){
    shapes[i].blit();
  }
}


So to draw an entire HUD, or an entire map, all you have to do is a single batch call. And because both the Shape object and Batch object is built into the engine, it can be optimized at a much lower level. It will also help to discourage calling cosntructors every frame--which is kind of a silly thing to do almost all the time, anyway. This API is supposed to encourage object-oriented programming, whereas the old API was not that well suited to OOP.

So a 1:1 conversion to this kind of API would, in fact, be quite verbose (long lines of code, even if the same number of lines). But most of the time, it should actually make things at least somewhat simpler and more logical.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Pegasus: Sphere 2.0
Reply #5
I see. The only thing I'm worried about in that case is - how would you keep the nice simplicity that Sphere currently has regarding this? Is more of a learning curve expected from the very newbies?

  • Rahkiin
  • [*][*][*]
Re: Pegasus: Sphere 2.0
Reply #6
We are talking mostly about internal stuff now. Most of it, if not all, can be shimmed to fit even the most noobest newbies.

Also, research-code tends to look nasty, but this will be worked out in time.

// Rahkiin

Re: Pegasus: Sphere 2.0
Reply #7
I guarantee that TurboSphere, up to and including at least version 1.0, will still have the old API exposed.

The old API is very easy to use. I wouldn't want to lose that, but I would hope that after a little use the new API would seem quite convenient and inviting.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Pegasus: Sphere 2.0
Reply #8

I see. The only thing I'm worried about in that case is - how would you keep the nice simplicity that Sphere currently has regarding this? Is more of a learning curve expected from the very newbies?


If it makes you feel any better, newbies can do this:
Code: (javascript) [Select]

require('sphere-compat.js')// name tbd
function entry_point() {
    CreatePerson('bob', 'bob.rss', false);
    AttachInput('bob');
    AttachCamera('bob');
    MapEngine('map.rmp', 60);
}


But, that's just a tentative example so the code will not look exactly like that in the end. Entry point might be an init method somewhere, exposed to global scope. Nevertheless, a newbie just need to learn one new thing to use the existing code-base: importing the old code base. That's basically it!
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

  • Rahkiin
  • [*][*][*]
Re: Pegasus: Sphere 2.0
Reply #9
However, the APIs are not compatible, we will indeed make a 'newbie' layer that uses old-style functions. It will be not be possible to create a shim to 1.x because there are radical changes.

But still: due to the nature of the Pegasus: everything is possible!

  • Rahkiin
  • [*][*][*]
Re: Pegasus: Sphere 2.0
Reply #10
The Pegasus API and designs are now available on GitHub. Please remember that it is all just research and drafts and that nothing is permanent at the moment.

Edit: It is no_w_ available, not no_t_ :P
  • Last Edit: April 23, 2014, 09:41:03 am by Rahkiin