Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8507946 times) previous topic - next topic
0 Members and 202 Guests are viewing this topic.

Re: minisphere 1.7.11

Reply #840 –
Well, that's good to know at least.  Still stupid that the PNG group thought it was a good idea to release a 1.5/1.6 and not keep it at least somewhat source-compatible with 1.2, though.  The API is completely different.  I know PNG predates semantic versioning, but even so, that's tacky.

That said, I removed the image processing for now as it was only being used to generate tilesets, but that's not useful as the resulting tileset has no obstruction data.  I haven't come up with a solution for that yet.

Re: minisphere 1.7.11

Reply #841 –
I'm pretty sure there were a large number of versions that had both APIs. I am sure Travis is just that out of date. No library has the same API forever.

The new API is much, much better, and means that there is no forseeable reason to ever break the ABI again. It also makes the library's ABI compiler agnostic (the 1.2 and older API was not).

Re: minisphere 1.7.11

Reply #842 –
No, I like the new API a lot, don't get me wrong on that. :)  It's just that they should have versioned it at 2.0 to make it clearer that the upgrade wouldn't be seamless.  Keeping the major version the same implies at least mostly-backward compatibility with code from the older version, which isn't the case at all.  It certainly caught me by surprise!

Re: minisphere 1.7.11

Reply #844 –
Hm, I'll look into it.  However, off topic, I found this:
https://github.com/dimensio/libpng16-deb/blob/master/README.md

Ubuntu, which Travis uses, includes 1.2.  The readme also says Debian is experimenting with adding 1.6, but there are apparently compatibility issues preventing it.  No idea why but that explains why the Travis build fails at least.

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #845 –
The first pre-release of minisphere 2.0 is now available, minisphere 2.0b1!  This includes a preview of the new Cell compiler.  To get started with Cell, place this example script in any Sphere game directory as Cellscript.js:

Code: (javascript) [Select]

function $sphere()
{
	install(files("animations/*", true), "animations");
	install(files("maps/*", true), "maps");
	install(files("fonts/*", true), "fonts");
	install(files("images/*", true), "images");
	install(files("scripts/*", true), "scripts");
	install(files("sounds/*", true), "sounds");
	install(files("spritesets/*", true), "spritesets");
	install(files("windowstyles/*", true), "windowstyles");
	
	install(sgm({
		name: "Awesome Sphere Game",
		author: "Some Weird Guy",
		description: "Follow the hero as he tries to get devoured by the nearest pig.",
		resolution: "320x240",
		script: "main.js"
	}));
}


Then from the command line, switch to that game's directory and (assuming you added minisphere to the PATH during setup):
Code: [Select]

cell -p game.spk
msphere game.spk

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #846 –
It's a good thing I really enjoy doing this or the overall deadness of the Sphere forums would be incredibly depressing after all the work I did on minisphere... :P

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #847 –
Hopefully someday we can start marketing a nice solution to game hobbyists. I think Sphere has fallen in visibility lately and we can try to re-ignite what was there under Minisphere and my editor. Perhaps get a more advanced crowd to who'll appreciate debug tools and command line build scripts. ;)
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

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #848 –
That's actually my overarching goal with the recent additions (from around 1.5 on)--to make Sphere look like a serious tool for game development, beyond the "toy" that is Sphere 1.5.  To accomplish that, I realized it needs to be more than just the engine; it doesn't matter how many awesome features I add to it, there needs to be some sort of toolchain to go with it.

If you think about it, being more than just a toy is what got Sphere on the map originally--it had JavaScript, a full programming language, while everyone else was using RPG Maker 2000 with its point and click "scripting".

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #849 –
Quote from: Radnen – on

Hopefully someday

We're pretty much already there.

Also, I remember talk about an overhauled map engine at some point? Definitely check out http://www.mapeditor.org/ - it's a fantastic cross-platform map editor I've been using since very recently which is just EXCELLENT and I think integration of its map format into minisphere would be *very* beneficial for Sphere and the community to have. And re-ignite some of its flames.

Heck, look at what already supports it. Add minisphere to that list and bam, visibility goes up. :)
 

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #850 –
That map editor looks awesome.  I'll see about integrating it, even if I don't support it in the engine directly I could have Cell be able to compile it to an RMP if nothing else.

Speaking of which, thanks to a recent massive overhaul of Sphere Studio's plugin system, the minisphere 2.0 GDK will have much tighter integration with the editor.  So you won't have to drop to the command line to get the full power of Cell! ;D

As for the overhauled map engine, I was considering doing one for minisphere 2.0 in JS.  I keep putting it off to do other stuff though, like the Sphere Studio overhaul, because I know it will be a huge undertaking.  Implementing the classic map engine was easily the most time-consuming part of minisphere's early development, and that was working off of the original Sphere 1.x source!

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #851 –
Quote from: Lord English – on

As for the overhauled map engine, I was considering doing one for minisphere 2.0 in JS.  I keep putting it off to do other stuff though, like the Sphere Studio overhaul, because I know it will be a huge undertaking.  Implementing the classic map engine was easily the most time-consuming part of minisphere's early development, and that was working off of the original Sphere 1.x source!


Always remember the most immediate advantage of making a piece of the engine in JS is how easily portable it will be to the web versions (and likely inevitable node.js version). Once a working proof of concept is made (can probably reuse casiotone's, Radnen's, and/or my existing JS animation code for animating tiles), THEN we can worry about optimization and stuff. If you look at the source for mine you'll see I had almost finished map stuff, but I was stuck on figuring out an efficient animated rendering method and didn't go further.

Note: in my tile animation demo section the 'A' that marks animated tiles is HTML, not canvas, so don't worry about a parsing error there if you want to save the canvas to a file.

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #852 –
I found it was much, much faster and easier to write a map engine clone in JS. And I also found that, just knowing what characteristics it should have and implementing those, I came very close to creating an equivalent object-oriented API without really meaning to.

That was what prompted me to try and rewrite more of the API in JS. I found it was actually pretty easy for a lot of the API, and didn't incur much of a performance hit at all. Fortunately, SpiderMonkey is able to properly manage its own memory, so I could finally tie GPU resources to JS objects.

That was also what made me think about putting almost the entire API in script. Just expose a single ArrayBuffer that is the screen, and ArrayBuffer-like object you can post audio to, something equivalent in functionality to the RawFile object for filesystem and network access, and an object that represents input. Everything else can be done in script.

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #853 –
That ArrayBuffer-like audio object is answered by Audialis, which as of 2.0 will support 8, 16, 24, and 32 bit audio, the last one being float.  Likewise RawFile is being deprecated in favor of the new FileStream object.

24 bit audio might be a bit awkward with ArrayBuffers though as there is no Int24Array.  Thankfully there IS a Float32Array. :)

Re: minisphere 2.0b1 (stable 1.7.11)

Reply #854 –
16-bit audio is pretty standard, though. You can assume that this is supported by just about every platform. Floating-point audio is a bit more exotic.