Am I only who doesn't like graphical smileys at all? If I remember, I always click "Disable smilies" when sending a post...

ASCII is best \>:D/

Great to hear this!

What about the translation of the plugins? Do they support it? How are they going to be translated?

Oh look, a bird...

<img src="http://drasa.nipponfever.net/muu/hontto.jpg">

My bird wins yours, because looks stupider.

This is a thread about birds now.

Yeah, I've never actually used GIMP but I do hear that the interface is kinda wonky.

Fortunately, it will be improved in the next version, 2.6, which is coming really soon.

I think that what we need is wrappable layers. They would help with this and many other things, like infinite parallax backgrounds and such.

Well, that's why HSL color model with tolerances would be useful. You could recolor the colors in the tolerances, and you could just recolor the hue, saturation or luminance. You could control the each channel separately, and you could perform effects like tinting, but also a lot more.

Ah, brings memories... The style resembles a bit the one in Worms 2. Nice <3.

Umm... Does it currently take a lot of resources? Optimisation is futile if there is any need to optimise. And I think layer scrolling takes less resources from CPU, IF it's relying on some DirectDraw things. Does it, Ashley / Dave / Rich? Using ball/bullet/whatever movement takes more resources from CPU, 'cause it needs to calculate every object's position... But currently, if it isn't slow already, I wouldn't try to fix it.

David posted an example of family picking a few days ago in Help

But good job on coming up with it on your own. And your example is pretty sweet, too

Oh thanks, seems that I missed that topic before.

Edit:

Ooh, I can make it crash... if I mix them all up in a big pile then start clicking and dragging things out, eventually it will pop up with an error that says "A while condition has reached one million iterations blah blah blah" so apparently it's stuck in an infinite loop. Never seen that one before.

Yeah, the crash is because somehow the cells form a group where the first cell's Target value isn't zero but the UID of the last cell, kind of a ring. Then it tries to resolve the first cell in the chain, but ends up just looping infinitely...

I have been playing with object picking for some time now. A long time ago I made a suggestion that the picking system needs to be improved; there is not much control over the picking, when instances of same object have to interract with each other. I suggested that in event editor, when choosing an object user could define additionally an "group" which would "represent" the specific instance or instances. (Ah. This is hard to explain ) So, that there would be conditions like:

Sprite1.A.Value('Strenght') > Sprite1.B.Value('Strength')
+Sprite1.A Collides with Sprite1.B

Welp, I found a post where the creator of the original game explained how he made the asteroids...

[quote:3nuys7g6]Each asteroid affects each other, which is an O(n^2). This should be really slow for 1000 asteroids. Should be 1,000,000 gravity calculations. So... I use a coarse grid and calculate the mass contained in each grid segment. Gravity is calculated accurately for near by asteroids and the grid is used for distant asteroids.

I don't know what that means

I am not sure myself, but I'll try to explain anyway ... First it initializes an array, a grid which has wide segments, like 1000 pixels or something like that. Then it calculates the amount of the mass in each segment... it kind of "rounds" the "gravitational map", or "scales down the resolution", if you get it that way. Then it starts to loop through each asteroid and calculating the forces affecting them. If there were... let's say about 10 asteroids on each segment, it calculates the forces of asteroids on its own segment and the neighbour segments, the forces of, say, 90 asteroids. Then it calculates the more distant ones, but it doesn't calculate asteroids, it calculates the combined gravitational forces of segments. If there is 1000 asteroids, like in your quote, and there is 10 asteroids per segment, then there would be totally 100 segments, so, there would be a 10 x 10 segment grid. So, the forces affecting a single asteroid would be forces of 89 asteroids and 100 - 9 (9 is the amount of neighbour segments whose forces are calculated accurately) = 91 segments, so there would be only 180 forces to calculate per asteroid, instead of 999. So, it's over five times faster.

And I think it can be optimised further. For example, the forces of the distant segments are the same for every asteroid in a segment, so these forces need to be calculated only once per ten asteroids, assuming we have that ten asteroids in a segment... so, averagely 89 + 9.1 = 98.1 force calculations per an asteroid. That's already TEN times faster !

Of course, updating the mass grid takes some calculating, but it's not necessary to do every tick, since the positions of the asteroids don't change that fast.

I think this wouldn't be too hard to implement with Construct... But of course, cannot say surely yet. I would try to make this myself unless I had so little time :I

> +Left arrow is down
+OR
+A key is down
+OR
+Left joystick is down
AND
+Walk=1
+Player is on ground
[/code:300f4thf]

You can do this easily with subevents:

+Left arrow is down
+OR
+A key is down
+OR
+Left joystick is down

	+Walk=1
	+Player is on ground

[/code:300f4thf]