Modularity not only helps in collaboration, but everyone. I was always using oop software, where you structure your code in modules, just like the good old term "black box": You develop it once, store it somewhere and access it from any of your projects. No need to re-invent the wheel - and that's the bad thing about C2. You're forced to do all those standards that you use in your projects over and over again.

Sharing those snippets is a great side-effect, but imagine the decrease in development time for yourself in future projects. You actively help decreasing the time with any module you can store to create your own (or shared) library of algorithms, functions, helper code, etc.

Of course this is nothing new to Ashley. He's working with such software to develop C2. And so he might also see the amount of work and time it will cost to implement it. So much time, that C2 wouldn't grow on features during the time, which isn't good for selling arguments.

Yes, modularity is the most important thing right now. The sooner it comes, the faster the community output will grow. And that is also a great argument to sell a software ;)

Don't give up, man! It's your baby. And just like all babys it is not always cute and innocent. Sometimes it just cries for no obvious reason. But you as the daddy have to find out what the crying is for.

And at least you're learning a lot about optimizing - and about all the things you could have done in the beginning ;)

Optimizing in this case means being familiar with how C2 works (best), so that you can avoid redundant events, functions or checks.

Again, don't leave your baby alone crying xD

Very interesting read!

Here are some additional thoughts:

When digital games became an industry, they also slowed down the creative expansion. Mainly because game development even after 40 years still means re-inventing the wheel. Those who did this process once, had a huge advantage - and used it to control the market as much as possible.

If you are unsure what I mean, let's see a very simple example:

We're back in 1981, a few months before the release of the C64. A young boy aged 13 walks to the mall almost every day to admire a computer named Sinclair ZX81. After a while he got up the nerve to actually touch the device and start using it. He developed his first simple programs, especially interested in the random function.

One day he asked the always helpful shop assistant: "So now that I can generate random numbers, how can I make sure, that the numbers are unique? You know, like in a card game, where you just shuffle, what is already there." The shop assistant explained it, and it was quite simple, once you understood the thoughts behind the technique.

Sounds familiar? Shuffling random unique numbers? It is. It's something everyone needs sooner or later when developing a game. Still, in 2013, people have to ask how this is done. They shouldn't be forced to. Re-inventing the wheel.

Game creation software is on the right track taking the technical load of standards away from the developer. Physics simulation, automated control behavior, line of sight, pathfinding, etc. But it's not enough yet. Because the only "indie revolution" that really deserves the name, is given when everyone can make a game, just because he/she wants to.

Just as you can write a blog or create a video. You just do it. No hurdles, no "secret" knowledge necessary. That would be a revolution...

Also, when wanting to support multiple screen sizes, there's always scaling involved. So it's either crystal clear, crisp Pixels or multiple screen size support.

The reason for the old pixel games having that clear picture is that the games back then were especially made for that resolution alone (even pc monitors used to support one screen size only!). On the packages you could always read something like "needs 320x240 resolution"

If you want to recreate that sharp pixel feeling for all you would need to basically design the game for each of the resolutions on the mobile market seperately.

Else you have to live with compromises (e.g. sharp images but less canvas on smaller resolutions, or sharp images on one specified resolution, but scaling to fit on all other, etc.)

And yes, go with a 16:9 ratio. It's a de facto standard nowadays. And in general regarding pixels: It's always better to downscale than upscale. So creating your sprites, they should be at least as large as neeeded to show them crisp and clear on the highest possible resolution you want to support.

Have a look at the manual

If you had done it you would have read the following notice:

Note WebStorage only stores strings. If you set a key to a number like 100, when you retrieve it back it will be a string. To convert it back, use the system expression int, e.g. int(WebStorage.LocalValue("score")).

Yes there is. Put the distance check in a for each loop. See manual->system conditions (scroll down to "Loops")

Great!

Sometimes it's just the small things. I'm glad that I recalled correctly <img src="smileys/smiley2.gif" border="0" align="middle" />

If I recall correct, it is not enough to clamp them into the value range, they need to be integer values. Have you tried to set the (range corrected) values with

"rgb("&int(red)& ... etc.?

Else, in case there's just some typo or small error, I'm sorry, but I can't have a look at your capx, I'm using an older stable version of C2.

Two things:

1) red green and blue need to be integer values in the range [0, 255]. Setting green and blue to loopindex give them values above 255, which is invalid

2) If that alone doesn't help, try drawing to the canvas on the first tick instead of "on start of layout" (compare tickcount to achieve this). The reason for this proposal is that I'm not sure if the canvas is already available for drawing before tick 1.

EDIT: OK, sorry, forget point 2 <img src="smileys/smiley36.gif" border="0" align="middle" />

In filter is the Q inverted or not? Many eq's have got inverted Q, which means the higher the number the narrower the band.

megatronx From my long-term tests I can tell that Q is inverted.

Also, from the web audio api documentation (https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html):

knee

    A decibel value representing the range above the threshold where the curve smoothly transitions to the "ratio" portion. Its default value is 30, with a nominal range of 0 to 40.

in short: 40dB = max useful smoothing, 0dB = punch, values outside = <img src="smileys/smiley18.gif" border="0" align="middle" />

It depends on how fast you need this to be. For example, you could use ROJOhound's Canvas plugin where you can paste the sprite to the canvas plugin, then loop through all pixels, get the color/alpha value with rgbaAt() and in case it's white replace the alpha with

Draw point (x,y) with "rgba(0, 0, 0, 0)"

Of course that wouldn't be very fast.

No, you shouldn't. I would be glad to work on an event sheet structured so detailed.

The delay thing: I wouldn't say they are causing a delay (not in the true meaning of the word). Also, I talked of milliseconds, and even that might be too much. It's just that groups are active elements, they can be set on or off. This needs a check for every group on every tick (Imagine something like "For each group, if group is active then execute") and this adds to the length of a tick. But I really can't tell how much these checks cost. Might as well just be 2 microseconds... <img src="smileys/smiley1.gif" border="0" align="middle" />