Skip to main content

News

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

0 Members and 2 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: Sphere SFML v0.80
Reply #270
I guess it's possible I could be interacting badly with your rendering code, but all I know is, when I had the renderAll() method print out all the renderers, without the sort all the functions were intact, but after being sorted several of them were listed as null.  And like I said, if you remove the sort() call, everything gets rendered (this is best seen by commenting out the rectangles in BattleScreen.render and comparing the output with and without the thread sort).

The issue with it not reaching the end of renderAll() is very strange, too.  I did some tests, and that doesn't happen in vanilla Sphere, only in SSFML.

I don't know, all these glitches are very, very bizarre.

EDIT: Just saw your edit.  I'm on my phone so I can't test, but how does that test code even work?  You need to put updateAll and renderAll in the update/render scripts but it doesn't look like you did.  You shouldn't get ANYTHING being rendered in that case...

EDIT2: Ignore that edit, I'm an idiot.  Threads.initialize() sets the update and render scripts for you.  My bad :)
  • Last Edit: March 21, 2014, 01:53:39 am by Lord English
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.80
Reply #271
Wait.. do I know your own threaeding library better than you!? :P

So, I did find a bug in my code, two of them! One: IsAnyKeyPressed was exposed wrong. Two: It is true your code is competing with my rendering backend. Only on maps, however! It seems that the sprite-batcher is running out of order with the map itself. My Solution: run the map itself through the spritebatcher, so it's rendered behind any renderscript calls.

About the randomness in Threads.js, what is this void null thing? Can Jurassic understand that syntax? It could drop stuff here, it's the only other place things get set to null.
Code: (javascript) [Select]
	renderer = renderer !== void null ? renderer : null;
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: Sphere SFML v0.80
Reply #272
Little known fact: void is an operator in JS.  It sets whatever comes after it to undefined.  I did this as a precaution, to get around the fact that undefined can be assigned to (at least in earlier versions of JS, like SpiderMonkey, I believe the current standard forbids it however), which would screw up direct comparisons against undefined.  Most people use void 0, I prefer void null.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/void

And no, I just forgot that Threads.initialize() sets the render and updatescripts because at one point in development, it had to be done separately.  And I tend to forget implementation details after a while if I don't touch the code for a while; eventually, only the public API will stick in my mind.
  • Last Edit: March 21, 2014, 09:46:56 am by Lord English
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: Sphere SFML v0.80
Reply #273
So did you ever figure out what was wrong?  I went back to Sphere 1.5 for now; nothing I do can coax the threader to work properly in SSFML.  So far I haven't seen any crashes, though, so maybe it was the slice/splice thing in Link causing it after all...
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.80
Reply #274
I haven't yet touched the engine. I'll do this now.

Good news! I may have it working! It's now saying GradientCircle is not found, which means not only am I drawing things correctly it's finally found the direct calls for rendering your GUI. Now I just gotta implement these extra draw calls and fingers crossed it should be good. I decided that the map engine is too big/complex for the sprite batcher, so it'll draw everything map-related first, then flush the sprite batcher just in time for the RenderScript() to run I think this is a good solution.

Edit:
Eureka! I did it! It's not perfect but pretty damn close. It all works, the text moves, elements pop in, etc. I don't think you were dropping renders, I think sort() is just fine in Jurassic. :)

The reason you were finding strange render issues had to with the fact render scripts were calling render scripts and this created recursion - precisely when a loop ran a scenario context in which you called RenderMap. But it didn't run the stack out since it operated in a loop that just drew stuff over and over to the screen. The update script would have been the real issue here and I put a block on it, to prevent it from recurring update and render map calls.
  • Last Edit: March 23, 2014, 09:10:50 pm by Radnen
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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: Sphere SFML v0.80
Reply #275
Damn, I just noticed your edit now, several weeks later, go figure.  I really wish the forum notified for edits...

But awesome that you got it working.  The render recursion makes sense, although why that only seems to happen in SSFML and not Vanilla Sphere I don't know.  I did recently start having issues with the threader in Vanilla Sphere however (specifically, my textbox's renderer sometimes randomly got called several minutes after the textbox was dead and gone, causing undefined variable errors), which led me to discover that the glitches was indeed on my end: As new threads are usually created during another thread's update, this causes the thread list to be re-sorted in the middle of traversing said list, leading to all sorts of weirdness.  The most benign manifestation of this was my battle engine sometimes calling its shutdown code twice (which has been a long-standing bug for a long time, and I never would have noticed except for my trusty console); however, as Sphere-SFML has shown, the consequences can be much, much worse.  I haven't yet figured out how to solve it yet.  My first thought was to defer thread registration until after the thread list has been fully traversed, but since individual threads can block (essentially causing Threads.updateAll to recurse), and my engine is built on that functionality, that won't work.  Can I maybe use Link for this?
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.80
Reply #276
Yeah, I should say SSFML only works up until it asks for player key input (unless you use a workaround for now).


Can I maybe use Link for this?


Yeah, but it doesn't make algorithm design a silver bullet. :P You'll have to come up with a way to do thread locking with semaphores or what-not, or a thread-level dependency resolution system. Or I guess you can have two arrays, one for the in-traversal array and the other for what to replace it with when finished. You just swap between the arrays like so when changes get made:

Code: (javascript) [Select]

var cur_stuff = [obj1, obj2];

// new_stuff is not ever looped through, preventing the 'creation in same loop' issue
// also new_stuff must contain same references to old_stuff, you'll see soon enough
var new_stuff = [obj1, obj2, obj3]; // here obj2 from cur_stuff added obj_3 (but to new_stuff)

// switch out to the array with the new stuff
if (changes_made) {  // ie: new_stuff.length > cur_stuff.length
    cur_stuff = new_stuff;
}

// then you can do deletions like normal, or whatever else you may want to do
// it is important that before this step new_stuff at least contains the cur_stuff
if (deletions_made) {
    cur_stuff.splice(deletion, 1);
}

// then reset new_stuff to do the process over again in case there are changes
// if there were no changes made, well the worst is nothing (cur = new) and it's like nothing happened.
new_stuff = shallow_copy(cur_stuff); // we need a new identity, but same object references

// feel free to optimize this, but I think the shallow_copy above is the real trick here. You want to work on the same data, you just want to run an array with elements you are sure are made to be executed during that cycle. I'm sure there are better ways of doing this, but I hope this code here makes for a seamless transition between thread lists behind-the-scenes.


Also, my engine is very slow when it runs your game -__-... you're testboxes render at 121FPS on my rig, but on Sphere they are like 600ish(?). Why must you draw to surfaces like that!? The way I particularly coded Sphere SFML, surfaces are very slow when modified in loops (but fast when modified outside of loops so they are only drawn when 'finished') it has to do with a lot of cpu->gpu bottlenecking that I can avoid if I were to go to straight-up hardware surfaces (which well, I'll need a more open GL library to do that first... maybe).
  • Last Edit: April 04, 2014, 05:29:06 am by Radnen
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: Sphere SFML v0.80
Reply #277

You'll have to come up with a way to do thread locking with semaphores or what-not, or a thread-level dependency resolution system.

Out of curiosity...why semaphores?


Also, my engine is very slow when it runs your game -__-... you're testboxes render at 121FPS on my rig, but on Sphere they are like 600ish(?). Why must you draw to surfaces like that!?


Some versions of Sphere 1.6 are even faster with surfaces than Vanilla Sphere.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: Sphere SFML v0.80
Reply #278

Yeah, I should say SSFML only works up until it asks for player key input (unless you use a workaround for now).


Can I maybe use Link for this?


Yeah, but it doesn't make algorithm design a silver bullet. :P You'll have to come up with a way to do thread locking with semaphores or what-not, or a thread-level dependency resolution system. Or I guess you can have two arrays, one for the in-traversal array and the other for what to replace it with when finished. You just swap between the arrays like so when changes get made:


Obviously not, but the main issue is that threads can block, effectively causing Threads.updateAll to recurse and thus even if I delay thread creation until after a full traversal, that just shifts the problem down the rabbit hole one level, it doesn't actually fix it.  The main issue I was trying to solve with Link was this: Don't sort the thread list, just add to it, and then create a sorted array using Link on demand at render time.  I actually ended up doing this, though I'm not sure how much of a performance hit I'm going to take by doing so.


Code: (javascript) [Select]

var cur_stuff = [obj1, obj2];

// new_stuff is not ever looped through, preventing the 'creation in same loop' issue
// also new_stuff must contain same references to old_stuff, you'll see soon enough
var new_stuff = [obj1, obj2, obj3]; // here obj2 from cur_stuff added obj_3 (but to new_stuff)

// switch out to the array with the new stuff
if (changes_made) {  // ie: new_stuff.length > cur_stuff.length
    cur_stuff = new_stuff;
}

// then you can do deletions like normal, or whatever else you may want to do
// it is important that before this step new_stuff at least contains the cur_stuff
if (deletions_made) {
    cur_stuff.splice(deletion, 1);
}

// then reset new_stuff to do the process over again in case there are changes
// if there were no changes made, well the worst is nothing (cur = new) and it's like nothing happened.
new_stuff = shallow_copy(cur_stuff); // we need a new identity, but same object references

// feel free to optimize this, but I think the shallow_copy above is the real trick here. You want to work on the same data, you just want to run an array with elements you are sure are made to be executed during that cycle. I'm sure there are better ways of doing this, but I hope this code here makes for a seamless transition between thread lists behind-the-scenes.



That's an interesting idea, I might consider it if Link turns out to be too much of a performance hit.


Also, my engine is very slow when it runs your game -__-... you're testboxes render at 121FPS on my rig, but on Sphere they are like 600ish(?). Why must you draw to surfaces like that!? The way I particularly coded Sphere SFML, surfaces are very slow when modified in loops (but fast when modified outside of loops so they are only drawn when 'finished') it has to do with a lot of cpu->gpu bottlenecking that I can avoid if I were to go to straight-up hardware surfaces (which well, I'll need a more open GL library to do that first... maybe).


I did it that way because that was the only way I could figure out to get the effect I wanted.  If you slow down the effect, you can see that it's not really a typewriter effect like in most games, but a sweeping fade. I don't believe there's any way I can do that without surfaces.
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.80
Reply #279


You'll have to come up with a way to do thread locking with semaphores or what-not, or a thread-level dependency resolution system.

Out of curiosity...why semaphores?


I think they would have been easy enough to implement in raw software. I mean I guess spin-locks would be okay too, with busy-waiting. But it's still impossible to have/mimic atomic locks.
[/quote]



Also, my engine is very slow when it runs your game -__-... you're testboxes render at 121FPS on my rig, but on Sphere they are like 600ish(?). Why must you draw to surfaces like that!?


Some versions of Sphere 1.6 are even faster with surfaces than Vanilla Sphere.


I tried it out and the framerate was inconsistent, drew polygons wrong, and dropped certain renders altogether. Have you tried testing FJ-GL on the actual games repo?
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: Sphere SFML v0.80
Reply #280
I tried it on KR, the Particle of Infinite Free Will, Entropy, and Hold the Line (among anything else I've tried out since January), along with all the demos included with 1.6, and it seems to work perfectly. I currently use it exclusively.

Did you try it since I fixed the miscoloration (and added Bezier Curves, it was all in the same release)? The miscoloration, dropped frames, and bad vertices were all the same issue, basically (bad shader for GL 2.0 and greater).

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.80
Reply #281
I tried the release you linked to here. :P I tried the Sphere 1.6 collision demo with the polygon shapes, and they were missing sides (the demo still worked since technically the shapes' pixels aren't used in the collision - just their vertices). I then tried it on my Hold the Line 2 game (which I ought to upload and share soon) and the background turned white on some frames, and in other frames the fps went between 1200's and 48 (unthrottled). I will admit that it's only so much faster, SSFML rendered HotL2's background in the 2000's fps range.

Look, if your FJGL is more stable than Sphere 1.6's current drivers then that's amazing. My only issue with 1.6 so far is the occasional crash due to memory mismanagement or whatever (it might not even be at the driver level).
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

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #282
I fixed a lot of little bugs and completely added TCP networking support. To demonstrate, here is an image. I haven't uploaded the code yet, but soon I'll release another version of this engine. It can play quite a few more games now. Also, it mostly handles Lithonite.js by FBN which is a huge success since Lithonite uses a lot of features intrinsic to the map engine and player bases (I say mostly since I still need to do a thorough test, but all my games that use it for it's basic features and deobstructioning all work).

So, yeah, basically I've taken some time to work on this. :)

Edit:
About the networking. I'm not using SSFML for client and server. I'm running a Node.js TCP server in the background that handles the broadcasting of events. Since it's Node.js I can create game state files the client and server can share since they are all written in JS. I've noticed far better performance doing it this way (I should have done it like this in the past when I dabbled with networking games earlier, like that Pokémon game). Technically, SSFML can be used for server, but much like Sphere it's be a huge waste since I have not yet programmed a "server-only" version of SSFML, so there's lots of waste going on if you do use it as a server. But I am using SSFML here as a TCP client, reading and writing to a socket using the exact same API as Sphere. The demo below looks exactly the same in Sphere 1.5 as it does in SSFML, but in SSFML there is far less lag since on the JS side of things there is a far better speed improvement when reading and writing to sockets over Sphere 1.5. There's simply no lag. :)
  • Last Edit: January 04, 2015, 04:31:46 pm by Radnen
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

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Sphere SFML v0.90
Reply #283
Looking good. Makes sense that Node.js is a good match for Sphere.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: Sphere SFML v0.90
Reply #284
Are these changes on GitHub, or...?
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub