Sphere SFML v0.90

Topic: Sphere SFML v0.90 (Read 1565290 times) previous topic - next topic

0 Members and 3 Guests are viewing this topic.

Re: Sphere SFML v0.80

Reply #255 – March 18, 2014, 11:50:15 pm

Okay, well that was some obstacle course. First it wouldn't build because "unsafe code not allowed unless you compile with /unsafe". That was easy enough to fix in the project settings. Then I got this error during build:

Quote

Error 1 The command "
if not exist "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\" md "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\"
xcopy /s /y "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\packages\ClearScript.V8.5.3.10.0\tools\native\x86\*.*" "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\"
if not exist "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\" md "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\"
xcopy /s /y "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\packages\ClearScript.V8.5.3.10.0\tools\native\amd64\*.*" "C:\Users\Bruce\Documents\GitHub\sphere-sfml\Engine\Engine\bin\Release\"" exited with code 4.

However, that was a post-build step, so the engine executable actually was generated and I was able to run it despite VS's protests. Unfortunately, trying to run Spectacles with it threw this at me: "Fatal Error: Parameter not of type string or function: System.Int32"

Oh, and Visual Studio gave me an error about Packages.mdproj when loading the solution.

Re: Sphere SFML v0.80

Reply #256 – March 19, 2014, 12:23:10 am

It's loading ClearScript for some weird reason. Despite the fact it's not loaded. I have a branch using ClearScript instead of Jurassic to test V8, it was loaded as a NuGet package. Packages.mdproj is a MonoDevelop/Xamarin thing, so VS won't recognize it. I'll delete my local git branch and re-clone to test what a fresh build looks like.

I'll try running specs through the engine and see what I can find.

Re: Sphere SFML v0.80

Reply #257 – March 19, 2014, 01:21:32 am

Ok, I see it's SetDelayScript. I got the API call wrong, lol. It's frames first then the string. Also you use SetDelayScript(0, string) which is weird since it technically should not run... unless 0 in this case means immediate. In my SSFML it doesn't run unless you call it starting with 1. I'll definitely have to change this behavior.

I ran into a problem with Specs and Jurassic, it's a serious low-level issue. I got around it by fixing this area of Scenario:

Code: (javascript) [Select]


// from this: (line 147)
if (command.start != null) {
	var parameters = [];
	parameters.push(scene);
	for (i = 0; i < command.arguments.length; ++i) {
		parameters.push(command.arguments[i]);
	}
	command.start.apply(commandContext, parameters);
}

// to this:
if (command.start != null) {
	var parameters = [];
	parameters.push(scene);
	parameters.concat(command.arguments);
	command.start.apply(commandContext, parameters);
}

For some reason it was mistreating arguments. I'll have to isolate the issue and give a bug report to Jurassic. Anyways, concat is a better solution.

But then I get another issue:
Battle: definition 'undefined' doesn't exist!

BTW: my engine should compile normally now.

Re: Sphere SFML v0.80

Reply #258 – March 19, 2014, 01:53:19 am

That code was written early in Scenario's development, before I knew much of the JS standard library. I'll definitely see about using concat for such cases in the future.

The undefined battledef is odd though, the latest commit works fine in Sphere 1.5.

Re: Sphere SFML v0.80

Reply #259 – March 19, 2014, 01:58:08 am

Quote from: Lord English – on March 19, 2014, 01:53:19 am

The undefined battledef is odd though, the latest commit works fine in Sphere 1.5.

Hmm... I see. That happens when I move to concat to "fix" the problem. That's odd because concat should do functionally the same thing! Why is this happening!? What the heck is command.arguments??? It's definitely not of an array type.

Line 33 of scenario is of arguments type - not an array. Fix it like so:

Code: (javascript) [Select]

arguments: [].slice.call(arguments, 0),

Hmm, but that still doesn't fix it in SSFML.

Re: Sphere SFML v0.80

Reply #260 – March 19, 2014, 02:08:06 am

You're right, it's not a proper array. I just checked, and command.arguments is the exact arguments object passed to the function that enqueues the command. Look at Scenario.defineCommand() to see it. Am I doing something evil?

Regarding delays: Yes, the 0 means "as soon as possible", i.e. on next map update (I feel using 0 here is more of a guarantee of that than 1). The only reason I defer at all is because the cutscene changes maps a couple times. I found out the hard way that you can't change maps during a map load when using persist/analogue.

Edit: Ninja'd. Not surprising given I'm using my iPhone to post!

Re: Sphere SFML v0.80

Reply #261 – March 19, 2014, 03:03:48 am

Ok, I updated my Jurassic JS engine to latest version. It seemed to fix the array wonkiness with your scenario. Furthermore, I'm going to update Link to 0.2.10, which fixes a JS issue with array.splice - it should be array.slice. I don't know why Sphere 1.5 has this working for you, but this is a serious bug in Link, and *might* be why you crash sometimes.

So, I'll update SSFML again, update Link to 0.2.10 and then you should be good to go to run specs in SSFML. I was able to get it partially working. So hooray for me to load all that code and have it do something!

I'm now running into an issue both code and not code related. Let's just say the game works, but isn't displaying right. I don't know why... Add SSFML's Print(text) method to your JS-console's writeLine method to get real-time feedback, even if it seems stuck in a loop.

Edit: and both are done.

Re: Sphere SFML v0.80

Reply #262 – March 19, 2014, 08:12:14 am

Just some feedback: Specs certainly gets much further than it did before, but is still unplayable on SSFML. It won't accept input (I use the keyboard mappings defined by config.exe, are those implemented?), and the rendering is very wonky. Screenshot attached.

Also, using concat like you do above is incorrect, and is what caused the undefined battle error. concat returns a copy of the original array, it doesn't change it in-place. Which is likely the reason I overlooked it when I wrote that code.

Re: Sphere SFML v0.80

Reply #263 – March 19, 2014, 03:09:51 pm

I don't have config.exe-like key-mappings implemented yet, so that will definitely take me some time. About concat, yeah I forgot it copied the array silly me.

I really don't know what to say about the rendering. There's just so much code to sift through it could be anything, anywhere doing something. In isolation SSFML can run your kh2bar and should be able to draw all the other things I see, so it's just weird where it get's hung up. By adding SSFML's Print() function to your Console.writeLine() method, it seems to stop on calling headlessHorse.start(). Specifically where the textbox displays. I'll need to do more digging to see exactly what the culprit is.

Re: Sphere SFML v0.80

Reply #264 – March 19, 2014, 05:47:42 pm

Maybe it is time so set up a Unit Testing framework for Sphere runtimes, and a big set of Unit Tests for those runtimes. Now we have Vanilla, SFML, TS and mine.

Re: Sphere SFML v0.80

Reply #265 – March 19, 2014, 06:23:52 pm

Looking at what ultimately gets rendered, it looks like it might be a Z-ordering error. This is reinforced by the fact that, if you turn on the console, you can see it show up for a split second at startup before being covered by the battle.

Z order is handled in Specs by having the threader sort the thread list by priority. Threads.js might be a good place to start looking.

Edit: And I was right. Screwing with the thread-sort function changes the order stuff is rendered in. I believe I figured out the issue: Spidermonkey's Array.sort() must be stable, so threads with the same priority are rendered in order of creation (most recent last). Jurassic's sort is not stable, and the expected Z-order gets shuffled as a result. As it turns out, this was stupidity on my part: The JS standard doesn't specify whether Array.sort() is stable or not, so relying on stable behavior was foolish. I should be able to fix it by using the threadID as a bias, similar to what I do in the turn predictor.

As for it hanging in headlessHorse.start(), that's because you didn't implement config.exe key mappings, so the textbox is waiting for the confirm key (A in config.exe) to be pressed, which never happens.

Edit 2: Biasing the thread sort doesn't seem to help. I'm wondering if it's actually the reverse and SpiderMonkey sort is actually UNstable while Jurassic's is stable. The unstable sort just happened to put the equal-priority renders in the right order, but the stable sort reveals the error...

Re: Sphere SFML v0.80

Reply #266 – March 20, 2014, 02:36:51 pm

Okay, this is interesting: NOT sorting the thread list at all results in the exact same rendering order as with the sort, despite the thread priorities being different. Is Jurassic's Array.sort() bugged?

EDIT: Yep, Array.sort is bugged. Without the sort, everything gets rendered, but in the wrong order. With it, some of the renderers get wiped out (set to null) and thus never get called.

EDIT2: Alright, I'm stumped. Try this: Comment out the sort() calls in Threads.js and add a line that gives feedback after the for loop in Threads.renderAll(). For example, a Print() call. You would think it would just keep printing the line over and over, once per frame, right? It doesn't though--after a while it stops printing it, as if .renderAll() is returning before reaching that line. There are no premature returns in that function, though... That suggests infinite recursion (which would be a bug on my end), but unless Jurassic is allocating an ungodly amount of stack space, it should crap out within seconds, which it doesn't.

So yeah, this is really weird.

Re: Sphere SFML v0.80

Reply #267 – March 20, 2014, 03:28:13 pm

Equal-priority is always undefined; you need a tie-breaker. I can't honestly say if Jurassic is at fault here since the specification doesn't really say what the ideal sort is, it's up to the implementer. I'll try some isolated tests and get back to it's creator. You might be on to something here.

I'll look at the other things later today.

Re: Sphere SFML v0.80

Reply #268 – March 20, 2014, 03:32:12 pm

Even with the tie-breaker (the thread ID), I still had the issue of renderers getting null'd. So yeah, definitely a bug somewhere. And that other issue in my second edit is just bizarre...

Re: Sphere SFML v0.80

Reply #269 – March 21, 2014, 01:07:33 am

All of my isolated tests pass. I too use a priority-based hooklist in Blockman and it uses Array.sort and it doesn't seem to fail. Time to use your Threads.js in a small demo project and see if it works or not. I also wonder if the rendering is due to my sprite-batched graphics backend... Could you be fooling it? That said, the array.sort method should never nullify anything.

Ok a small test, you'll need at least a test-map:

Code: (javascript) [Select]


RequireScript("Threads.js");

function Test() {
	Threads.initialize();
	Threads.createEntityThread(new Textbox("Hi, how are you?"));
	MapEngine("testmap.rmp", 60);
}

function Textbox(text) {
	this.wind = GetSystemWindowStyle();
	this.font = GetSystemFont();
	this.text = text;
}

Textbox.prototype.render = function() {
	this.wind.drawWindow(16, 16, GetScreenWidth(), 64);
	this.text.drawTextBox(16, 16, GetScreenWidth(), 64, 0, this.text);
}

Textbox.prototype.update = function() {
	if (IsAnyKeyPressed()) return false;
	else return true;
}

I don't think it's Array.sort() that's doing it, I mean it's really messed up. I get a green wash over everything, which is otherwise not possible with this code. And it doesn't draw the text.

Edit:
However if I change the update method to this, it seems to draw everything correctly but the text:

Code: (javascript) [Select]


Textbox.prototype.update = function() {
	if (IsKeyPressed(KEY_ENTER)) return false;
	else return true;
}