Javascript Sprite Animation

jersmi's picture

Posted is a working little animation using sprites, iterator and javascript. I want the animation to add the sprites (random size and color) without overlapping, and scroll as the screen fills.

  1. Regarding, for ex., sprites filling screen but not overlapping, in javascript (or otherwise, i guess), how can a relationship be set up between queue indices, so current index uses values from previous index (or indices) to determine x position, y position, width and height?

  2. Would it be better (faster) to have the random values sampled in js?

  3. How can I generate the scrolling, say after the screen fills? Best way? Sometimes I see the "dummy" patch time patch input in js -- what is this for? Am I off the mark for thinking of this re: scrolling in js?

Any help is appreciated.

PreviewAttachmentSize
Sprites_rdm_000.qtz17.82 KB

cybero's picture
Re: Javascript Sprite Animation

I just noticed that if I arbitrarily increase the value of the size to say 120, from your preset default of 32, then the JS gives an error.

However if I hook up an incremental + 1 routine, thus 32,33,34, etc then, eventually, it will hit 120 without a hiccup. If I hook up an Interpolator with range 1 - 120 then until it has actually accrued a value it can begin to deal with, the script errors in the GF Log. Thereafter it can then use the value up from the one that first took a hold [1, BTW :-)]

Given that's all at the first stage of what you eventually scroll, I think that needs to be sorted firstly.

Then you'll be able to benefit from using something, perhaps based upon the Developer example Ticker.qtz or RSS Ticker. Ticker.qtz uses a timeline based approach, whilst RSS Ticker uses a purely mathematical , boolean switched approach. [Oops - not Developer examples after all - my mistake]

Both work on the x-position , scrolling right or left depending upon what direction you want to go in; you'll need to scroll on the y position for up and down, just switch the x output into the y position and fix the x position as you see fit.

Have fun.

Oh and do tell if you can't find those examples, I'll happily post Ticker up here for you.

RSS Ticker is a part of CamTwist a freeware application you might already have heard of from Lee. Just download that and study the bit that does the scrolling.

Just put your current iterator into an RII and then output that to a Billboard upon which you affect the Y or X position depending upon how you want to to scroll.

(Pardon my earlier enthusiasm that led me to unintentionally misrepresent the source of the examples being quoted upon).

Find attached a very simple scroller example - based upon RSS Ticker.

Hope that helps :-)

PreviewAttachmentSize
scroller.qtz7.4 KB

jersmi's picture
Re: Javascript Sprite Animation

Reassuring to see that, cybero. Can't quite see yet how the scrolling will work in this case, but shouldn't be too difficult. I need to dig in a little later and try a few things. The desired effect will be sprites continuously filling the empty screen and scrolling away as the screen gets filled. I know George Toledo has some comp(s) posted that come close, scrolling GL lines output from a js queue.

So I guess the hard part right now is the first question: how do I go about using js to generate sprites that fill the screen, one at a time, with random (within a range) width/height, with current sprite index having one side touching -- but not overlapping -- the previous sprite.

Also, I don't quite get what to do yet with the error you mentioned...

jersmi's picture
Re: Javascript Sprite Animation

Here's the comp with a working scroller (and a simple graphic). Easy, really. And I noted how I think it'll work for placing sprites on the screen in a more specific fashion. Once again, advice welcome.

PreviewAttachmentSize
Sprites_rdm_001.qtz357.48 KB

cybero's picture
Re: Javascript Sprite Animation

Depth Sort Environment and Depth Sort Sprite ?

jersmi's picture
Re: Javascript Sprite Animation

Well, that's two oblique clues you've given me, cybero. First was to use a counter to march through iterations -- I'm thinking this will work. Haven't a clue how Depth Sort Environment and Depth Sort Sprite applies in this scenario. I'll have a look.

jersmi's picture
Re: Javascript Sprite Animation

Depth Sort Environment and Depth Sort Sprite simply say "This patch is..." in QC. Isn't depth sorting for Z space? Please advise if I'm missing something. I'm only dealing with x/y pos right now, so the Depth Sort Sprite doesn't offer any solutions for me? At this point I think it's a procedural math puzzle, like making an l-system or something. That brings up -- haven't seen any up and running l-systems in QC.

gtoledo3's picture
Re: Javascript Sprite Animation

You could hook the queue count and (add insert splitter to queue) and a structure count (post queue), and hook booth to a conditional. Set it so that when both are equal, it is "true", then hook that output to the integrator.

That will make it so nothing moves until your queue fills.

I'm not sure how Depth Sort/Depth Sort Sprite applies either - that useful when you have images on the sprites, are in over mode, and you need them to render in correct z order. I'm not sure if that would help here for any reason.

You can do some math, and by knowing the current width and height of a given sprite, you can figure out where the four corners of any given sprite are (and z placement too, if needed).

If you offset something by half of width, the sprite will line up so that one side is x=0. You could use that premise so that every other sprite lines up with the right side at 0=x (offset half width, multiply by -1), and that every other renders with left side at 0=x (offset by half width). That will handle your "side by side".

I think that if you determine your corners, you can setup something in the iterator so that if any overlap, a conditional can make a given sprite not render, if you just want to have a bunch of sprites "firing off" and not overlapping.

Sorry for just describing premises, but it would be a little time consuming to whip up what you're talking about.

cybero's picture
Re: Javascript Sprite Animation

See attached redraft of your example, jersmi :-) using a depth sort environment patch with a depth sort sprite replacing the stock sprite patch. Pretty much all else in the comp is as you left it in your last post. Hopefully that's more concrete for you.

Added a redraft version with z0 position and a boolean switch between a mesh and a depth sort sprite.

PreviewAttachmentSize
Sprites_rdm_001_depth_sort.qtz322.9 KB
Sprites_rdm_002_depth_sort.qtz322.95 KB
cube1.dae_.zip1.33 KB

cybero's picture
Re: Javascript Sprite Animation

Yes , in part depth sorting is for z positioning; it also provides fine rendering and low levels of image artefaction .

It's easy to add a z0 to your JS as needed, see the 2nd redraft posted above.

Regards L-systems- have you had a look at l-systems on the ellington blog from ian grant [pre Kineme 3D and Meshes] & tetragram, gtlines & pop art on the Kineme site ?

All L-System related stuff.

:-)

The Depth Sort patches info is sparse •~

gtoledo3's picture
Re: Javascript Sprite Animation

The example composition for depth sort shows the appropriate way and reasons behind using it. In looking at it though, I'm not 100% sure it's working correctly anymore... it seems to be ignoring translation for me in some scenarios (but I'm running some other stuff that might be messing it up).

If someone wanted to do something with the little curly q type line systems, that offshoot from a main one, you can program your spiral curve, put it in a macro, and make one render every so many points in your structure (or setup some other rule).

cybero's picture
Re: Javascript Sprite Animation

I am finding that if rotated in trackball, a depth sort sprite will stop rendering until one has fully rotated. Maybe that is related to the translation problem you report, I don't know. I find that translation on a 3d transformation patch works OK.

jersmi's picture
Re: Javascript Sprite Animation

Quote:
I just noticed that if I arbitrarily increase the value of the size to say 120, from your preset default of 32, then the JS gives an error. However if I hook up an incremental + 1 routine, thus 32,33,34, etc then, eventually, it will hit 120 without a hiccup. If I hook up an Interpolator with range 1 - 120 then until it has actually accrued a value it can begin to deal with, the script errors in the GF Log. Thereafter it can then use the value up from the one that first took a hold [1, BTW :-)] Given that's all at the first stage of what you eventually scroll, I think that needs to be sorted firstly.
I don't know how to sort this out...

jersmi's picture
Re: Javascript Sprite Animation

Thanks, Cybero. I don't see the redraft version you mention, but I get the point. I'm starting in 2D anyway.

Re: the examples of l-systems, yes, I have looked at those. Tetragram uses a sketch up plugin to generate the l-system. I never did give the l-system experiments from the other site much time -- couldn't see much of anything developed there to grab onto. Re: gt's lines, I have spent quite a bit of time with those. Learned a lot. Love 'em.

GT -- thanks so much for even considering posting some kind of finished thought -- of course I don't expect that in a case like this. Sometimes I get a little stuck getting something off the ground, so I post for help. And in a case like this with the errors, the procedural math, etc., I usually learn a lot to help the cause. But I don't expect anyone to do the work for me. :) Sorry if it comes across that way...

I am on the same track with the math (for ex., for x position something like, Xpos[n] = Xpos[n-1] +/- (width/2[n] + width/2[n-1])). Not sure about n=1, n+2, etc., i.e., still can't quite see how to have sprites fit together tightly like a jigsaw puzzle. Maybe if I limit the number of sprites to <10 and work the whole set into a puzzle first. I don't know yet...

Anyway, I'll get to this in the next day or two. I'm building engines for interactive live performance -- a library of graphic choices right now. This is one of a good handful of little parts. I post this info keeping in mind the possibility that it might trigger some relevant response within the community.

jersmi's picture
Re: Javascript Sprite Animation

Thanks again for the useful info.

One more thing re: the js error -- here's the console error: "TypeError: Result of expression 'queue[index]' [undefined] is not an object." QC bug mode says it's the js patch @iterator.

Here's the js:

function (__number x0, __number y0, __number width, __number height, __number hue, __number saturation, __number luminosity, __number alpha) main (__structure queue, __index index, __index total)
{
    var result = new Object();
    if(queue != null) {
        result.x0 = queue[index][0];
        result.y0 = queue[index][1];
        result.width = queue[index][2];
        result.height = queue[index][3];
        result.hue = queue[index][4];
        result.saturation = queue[index][5];
        result.luminosity = queue[index][6];
        result.alpha = queue[index][7];
    }
    return result;
}

jersmi's picture
Re: Javascript Sprite Animation

Oh, and you were reading my mind about the integrator issue with the queue filling. This has been bugging me with some other comps, too. thanks!

It's the random element in the height / width that makes it hard to conceptualize right now... i.e, if sides of two sprites touch, but slightly shifted up or down (random y factor), what about the next sprite in relation to the previous two? (I'm just rewording what I posted a few minutes ago, but it's helpful to do so...)

cybero's picture
Re: Javascript Sprite Animation

Integrator set to a value of 1, hook up to Size and Iteration input on the first level of the composition :-).

"Code free" solution [work around].

Come to think of it, your composition's patch dedicated approach is definitely worthwhile tailoring for other stock and 3rd party patch renderers.

Thanks for sharing.

Post Script

I might need to double check on that, just had QC crash, double checking by running your script in isolation, as it could have been unrelated to your composition, but it crashed when the size had reached 1088.

I'm off to the shops for some fresh bread - new Artisan Bakery opened nearby , shall be leaving the composition running in the background and see if it copes. Possible additional workaround might be to restrict the value fed through to the Size / Iteration inputs from the Integrator.

gtoledo3's picture
Re: Javascript Sprite Animation

The integrator should just be used to translate stuff (I'm thinking). If the integrator input is true, and it's hooked to something like an iterator count, of course it's going to crash QC or grind your computer to a halt at some point. Maybe a spontaneous logout (yay, fun).

cybero's picture
Re: Javascript Sprite Animation

Did not find that QC had hung on my return.

Did find that on restarting what seemed to be a really useful workaround solves almost nothing [in fact]. Must be the result of caching during an editing session that it seemed so effective, even with rolled over value.

If the Integrator -> Range is output through Clipped Value and Range min is set reasonably high , then it does make for a stable workaround.

gtoledo3's picture
Re: Javascript Sprite Animation

Oh yeah, for sure. Man, there are a so many ways to tackle the same thing in QC! I think I would ponder some way to get whatever is increasing the iteration count to actually shut off when it reaches a certain number (maybe a conditional or something?).

You know what's so weird, is that I swear that all of this "caching" stuff is something that it seems like I've never run into. I'm not sure if it's because I've subconsciously lopped out stuff that seems to cause QC weirdness from my setups or what. I do know that if you're running in QC and get an exception, you should pretty much just close whatever file you're working on and restart QC, because the QC app events are no longer in a "sane state", to varying degrees (yeah, I ignore this sometimes). (This has been explained to me in much more detail, but that's the gist of it.)

cybero's picture
Re: Javascript Sprite Animation

Heard and understood, and the caching related problems I get , well, for instance that Integrator to Range [Clipped Value] doesn't give a totally clean result when range min is set higher than 0. Did in a previous editing session. So it goes.

[ Thus scratch that 'solution' :-( ]

Integrator [Value - 1] Reset flagged or unflagged to --> Range [min 0, max - whatever] to --> Iterator index input , using either the Rolled or Clipped Value output does work, however.

cybero's picture
Re: Javascript Sprite Animation

Quote:

I do know that if you're running in QC and get an exception, you should pretty much just close whatever file you're working on and restart QC, because the QC app events are no longer in a "sane state", to varying degrees (yeah, I ignore this sometimes)

probably a good general guideline to follow.

However, I also think that for me, today, I've needed to completely restart OS X entirely.

Some of the results that I got say when dividing Current Index by Iterations, for example, which should be pretty small in size, resulted in totally incongruous results even after restarting QC.

Only after a total restart do I now get true to the math results. Pity, in a way, as some of the incongruous results were graphically interesting.

Actually I am able to reproduce some of the results, find attached what I'm calling Odd_Iteration_Behaviour, but who knows maybe I'm not seeing how the iterations actually amplify the size of the GL Point Structure that the values are being fed to, which is probably what is happening :-)

Just tried to reduce the sizing and cannot do so, still get the same sizing behaviour regardless. Also get the same sizing result with GL Point patch.

PreviewAttachmentSize
Odd_Iteration_Behaviour.qtz13 KB

jersmi's picture
Re: Javascript Sprite Animation

Not sure what odd behavior to look for over here, but I did take your mod, cybero, and add a couple things, like gt's suggestion to load the queue before takeoff. (basically messing around and not doing the real work of creating the specific animations i need...)

PreviewAttachmentSize
scrolling_gfx_000.qtz16.53 KB

cybero's picture
Re: Javascript Sprite Animation

The ''odd behaviour' is basically to do with the sizing achieved by the GL Point Structure points. If you switched off the GL Point Structures & replaced with something else, say a Sprite, with a nicely resized circle image [32 * 32 px size] fed into it and then affect the width and height of the Sprite, you'll see that the circle shown does alter in size, which the GL Point Structure does.

Unless I'm missing something here with how Iterators work, I thought they would affect the number of objects and their positions, size values being generally respected by the Iterator patch and remaining unaffected.

jersmi's picture
Re: Javascript Sprite Animation

ah, okay. good to know.

cybero's picture
Re: Javascript Sprite Animation

Thing is, with what I'm thinking is a slight GL Tools iteration incongruity [do correct me on this point Kineme crew if that ain't so :-)], is that it effectively means that if it is something that could do with being corrected then any composition that currently depends upon or exploits that peculiarity will eventually need to be re-jigged as and when the updated version of the plugin is installed.