Blinkyâ„¢ from Ruairi Robinson on Vimeo.
Soon every home will have a robot helper.
Don’t worry.
It’s perfectly safe.
Written, Directed & Edited by Ruairi Robinson
Starring Max Records from “Where The Wild Things Are”.
Cinematography by Macgregor
Music by Ólafur Arnalds courtesy of Erased Tapes
Funded by Bord Scannán na hÉireann / Irish film Board
Thanks to the power of google and some very explicit search terms, I stumbled upon this ( http://www.onaluf.org/en/entry/13 ) valuable tip.
Inside Ping, my implementation of putPixel uses either a fillRect or arc path because I’d already found making direct writes to the canvas pixel array terrifyingly expensive.
Next up for Ping is to use multiple canvas’s to store static images ( examples background layout ) and see how that works out.
I’ve been writing class/method level documentation and ideally plan to make a step by step explanation of what the heck is going on inside the Ping toolset. Until then it’s pretty doubtful anyone will want to use it. Never mind everything is still in Alpha state and there is very little guarantees that something won’t be written.
I’m getting a tad tired of the asymmetrical relationship between my WordPress install and the endless horde of robots out there. Stage 1 has been to isolate a majority list of IP’s and host servers from whence they came, then I shoved a python script between here and there that transparently catches most of them. Next step up will be to start install bot traps and burn up their bandwidth transfer allotments.
Running live here
User input is fed off the left & right cursor keys.
Ping additions included a formalized Quad tree library into the ping.Lib namespace but I want to fix up the factory function I wrote to take an instance of the Canvas rendering class instead of manually writing out the root dimensions. Otherwise collision checks are still a tad wonky… there’s a high propensity for near misses unfortunately 🙁
So I’ve got a working Quadtree implementation that is relatively performent on Google Chrome 10
Demo here
GitHub repo here
So far bounding box detection isn’t but working on that, also documentation, and unit-tests are non-existent but I’m working on that now.
Once I hash those out, then this should be an useful collision detection/proximity check library for canvas tag games.
If only the damn clients would wait another day, week, month, or even better a year to release; life would be so much easier with more time. Seriously though, I’m losing track of the number of times I wanted to ask a question on Stackoverflow and in the process of articulating my question into something legible to people who are not me… I find the answer to my question. At least I have you people (1200 unique spam bots, spiders, and scripts + 300 unique visitors a month who bounce in under 1 minute) to sanity check the crap I write here… without you I’d probably be doing what I am doing now, spending time writing two new functions, deleting one, and refactoring the other every day.
So… a fair number of people arrive here looking for how to detect when a pixel/object/thing has collided with something else.
I’ll add more information in the future but in the interim, the quick and dirty advice I can provide:
Given p = x, y where this is the point your trying to determine if it intersects another… the best place is to start with bounding box logic. Â Regardless of what shape your object is, if wrap it in an invisible box boundry, it’s relatively trivial to do:
box upper left origin is bX, bY off size sizeX, sizeY.  If p.x greater then bX and p.x less then bX + sizeX AND p.y greater then bY and p.y less then bY + sizeY  you’re inside the bounding box and it’s highly likely your point has or will soon be colliding with an object.
That’s pretty much it and is perfect if you don’t mine lagging the crap out of whatever is running this logic.   To make these collision checks performant, you need to make the computer do less work.  For two dimensional space, my personnel research has led me to the Quad tree structure ( wikipedia article ).  I’ve got a brute force / naive implementation prototyped  @ here & here but as of 2011 March 9th it is not finished and needs some more work.
Basically Quad tree’s provides a super quick way for you to determine if there is any other objects in relative space to an entity. Â Doing a quick lookup, if there’s nothing nearby then you can skip the bounding box checks and then the stupidly expensive perimeter intersection checks.
Full library is here and like most of my pet projects is heavily undocumented and completely absent of unit-testing.
So… the graphing library look damn good, but focusing more on the nutts & bolts.
Previously ExtJS has had an on demand instantiation system vi anoymous objects with a property of xtype. It’s fairly likely that not every component of an ExtJS enhanced page is going to be used by a user or even looked at, so the xtype support allowed for avoiding costly and wasted object/component instantiations.
Now it looks like they’re taking that one step further. Looking at the Public Release 3 of ExtJS 4’s documentation, I noticed some new additions… specifically lazy class loading. If I’m correct in my assumptions, that means that instead of loading the ENTIRE ExtJS library and possibly only using a tiny bit of it, you can load up only what you need saving rendering time & bandwidth!
Ext.require([
'widget.window',
'widget.button',
'layout.fit'
]);
Ext.onReady(function() {
var window = Ext.widget('window', {
width: 500,
height: 300,
layout: 'fit',
items: {
xtype: 'button',
text: 'Hello World',
handler: function() { alert(this.text) }
}
});
window.show();
});
Authoritative source here
Inspired by this
Source code @ Github here
So… this basically covers elliptical paths ( which I want to play with more ), a rendering chain I’m happy with, and a few others things. What isn’t exactly right: speed, planetary/stellar surface animation is missing, and I’d like to have a fly by mechanism that shifts the Y ratio progressively over time.