Skip to main content


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - N E O

Programming / MuJS - embeddable-in-C JS engine
Split out from MuPDF, MuJS is AGPL v3 licensed and can be found at and source in the repository.

It claims to be similar to Lua in that it's "as simple as possible to use" and about ~10K lines of C to include. Seeing as how successful recommending Duktape became I thought I'd pass along another "small" embeddable JS engine. It's very clearly not optimized for speed, but it looks similarly as simple as Duktape if the examples are any indication.

Like Duktape, I hate that it's C and not C++, as I'd love to see this objectified simply instead for simplicity. Seeing all those .c files bugs me, and I'm pretty sure there could be some combining happening. I may attempt it as a summer project or something.

edit - corrected GPL to AGPL +neo
Articles / Gamasutra: Fixing Pokemon

At the end, when he presents the table, I immediately thought of Radnen's Link.js and Lord English's Scenario for the powerful array function chaining to achieve such results easily.

So! Who else here thinks Pokemon needs to be fixed and how? I know Sphere has seen its share of Pokemon projects and I for one would love to see a TBS RPG on Sphere implement these "Master Mode" mechanics.
Ladies and gentlemen, JS-ception.

SpiderMonkey compiled via LLVM, then run through Emscripten. Reportedly REALLY slow, but the fact is it exists.
A long time ago, I wrote a library, NTrans, that contained RPGMaker-like screen transitions for Sphere like wipe in/out, iris in/out, etc. The most recent (I think in 2011 or 2012) transition I wanted to add was an animated shattered glass effect for, say, a map-to-battle transition like one of the Tales games. I never had a decent one working.

Fast forward to now, I find this canvas-based script which takes "random" vertices, applies Delaunay triangulation to make triangles, and clips image segments to those triangles. CSS takes care of the animation aspect of it.

What that script can do that mine never could is clip a given image to non-rectangular polygonal boundaries. Sphere does not have a polygonal clip function (in future APIs I'd like to see it called Surface.clipPolygon or something), so how can we make this happen in Sphere? The "fastest" (i.e. the slowest) way I remember is to Surface.cloneSection the triangle's bounds and manually fill outside of that cloned triangle with rgba(0,0,0,0), but that was always unreliably slow.

Do we have better ways to clip a given image or image section to non-rectangular boundaries but still within Sphere 1.5 API? Ideally such a method could also take care of the problem I had with non-rectangular iris in/out transitions, too.
Programming / Duktape - embeddable-in-C/C++ JS engine (MIT licensed)

Looks about as simple, if not simpler, than SpiderMonkey. Anyone here want to benchmark speed vs. SpiderMonkey/Sphere, V8/TurboSphere, and/or Jurassic/SSFML?

I'll be playing around with Duktape a bit and see what I can get out of it, but until we know more I wouldn't knee-jerk immediately recommend we switch out SM, V8, or Jurassic just yet.
Sphere General / Object.defineProperty in Sphere 1.5?
I'm currently unable to access my Windows laptop that has Sphere 1.5 on it; can someone with easier access to their 1.5 setup confirm whether or not the Object.defineProperty method of getters & setters works? I know much of my old Sphere code uses older getters and setters tactics and I'd much rather recommend something more modern and standardized to those who want to raise their JS level.
Game Development / [ebook] Game Programming Patterns (also on GitHub)

The author, Bob Nystrom, apparently worked (works?) for EA and created the Magpie programming language so I'm pretty sure he knows his stuff. It's pretty hardcore, though, and also deals with game programming aspects that theoretically may already be taken care of for Sphere users by the engine itself, so don't go in expecting a read aimed at novice devs.

That's not to say it's not useful for Sphere users or even the few of us here developing/maintaining Sphere-compatible engines. Basically, if you have an interest in learning how a game development professional recommends organizing task-specific sections of code it will be a useful read, especially if you're a fan of the book Design Patterns: Elements of Reusable Object-Oriented Software.
Resources / Magic Tools - "A list of Game Development resources to make magic happen."

It's like the game-dev-only version of the massive list of free programming books and resources, and even links to the officially released source code packages for complete games such as Doom, Quake, Prince of Persia, etc.

Going through the list myself, I'm thinking so far so good. It does NOT, however, list Sphere in the Engines/Frameworks section (or at all, for that matter). Let's figure out how to resolve that, shall we? ;)

A well-informed article by Ben Kuchera on learning how to copy someone else's game design aspects and, more importantly, when to do it and what to actually "steal." A good quotation from early in the article (emphasis mine):

Quote from: Mike Bithell, developer of Thomas Was Alone
Look at the game you are thinking of copying, the one that got all those YouTube views, and look at why it worked, the decisions and choices, the objectives, how the surface of the game achieved the outcome, and then come up with something different that may duplicate some of that success.

I highly recommend reading the entire article because there are some really good anecdotes peppered throughout, so I'm not going to summarize the thing here.
As part of my knowledge-absorption regimen, I subscribe to Quora regular email digests. Every so often a good programming related question appears and I feel a given answer is so good I have to upvote it.

This time the question was "how do I create an MMORPG [ with no skills of programming or design ]." This was Daniel Super's answer.
Programming / VGM web player in JavaScript
After almost two years of work (at least one year of which was a sabbatical from personal projects) and almost 10 years of research, I've finally completed a working VGM player in JavaScript! I've also successfully implemented gzcompressed VGM handling in it using zlib.js, officially bringing the player's capability to VGM v1.50 spec.

SN76489, YM2413, and YM2612 cores are ported from the Genesis Plus GX emulator; YM2151 core is slightly modified from Kuma's MDX player. The player itself is my hand-rolled "NPlay" script (yep, "N" branded ;) ) to attach audio output to the XAudioJS library by Grant Galitz using jQuery. Many thanks to the SpritesMind Forums community for the massive amount of info on the YM2612, Grant Galitz for making XAudioJS so I didn't have to, GitHub user imaya for the zlib.js that powers the VGZ decompression, VGM maintainer ValleyBell for the massive amounts of direct help with the development of the various cores, vgmrips webmaster vampirefrog for various suggestions, support, and other web VGM playback development, and the vgmrips community for advancing the VGM format beyond the SMS, Game Gear, and Genesis.

The sound chip scripts should be platform-agnostic and therefore usable in Sphere, but there may be an errant web-only line or two and there are a lot of console.log calls that would need to be commented out. The point is JavaScript-only playback of the VGM format is entirely possible and my player is currently the proof-of-concept of such. One day either myself or someone else will port the player to Sphere APIs.
I've been following this Quora question on game resource management for a while now and it has some really good explanations from industry veterans on what they did and what could be done. Some of it might still be relevant in this day and age!
Sphere General / Establishing Sphere's notability
Sphere once had a Wikipedia article. This article was deleted in 2012 due to "Expired PROD, concern was: no reliable references, failed to find any; notability not established."

How shall we go about positively establishing (or likely in this case, re-establishing) Sphere's "notability" in the near future? I know the various Sphere modernization projects would go a long way towards confirming that Sphere is indeed still alive and kicking, but other than making more working projects (which admittedly is probably the fastest way, but also requires active people) what do y'all suggest/recommend we start doing/do more of/stop doing so that Sphere can maintain a more permanent spot on Wikipedia?
Site Comments / Uploading forum theme piecemeal
Throughout the weekend I'll be uploading the new forum theme piece by piece as I finish them. Currently it's not ready for prime time but what is uploaded allows me to see a result with live data.

It's not available for users to choose directly, but if you'd like to see it in action (like a Steam Early Access kinda thing) PM me and I'll set your theme to it. It is HTML5+CSS3 and for now requires JavaScript enabled for a few SMF functions I haven't obsoleted, so if you don't use a browser capable of modern web tech (aka a modern browser) don't ask.

Some pieces that have been uploaded do still need cleanup (like the breadcrumb nav), so I won't be accepting comments and suggestions until I open a thread specifically for them. My personal dev methodology for this theme is modern desktop browsers first, then smartphones, then handle stragglers like IE8 users on XP if necessary.
Site Comments / [WIKI] New wiki theme?
The spring semester's over so I'm resuming the forum re-skin. I'm putting it up piecemeal but once it's complete I'll turn my attention towards re-skinning the rest of Spherical.

The question at hand: should the wiki be re-skinned, and if so should the re-skin match the upcoming forum re-skin?

For reference, the forum re-skin will heavily use The Bricks by Designmodo where possible, as I previously bought it with a developer's license (which includes the addon designs as well) so I can use it anywhere I please. My choice of The Bricks is primarily due to wanting a simpler "semi-flat" UI style, as completely flat has essentially no affordance and completely the opposite (e.g. skeuomorphic) is usually too busy and "over-produced" (in my opinion; especially "shiny black" or "extreme" themes).

The "vinnyfonseca" experiment refers to this Wikipedia re-theme experiment which seems to cover the vast majority of what would need to be themed on our wiki. For Wikipedia it takes a few things for granted, but for our structure (especially the various API pages) things like the right sidebar are perfect for "nearby" pages like the API navboxes.

Or we could keep it mostly as it currently is. Vector is a good-looking skin and I'd mostly only need to change certain colors and spacing that I haven't already in order to match Spherical style (I don't have the color list in front of me, but I'll create a style guide page on the wiki once I find it). I would as a result be taking the time to solidify the existing style guide (which will be on the wiki shortly) to account for the re-skinned forums, the Vector-based wiki, and whatever modifications the portal page receives after all.

Theming the wiki is a larger project than theming the forums. I want to get a sense from the Spherical community about the wiki's current look while the forum re-skin is still in development.