UGH. Where was the Bomberman tech demo I was telling y'all about?

What you want to do is actually possible--what you have to do is have a counter variable that cycles through 4 different values, and each time the renderscript runs you attach input to a different player based on the value of the counter, and then set it to the next value.

That's exactly what I did, and it wouldn't work. I managed to get all four players being controlled at once (that was an odd one), and just the first or just the fourth player controlled, but not each controlled independently.

Though even if it's possible, I'm still canning the Gauntlet clone. I've got a simple project perfect for Sphere that'll be original, so maybe, if I make it good enough, I can launch a Kickstarter to develop a 3DS / Wii U version, which would be awesome.

UGH. Where was the Bomberman tech demo I was telling y'all about?

Do you remember who made it?

Damn, it's not in the repo.

I don't know the author off the top of my head, sorry. It was available around the time of the old flik_zelda, kooparoids, and puffpuff demos, though, so anyone here who may still have it check around those dates?

I should probably tell you this: renderscript is intended for rendering code in the map engine. You might want to try and see if doing it in an updatescript (with SetUpdateScript) works; this runs at a different moment.

Sphere just isn't meant for multiplayer.

How do you think this could be changed? I think being able to properly control multiple characters with multiple controls would be interesting.

NEO: No prob. I don't have any of the old games. Hopefully someone does, and can re-post them to the Drive.

Vince: The best way I can think of would be for there to be API commands for multiple AttachInputs. Instead of AttachInput(entity), it could be AttachInput(player,entity). Like, AttachInput(1,"Steve"); AttachInput(2,"Blaine"), etc.

Of course, that'd require recoding at the C++ level.

And yeah, I never really knew the difference between SetRender and SetUpdate. I might mess around with it some more, getting a multitap-esque thing working for Sphere would be really cool, but I'm gonna focus on other things for now.

Moock, I agree on the AttachInput. I think I'll add that to my SFML version.

And yeah, I never really knew the difference between SetRender and SetUpdate. I might mess around with it some more, getting a multitap-esque thing working for Sphere would be really cool, but I'm gonna focus on other things for now.

Several differences, two that I at least know of:
SetUpdateScript() runs before rendering anything at all.
SetRenderScript() runs after at least having rendered the map, and before the map engine does its FlipScreen() (which explains why you don't need FlipScreen() for a renderscript).

These facts might not make a difference for the functionality of what you were trying to achieve, though. Now that I think about it I think it's mostly done like this to separate rendering from logic.

Moock, I agree on the AttachInput. I think I'll add that to my SFML version.

*dances like a fool*

Wait, I thought the SFML thing was, you drag and drop your Sphere project into it, and it spits out a version that works on the web. If you're adding unique features, then will Sphere-SFML have its own editor?

And yeah, I never really knew the difference between SetRender and SetUpdate. I might mess around with it some more, getting a multitap-esque thing working for Sphere would be really cool, but I'm gonna focus on other things for now.

Several differences, two that I at least know of:
SetUpdateScript() runs before rendering anything at all.
SetRenderScript() runs after at least having rendered the map, and before the map engine does its FlipScreen() (which explains why you don't need FlipScreen() for a renderscript).

These facts might not make a difference for the functionality of what you were trying to achieve, though. Now that I think about it I think it's mostly done like this to separate rendering from logic.

Ah, that does make sense.

Will SetUpdateScript work even if you're not using Map Engine?

Wait, I thought the SFML thing was, you drag and drop your Sphere project into it, and it spits out a version that works on the web. If you're adding unique features, then will Sphere-SFML have its own editor?

Sphere-SFML is stand-alone, runs on .NET. It's just that with SFML you have an option to export/compile to HTML5 in some way or another.

Will SetUpdateScript work even if you're not using Map Engine?

Nope, updatescripts are also meant for the map engine. But you don't need them outside of the map engine, since you can just call any old function from any of your own loops. Consider this:

Code: (javascript) [Select]

function MyOwnGameLoop() {
  SetFrameRate(60);  //Forces short breaks with every FlipScreen() so the frame rate is forced to 60 and not "however much your system can handle". (Note: known for somewhat buggy behaviour in some Sphere versions)
  while (true) {
    UpdateStuff();
    HandleInput();
    SomeOtherThing();
    RenderStuff();
    FlipScreen();
  }
}

Versus this in the map engine:

Code: (javascript) [Select]

SetUpdateScript("UpdateStuff();");
SetRenderScript("RenderStuff();");

Wait, I thought the SFML thing was, you drag and drop your Sphere project into it, and it spits out a version that works on the web. If you're adding unique features, then will Sphere-SFML have its own editor?

Sphere-SFML is stand-alone, runs on .NET. It's just that with SFML you have an option to export/compile to HTML5 in some way or another.

Well, it's only used through the browser if I ran it through JSIL. Then again I'm running into data limitations which is making that route a sort-of no-go for now. So in the end, Sphere SFML is just a fast, modern reimplementation of Sphere for Windows computers. (Linux and Mac is possible, since Mono has came a long ways).

Will SetUpdateScript work even if you're not using Map Engine?

Update scripts run when the map engine updates the map. With no map engine running, the update does not run.

Edit: Oops, nevermind the first part of this message, if you already saw it. Saw my error and fixed it.

Wait, I thought the SFML thing was, you drag and drop your Sphere project into it, and it spits out a version that works on the web. If you're adding unique features, then will Sphere-SFML have its own editor?

Sphere-SFML is stand-alone, runs on .NET. It's just that with SFML you have an option to export/compile to HTML5 in some way or another.

Well, it's only used through the browser if I ran it through JSIL. Then again I'm running into data limitations which is making that route a sort-of no-go for now. So in the end, Sphere SFML is just a fast, modern reimplementation of Sphere for Windows computers. (Linux and Mac is possible, since Mono has came a long ways).

Aww, no web output? That was gonna be such an awesome feature, 'cause then players wouldn't have to download anything, they could just go to a website and play.

Oh well, if the API has multiplayer input, I'll be happy.

Hmm...maybe I should post a Dream API, just for the heck of it. With all the general-purpose features I can think of.

If you are wondering about recursion errors check your code out:

Code: (javascript) [Select]

function WriteSomething(){
    font.drawText(0,0,"All this program does is display this message.");
    WriteSomething(); // issue here.
}

Notice you are calling the same function within itself? It is recursive in that fashion, so naturally, it'll go on forever and run out of stack memory. Stack memory is the memory used for function calls. There is a limited space of stack memory, but that doesn't mean you can have a limited number of functions. When you removed this it worked. Now you know what recursion is . (It's not a bug or a bad thing. In fact if you can use it right it's awesome, but it is also tricky).

If I remember correctly, Sphere used to have a hard limitation of recursing a function 1000 times before erroring out with "Too many recursions". This was a safety feature made to prevent getting stuck in a resource-intensive type of loop. Not sure how it is in current Sphere; did this limit go up as we started giving JS more memory to work with?

Yes, Sphere was given more JS memory, but it still has the same hardset limit of 1000:

Code: (javascript) [Select]

function game()
{
	test(0);
	Abort("ok");
}

function test(num) {
	if (num == 998) return; // 998 = ok, 999 = not ok
	test(num+1);
}