//////////////
// PARTICLE //
//////////////
particle
parent_type = /obj
// -- var -- //
var
position_x = 0.00
position_y = 0.00
life = 45
life_max = 45
velo_x = 0.00
velo_y = 0.00
New(X,Y,VX,VY)
..()
loc = locate(1,1,1)
icon = _picon
SetPosition(X,Y)
SetVelocity(VX,VY)
proc
Update()
velo_x = velo_x * 0.95
velo_y = velo_y + 0.125
MovePosition(velo_x, velo_y)
life--
if (life <= 0)
del src
else
color = rgb( 127 + (128 * (life/life_max)), (255 * (life/life_max)), 0)
var/matrix/m = matrix()
m.Turn(life*4)
m.Scale((life/life_max)+0.25,(life/life_max)+0.25)
transform = m
SetPosition(X,Y)
if (X != null) position_x = X
if (Y != null) position_y = Y
UpdatePixelCoords()
MovePosition(X,Y)
if (X != null) position_x += X
if (Y != null) position_y += Y
UpdatePixelCoords()
UpdatePixelCoords()
pixel_x = round(position_x)
pixel_y = round(position_y)
SetVelocity(X,Y)
if (X != null) velo_x = X
if (Y != null) velo_y = Y
AddVelocity(X,Y)
if (X != null) velo_x += X
if (Y != null) velo_y += Y
/////////
// VAR //
/////////
var
list/
_list_particles = new/list()
icon/
_picon
proc
_Init()
_picon = icon('icons20.dmi',"white")
_Update()
for (var/d = 1 to 10)
var/u = rand(0,320)
var/e = rand(-10,10)
var/f = rand(0,2)
_list_particles += new/particle(u,-10,e,f)
for (var/particle/d in _list_particles)
d.Update()
world
fps = 30
icon_size = 20
New()
..()
_Init()
spawn()
while(TRUE)
_Update()
sleep(world.tick_lag)
Sure.
|
In response to Tom
|
|
Tom wrote:
But I think these examples would be a lot more useful with accompanying source code snippets. This is how a pro rips. #conspiracytheory Kidding, but really, a lot of impressive work. I'm as jelly as Tom is peanut butter. Lummox can be the bread that makes us whole. Edit: Makeii, that's fantastic. Good work! |
The particles emanating from my magic missile thing are animated using: (comments added for this)
// o is each particle. Each particle does this after being unpooled and positioned, each tick, on each pixel the mouse moved over. You can see how I track the mouse here. From there, it's pretty basic linear interpolation to get the particles drawn in between where the mouse is detected (otherwise there would be noticeable gaps when I move the mouse quickly). The best part about using one completely white icon with a few shapes with atom.color is that, when I turn off graphics hardware mode, absolutely everything turns white. It's pretty funny. |
In response to Super Saiyan X
|
|
He brought et to life!
|
I'm about to share the code behind it, but similarly to Flick's position, my programming for this little project is terrible...lol I hammered it together brute force, so it's pretty unsophisticated (and again, I just started messing with this stuff to make this, so I've probably done something "wrong").
world These objects (well, mobs, mostly, but they shouldn't be...lol) are just placed on the map. The globe in the center (the large blue outline is just a large-icon turf), and the three electrons are placed in their respective starting positions. I wanted to have them leave fading white trails (to more closely match the actual logo), but I haven't been able to work that out yet (the problem is that their movement is entirely visual; they never leave their original positions, so I can't create a trail of objects in their wake) |
In response to SuperSaiyanGokuX
|
|
You're chaining your animate()s wrong, I think. There's a special syntax for it; leave out the first (object) argument. And you can even make it loop forever without an actual infinite loop.
|
In response to Kaiochao
|
|
Kaiochao wrote:
You're chaining your animate()s wrong, I think. There's a special syntax for it; leave out the first (object) argument. And you can even make it loop forever without an actual infinite loop. Oh yeah. I remember reading that subsequent calls would default to the previously animate()ed object... I'm certain that there's some way to combine some of those animate calls into fewer calls altogether, but I couldn't figure it out. And my "timing" is pretty sloppy. Those sleep() values and the time arguments in the animate calls are all just entirely trial-and-error. And d'oh! I forgot about the loop argument! Oh well, I'm new! |
You should add little trails for the electrons.
Also, for some reason the scaling doesn't look like it follows a circular path :P |
It's because the electrons need to shrink slightly while they're "behind" the center.
I've never been able to get stacked animate() calls to loop. If I did animate(src,color = #fff,time = 10) animate(color = #000,time = 10) It would skip the first animation and just play the second. Things get even worse if I call the animate()'s with a loop setting. |
In response to D4RK3 54B3R
|
|
D4RK3 54B3R wrote:
You should add little trails for the electrons. I really want to, but I couldn't come up with a way to do it (well, without re-designing the electron movement altogether; they don't physically move at all in this setup, it's all visual. So I can't have them leave behind objects in their path, because they have no path (only the pixel offset endpoints) I could switch it so that they actually move, and then have them create trails along the way, but I didn't want to essentially "start over" for the effect. Also, for some reason the scaling doesn't look like it follows a circular path :P Yeah, their path is not very circular. The "back" of the circle is flat (for some reason, I couldn't get it to shrink and then grow; the inverse of the front, basically, but I couldn't get it to work), and the "front" is more of an angular change, like they're coming to a point in the center, and I'm pretty certain this is an easing problem (I need an easing that starts out fast and ends slow for the "growing" animation, then one that does the opposite for the "shrinking" animation. I tried a few that I thought would work (applying EASE_OUT or _IN in some cases) but nothing seemed to look right or even as good as just the plain linear easing these are using now. MisterPerson wrote: It's because the electrons need to shrink slightly while they're "behind" the center. They actually do shrink for the "back" portion of the arc. They should be at their actual size at the "ends" of their orbits, then shrinking->growing as they swing around the back (the opposite of what they're doing in the front), but but the timing is off, so it happens too fast (or something, I'm not quite sure yet). That smaller size is actually half of their actual size, but they're jumping into it too soon. |
Throw some easing onto those animations, add trails, and add a fade in of the "BYOND" logo text.
Instant opening cutscene for games. |
Another update!
I broke down and changed the electron movement to actual movement so I could add trails. Also, I'm giving each of them a random speed and random starting order (the older version had a random starting order, but I like that they're not all synchronized): Still tinkering with the timing and easings on the perspective scaling, so that's not perfect just yet, but I think this is definitely a step in the right direction! |
I think part of sharing your code is to get critical feedback that can help you improve.
|
I can definitely understand code shyness! Incursion's code is a hot mess, and has been modified many times since its original inception.
These being just proofs of concept, though, it's definitely worth getting out some snippets for people to see. I'll share a simple one here, for people who are having trouble with getting things to spin: animate(obj, transform = turn(matrix(), 120), time=10, loop=-1) Spinning can't be done as simply as turning 180°, as Danny noted, because that's interpreted as a flip. If your time increments aren't thirds-friendly (e.g., this is 30 ticks broken into three parts), then try 135 instead of 120; that way your time values can be multiplied without losing anything to floating point rounding error. The jump to 135 is 3/8, to -135 is another 1/4 (it's only a 90° change), and the final jump back to 0 is another 3/8 of the total time. In floating point, division by powers of 2 is always accurate. Speaking of flips, I bet this would be cool: // Spin a coin 5 times, then on a 6th spin make it disappear around the halfway mark If you want the deletion to be exact, you'll have to break that into more steps: var/matrix/M = matrix() Just to offer a little clarification on animate() when it comes to transforms, it's always going to try to find the best interpolation it can from the old matrix to the new one. Interpolation deconstructs both matrices to get translation, rotation angle, and scale+shear, and if the rotation angle is a multiple of 180° then it will ignore it so that simple flips are possible. |
But I think these examples would be a lot more useful with accompanying source code snippets.