Skip to main content

News

Topic: neoSphere 5.9.2 (Read 522752 times) previous topic - next topic

0 Members and 21 Guests are viewing this topic.
  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere
Reply #120
Line intersect is faster than pixel-perfect and can be nearly as accurate (if you map a decent contour), while bounding-box can be clunky on organic objects. That said my implementation of line intersect code is definitely not 100 lines, but then again I did abstract things away into helper classes. But even then, a hundred lines for that is a lot.

https://github.com/Radnen/sphere-sfml/blob/master/Engine/Engine/Objects/Line.cs#L33-49

The math there is the core of it, I'm sure you can abstract lines into a struct in C and make a few helper functions. It's literally that, and for loops, checking all the lines, whether the source is a person, a tile, or a custom map obstruction line.
  • Last Edit: February 25, 2015, 04:31:48 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

Re: minisphere
Reply #121
It's not that crazy, or at least it shouldn't have be. My JS implementation is totally contained inside that one file, and you'll note it's only 109 lines :)

Eventually, Chad Austin had wanted to use BSP trees for obstructions. I suspect that was a part of the change to segments.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #122
Yeah, wow, yours and Radnen's are so much shorter and more elegant.  I just checked the code in Sphere again, and this is what it looks like:
https://github.com/sphere-group/sphere/blob/master/sphere/source/common/ObstructionMap.cpp#L63-L189

Even accounting for blank lines and comments, that function still has to be close to 100 lines of code.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #123
Look what works in minisphere! ;D  Well, at least up till ExecuteGame is called...
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #124
In the Steps of the Blackfoot is almost completely functional (barring a couple glitches and lack of person-tile collision) in minisphere! :D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere
Reply #125
Wow, nice work man. :) Is performance decent?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #126

Wow, nice work man. :) Is performance decent?


It performs better than Sphere 1.5 in nearly all cases. ;D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #127
This just in: minisphere fully supports obstruction!

At this point I think minisphere is just about ready for a public beta release.  There are still a bunch of unimplemented APIs, but even as-is many existing Sphere games run with minimal--sometimes no--modification, so no real sense holding back anymore.  So get ready, minisphere is coming! ;D

Or, you know, you could just check it out from GitHub now and build it yourself, but... ;)

update: Aquatis now runs up to the intro cinematic before erroring out due to lack of Surface:applyLookup().  So close...
  • Last Edit: March 07, 2015, 11:23:34 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere
Reply #128
Just released the first public beta of minisphere! ;D  Try it out!  Link is in the OP, but I'll repost it here for convenience.

Current release: minisphere 1.0-b1 (March 9, 2015)
Download on Google Drive - GitHub
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere v1.0-b1
Reply #129
So, a few new features:

GetExtensions() returns a list of strings representing the engine's capabilities.  For example, calling this in minisphere currently returns:
[ "sphere-legacy", "minisphere" ]

I got the idea after skimming the Pegasus stuff on GitHub.

The other new feature is an optional stack offset passed to Abort(), like so:
Code: (javascript) [Select]
Abort("ThisFunctionSucks(): This function sucks, why did you call it?", -1);


It allows you to blame the error on a script further up the call stack, useful in libraries to report invalid parameters or other such errors.  If the stack offset is not provided, it defaults to 0, meaning "location of Abort call" - i.e. the normal behavior.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere v1.0-b1
Reply #130

It allows you to blame the error on a script further up the call stack, useful in libraries to report invalid parameters or other such errors.  If the stack offset is not provided, it defaults to 0, meaning "location of Abort call" - i.e. the normal behavior.


That's really awesome! In RadLib I had to do some SM only hacks to get line numbers and report the penultimate function call in the call stack. This would undoubtedly make that process much easier under your engine. +1
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
  • Sphere Developer
Re: minisphere v1.0-b1
Reply #131
See, the whole thing was kind of a happy accident - by default Duktape reported Abort-generated exceptions as coming from api.c, since that's where the duk_error() call is.  In order to get it to show the script file that aborted instead, I had to call into Duktape to walk a step or two up the stack and then use duk_error_raw, which lets you override the file name and line number of the thrown exception.  Of course, since I now had full access to the callstack, well... :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere v1.0-b1
Reply #132
Just before I switched to SM, TurboSphere reported the entire JS stack on crash. Unfortunately, V8 couldn't give line numbers for higher frames, but it was still nice to see.

Would that be possible/not-horribly-complicated with Duktape?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere v1.0-b1
Reply #133
Trivial.  The stack offset on Abort isn't required to be -1, it can go all the way up the stack if needed and even gives line numbers.  The functionality I use to do it--Duktape.act()--is even exposed to script, so as long as minisphere uses Duktape, the entire callstack will available to scripts at any time.

I have to say, Duktape doesn't look like much, but it's actually a pretty awesome little JS engine.  It definitely took me by surprise.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0b1
Reply #134
Just implemented atlasing for RFN fonts.  The original implementation used individual ALLEGRO_BITMAPs for each glyph, which I suspect was the main reason for minisphere's horrible text-rendering performance up to now.  The drag became especially noticeable in Spectacles when the console was displayed.  Now it seems to be much better!
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub