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

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.
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.

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.

Re: minisphere

Reply #123 –
Look what works in minisphere! ;D  Well, at least up till ExecuteGame is called...

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

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...

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

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.

Re: minisphere v1.0-b1

Reply #130 –
Quote from: Lord English – on

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

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... :)

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?
 

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.

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!