Skip to main content

News

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

0 Members and 23 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #435
It's not a config tool, but... I just implemented automatic U/V coordinate assignment for Shapes, and it's working great. ;D

@FlyingJester: Want to see a neat trick?  I assign default U/V coords like this:
Code: (c) [Select]
bounds = get_shape_bounds(shape);
width = bounds.x2 - bounds.x1;
height = bounds.y2 - bounds.y1;
for (i = 0; i < shape->num_vertices; ++i) {
delta_x = shape->vertices[i].x - bounds.x1;
delta_y = shape->vertices[i].y - bounds.y1;
shape->vertices[i].u = width > 0 ? delta_x / width : 0.0;
shape->vertices[i].v = height > 0 ? delta_y / height : 1.0;
}


Essentially I calculate the shape's bounding box, and then do a bit of linear interpolation on the vertices to get the U/V values.  This works for any number of vertices with no predefined lookup tables needed. :)

There is a downside, of course: If you accept the defaults, the texture basically becomes a decal.  This is the one upside of TS's method: If your 4-cornered shape is something other than a rectangle (a rhombus, say), the texture map remains rectangular (0,0)-(1,1) and the image is properly distorted.

Edit: So, new method, still works for any number of vertices but allows the texture to distort (note: assumes clockwise winding starting from top left):
Code: (c) [Select]
static void
assign_default_uv(shape_t* shape)
{
double phi;

int i;

for (i = 0; i < shape->num_vertices; ++i) {
phi = 2 * M_PI * i / shape->num_vertices - M_PI_4 * 3; // counterclockwise offset 135 degrees
shape->vertices[i].u = (cos(phi) * M_SQRT2 + 1.0) / 2.0;
shape->vertices[i].v = (sin(phi) * M_SQRT2 + 1.0) / 2.0;
}
}


Essentially what I'm doing is circumscribing the UV space--which conveniently happens to be a unit square!--and then setting UV to points on that circle.

Edit2: Correction, clockwise winding.  Trig functions are canonically CCW, but the inverted Y axis reverses the winding.
  • Last Edit: April 29, 2015, 08:55:13 pm 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 1.1b2 (stable: 1.0.10)
Reply #436
New beta posted. ;D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b2 (stable: 1.0.10)
Reply #437
I'm presently in the process of updating the Specs Threader.  I'm going to include with minisphere 1.1 as a system script. 8)

It's like an OO version of hook-list.js:
Code: (javascript) [Select]
Threads.initialize();
// ...
var tid = Threads.create(obj);
// obj has .update() and optional .render() called once per frame


It's also a bit like pthreads in that you can do this:
Code: (javascript) [Select]
var worker = Threads.create(obj);
// do some stuff, and then later, perhaps during an update:
Threads.join(worker); // block until worker terminates

...and it will only block the current thread (if any).

For what it's worth I think it might be a good idea to implement some sort of NuGet-type system, where external dependencies such as Link and this can be declared in a the game's metadata and be automatically retrieved.  That's a project for another time, though.
  • Last Edit: May 01, 2015, 05:03:10 pm by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.1b2 (stable: 1.0.10)
Reply #438

For what it's worth I think it might be a good idea to implement some sort of NuGet-type system, where external dependencies such as Link and this can be declared in a the game's metadata and be automatically retrieved.  That's a project for another time, though.


http://forums.spheredev.org/index.php/topic,1262.msg5934.html (like bower)
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 1.1b2 (stable: 1.0.10)
Reply #439
Is t that just about a way to load modules that already exist in the engine's search path, whatever that happens to be?  I guess it could be extended to search the Internet or something, but I didn't get the feeling that was what it was about.  That's more about modularizing stuff to avoid name clashes.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.1b2 (stable: 1.0.10)
Reply #440

Is t that just about a way to load modules that already exist in the engine's search path, whatever that happens to be?  I guess it could be extended to search the Internet or something, but I didn't get the feeling that was what it was about.  That's more about modularizing stuff to avoid name clashes.


Well, it's kinda both. Dependency management, name clashes and a tool like bower that you can use to pull dependencies automatically from a server (which is what NuGet is like, or NPM).

But this is more like an editor feature if anything. Unless you want to go the node route and inherently work with modules (meaning we must change the way in which we program and expose the code to all of our games going forward).
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 1.1b2 (stable: 1.0.10)
Reply #441
Right, which is what the Pegasus spec currently advocates.  Everything is a module, even built-in engine functions.  Personally I hate that model myself, though I can see the appeal.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.1b2 (stable: 1.0.10)
Reply #442
One aspect that I find appealing is that, under the plugin model of TurboSphere, you can run dedicated servers for networked games. In the case of TS, you can actually lose the libraries you don't want. The distro becomes smaller. Of course, the flip side is that it is a more complex setup in the first place.

Being able to remove any portion of the engine is important to me. Should someone find the audio plugin unsuitable, for instance, they could write their own or use an alternative, but not lose the other plugins. A Linux model, as opposed to a BSD model, if you will.

But of course, this is an aspect that is rather different in philosophy than Sphere 1.5. It just so happens you can recreate a Sphere-like environment while still working this way.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b2 (stable: 1.0.10)
Reply #443
True, I just don't feel, with minisphere being ~1.75MB for a complete 64-bit Sphere 1.x implementation (okay, so some stuff is missing like the Animation API, sue me :P) that works out of the box, plus all the extras it offers, it's worth adding the overhead of plugins (this is why I preferred the monolithic Allegro build before I switched to static linking--use more than about 2 Allegro components and the monolith DLL is actually smaller than the individual ones).

With TurboSphere the plugin model makes more sense, since it's designed for maximum flexibility.  minisphere I see more as a "download it and have a ball" deal.

By the way you might want to update the note about minisphere in the TS readme--I don't think minisphere can be considered in "early development" anymore. ;)
  • Last Edit: May 02, 2015, 12:32:55 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 1.1b2 (stable: 1.0.10)
Reply #444
I give to you: minithreads!  This is a generic adaptation of the threader I'm using in my game Spectacles: Bruce's Story.  It only works out of the box in minisphere, but would probably work in Sphere 1.5 with some tweaking.

[gist=0d2a95dcbbccf9a5ebb1][/gist]

Usage:
Code: (javascript) [Select]
// note: the below calls SetUpdateScript(); and SetRenderScript() intrinsically:
Threads.initialize();

// if `obj` is an object with .update() and .render() methods:
var threadID = Threads.create(obj);

// or perhaps to encapsulate a threaded thing:
this.threadID = Threads.create(this); // on construction
Threads.kill(this.threadID); // on disposal

// to create a makeshift thread for any object:
var vertices = [ /* ... */ ];
var texture = new Image("myTexture.png");
var shape = new Shape(vertices, texture);
var group = new Group([ shape ], shader);
Threads.createEx(group, {
    update: function() { return true; },
    render: function() { this.draw(); }
});

// to block until a thread finishes:
// (it is safe to call .join() in a thread updater--that thread will block
// but other threads will continue happily humming along!)
Threads.join(threadID);
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b2 (stable: 1.0.10)
Reply #445
And here's a polyfill for another minisphere 1.1 feature: the RNG object.  Of particular note: RNG.fromNormal(). 8)

[gist=779ddef439c8b93f393b][/gist]
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b3 (stable: 1.0.10)
Reply #446
minisphere 1.1b3 is now up and available to download. Tons of new features in this one (and a couple more bug fixes too)!  The RNG object is one I'm particularly proud of.  It's based on MT19937 (AKA Mersenne Twister), has a bunch of different generation methods, and allows manual seeding unlike JS's Math.random().  See the included API documentation for full details on it, it's pretty awesome.

I also took yet another leaf from TurboSphere's book and started on a JS-based "minisphere Runtime", previewed in this beta.  1.1b3 includes minithreads and minidelegate, the functionality of both of which have been invaluable during development of Spectacles and which I imagine will be useful in many, many games.  I'm thinking the final 1.1 release will also include a version of Scenario as part of the runtime as well.  These scripts can be used like this:

Code: (javascript) [Select]
RequireSystemScript('mini/threads.js');
RequireSystemScript('mini/delegate.js');


Also, minisphere is now officially BSD-licensed.  I figured it was about time I added a proper license file to the repo. :P


@DaVince:
1.1b3 fixes the BindKey() bug you reported on GitHub. :D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.1b3 (stable: 1.0.10)
Reply #447
There are three things I want to see fixed sometime before I can even use this engine.

1. Fix the windowstyle bug for windows that have edge widths/heights less than 16 pixels. (See attached).
2. Make GetPixel() much faster so all code I have written that incorporates pixel perfect collision can make my game playable. It's too slow right now.
3. Fix a weird blit bug. (See attached). Things are offset by half the width of an image, but in other engines that's not the case. Like the hp bar, it's offset wrong. What do you get from image.width/2?

Edit: I will say that I'm impressed. You've really made it work on many games. :) Sometimes it's down to a single feature that a game doesn't run, so good you've got most features implemented.
  • Last Edit: May 03, 2015, 04:19:03 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
  • Sphere Developer
Re: minisphere 1.1b3 (stable: 1.0.10)
Reply #448
That rotation bug was a known issue at one point... Then I forgot about it. :P  I think Allegro's treatment of the origin during rotation blits is off or something.  Either that or more likely, I interpreted it wrong.

The dashed windowstyle... Funny story about that.  I didn't really do much testing of Blockman in Sphere 1.5, I was too determined to get it running in minisphere.  As a result, I thought that was what it was SUPPOSED to look like.  If I had to guess, I'm thinking Allegro is padding out small bitmaps to be 16x16 under DirectX, as the windowstyle oddities doesn't happen with an OpenGL build of Allegro.

And the GetPixel() optimization I keep forgetting to get around to.  Thanks for the reminder!

And yes, I was VERY dedicated to making it compatible early in development.  I spent literally half a day trying to figure out a bug that caused Aquatis to crash on the opening credits.  It turned out to be a stupid refcounting error. :P
  • Last Edit: May 03, 2015, 05:19:27 pm 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 1.1b3 (stable: 1.0.10)
Reply #449
I fixed the Image:rotateBlit() issue.  It was user error, as I suspected: Allegro treats the X/Y for a rotated blit as the center of rotation, whereas Sphere apparently aligns it to the top-left.  It should have been fixed a long time ago, but I forgot all about it once I started working on the map engine.

Moving on... I added pixel caching for Surface:getPixel().  It definitely helped, but it's still ungodly slow.  It might help if you stopped creating a surface anew with each collision check.  Allegro stores all bitmaps on the GPU, so each time you call Image:createSurface(), a new texture has to be uploaded.  Not only that, but it's putting a lot (and I mean A LOT) of stress on the garbage collector: I added some logging for images, and... well, let the console output speak for itself:

Code: (text) [Select]
Last 4 lines after entering test map:
[image 4731] Cache miss!
[image 4731] Creating new pixel cache
[image 4731] get_image_pixel() using pixel cache
[image 4731] Dropped pixel cache

Last 4 lines after ONE attack:
[image 5868] get_image_pixel() using pixel cache
[image 5885] get_image_pixel() using pixel cache
[image 5868] get_image_pixel() using pixel cache
[image 5885] get_image_pixel() using pixel cache


So during processing of a single attack, the game created (and possibly destroyed, depending on how aggressive Duktape's GC decided to be) over 1,000 bitmaps.  The thing died right away, so my guess is a few attacks got coalesced due to lag, but still: 1,000+ bitmaps!  That's insane.  That's literally insane.  No amount of pixel caching I can do is going to help that.  I honestly have no idea why--or HOW--it works so well in Sphere.

HOWEVER, full disclosure--I don't think this is the only issue.  What exactly goes on under the hood when you swing the sword?  I'm consistently able to drop the framerate to 30-40 fps on my i3 just by slashing at thin air, but I get no log entries that a pixel cache was created during this.

The last thing I have to fix is that windowstyle glitch.  I'm not sure how to deal with that yet.  I may end up switching to an OpenGL build of Allegro.  The only thing that worries me is that OpenGL tends to be slow on Windows, certainly slower than D3D.  But it would fix the windowstyle issue, so....

Edit: Yep, same issue with the slashes--simply slashing at thin air creates and destroys nearly 100 bitmaps.  Sorry to say, this game is VERY poorly optimized. :(  If it were me, what I would do is call .createSurface() once for each relevant sprite frame and then cache those somewhere.  This way you can just pull them from the cache and do .getPixel() on them with impunity.  As long as the surface contents never change (which they shouldn't), you'll never get a pixel cache miss and Allegro won't have to upload hundreds of textures for every attack.
  • Last Edit: May 04, 2015, 02:12:56 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub