The file currently stands at ~150KB. The file with the Sphere 2.0 API (pegasus.c) for comparison is around 80KB. That's a good thing I think: It will lower the learning curve for the new API if there are less functions, and the API will be more consistent because everything was designed together. Sphere 1.x slowly evolved over time and you can tell by some of the inconsistencies in how APIs are set up.

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

Yeah, back in 2004 I noticed how long the api was when I was making the python demo for sphere. But still, 5k lines is not unexpected, the ika source code for the script extension also takes up 5k lines as well, but in their case, it's split up over multiple files.

As time goes on more and more apis need to be created, that's just to be expected. The source for script.cpp in sphere v0.75 was only 46k.

The big thing that jumped out at me was that we had lots of graphics functions that could be coalesced, ByteArrays can/should be replaced with ArrayBuffers (ByteArrays were considered a hack by Chad Austin and several others to begin with), and the map engine.

Moving the map engine to script is the logical thing to do nowadays, so that solves that. Using a newer graphics API, or simply condensing the existing graphics functions helps there.

I do think that moving towards a polygon-based graphics API (Galileo-like or otherwise) is the way to go. Although in that case, something like TurboSphere's planned shapelib is a good idea, to easily generate basic shapes like rectangles, circles, etc., since it will help projects get up and running quickly. Likely most projects will move to the raw graphics API at least in part at some point, but it's important to have that first step be easy.

The rest of the API is pretty concise. There are warts here and there, but the rest isn't so bad.

I do think that moving towards a polygon-based graphics API (Galileo-like or otherwise) is the way to go. Although in that case, something like TurboSphere's planned shapelib is a good idea, to easily generate basic shapes like rectangles, circles, etc., since it will help projects get up and running quickly. Likely most projects will move to the raw graphics API at least in part at some point, but it's important to have that first step be easy.

The rest of the API is pretty concise. There are warts here and there, but the rest isn't so bad.

That's actually the purpose of my prim module which I originally linked to in the minisphere thread: It provides replacements for the classic graphics primitives, so that the engine only needs to expose the base Galileo API.

I want to provide several modules like that with minisphere 4.0 so that it's easier for devs to get up and running.

As for ByteArrays, I definitely agree they are a hack and not necessary now that we have ArrayBuffers and their ilk. minisphere provides them for backwards compatibility only, but they're pretty much deprecated--it's a dark corner of the code that I threw together in a couple hours and don't really bother to maintain.

And yes, the map engine accounts for a huge chunk of the API. At last count I think it consisted of something like 150 functions.

Last Edit: June 17, 2016, 01:23:59 pm by Lord English

miniSphere 5.1.3 - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan