What has everyone else made? Have any cool ideas for how to put this new feature to use?
ID:1376026
 Sep 13 2013, 4:45 pm
|
|
I'm still getting familiar with how this new feature works. So far all I've been able to do is produce a small smoke puff effect. Here's the source code.
What has everyone else made? Have any cool ideas for how to put this new feature to use? | |
I would like to be able to choose which easing algorithm is used for tweening our keyframes. As I understand, it's currently only linear interpolation.
With quadratic easing(both in and out), we can do cool accelerating particle effects, like something falling downwards or launching a rocket or a bouncing ball. cosine easing is pretty nice too :) | |
I would really like to see more of "what you can do with it" posts like this because I really haven't had time to mess with anything yet!
| |
Does animate() work with client.screen?
| |
Nice! I haven't messed with it yet, so this is really neat to see.
| |
D4RK3 54B3R wrote:
Does animate() work with client.screen? Seems to, though the pixel_x,y,z doesn't. | |
So you can't tween the screen_loc?
| |
I'm still waiting for the issue with calling animate() on mobs to actually work without having to have the mob move to update the visuals.
| |
Although it's not related to animate(), here's an old concept I decided to retry.
 In the past, there would be ugly black seams between tiles all over the place, and things would twitch around from pixel rounding. The new atom.transform doesn't round positions and somehow the anti-aliasing gets rid of the seams. It's still pretty CPU-intensive, though. I think I had an average world.cpu of 35 at my obligatory 30 frame per second. Native client.angle (client.transform?) is very niche, as Lummox would say, and I don't see myself making much from it, but if it's ever to the point of "why not", it'd definitely be nice to have. | |
I'm guessing lighting just got a lot faster due to the client-side animation too? Someone should totally touch up one of the old lighting libraries.
| |
I'm sure alpha could be used to make the shading files smaller, but I'm not so sure anything else has improved at all from this. It's not like you can stretch a circle of anti-alpha to cut through a layer of darkness, or anything.
| |
Out of curiosity, what programs are you guys using to record your game and make gifs from it? The setup I use takes a lot of time to convert things over. Just curious if video capture software has gotten ahead of me.
| |
I'm using VirtualDub to capture as avi and then export as .gif
@WANO: I spoke to Yota about how the current lighting systems could be modified and possibly improved by the new features. Pretty much: with alpha, you can make a really really fast equivalent of Shadowdarke's DAL with colored lights. Add that with a small world.icon_size, and you might have a decent looking lighting solution on your hands. But for the current generation of lighting systems that interpolate brightness between tiles (d4y_dfl, fireking's lightspeed, and f_a's dynamiclighting), alpha only helps cut down the rsc size by a little bit. Yota and I discussed the use of color to shade atoms based upon how close they are to lights and such and we decided that it could interfere with other developers' use of color and alpha. It is possible to modify the rgb of color by parsing it, but we decided that it would be too slow to do so. I would love to see if someone can come up with a way to combine the interpolation techniques that the current lighting systems use, with different colored lights. animate() has limited utility for lighting systems. At best you could use it to tween a mob's color, from bright to dark, as the mob moves away from a light or something. But then there's some other problems that arise from using mob.color that I mentioned above. | |
SuperAntx wrote:
http://www.cockos.com/licecap/ This tool...  Just made that lmao. You just took my gif making skills to the next level, I thank you. | |
Is there something wrong with this?
animate(src, pixel_y = 64, time = 10) Instead of having the atom move up 64 pixels from a starting position of 0 it seems to jump about 32 pixels then glide up another 32 pixels. I'm trying to make the pic on the right but what I get is the pic on the left.  | |
With a single white 32x32 square, you can draw a line of any length and thickness pointing any direction.
It's slightly broken though, I think. It's supposed to be lerping the color of the explosion from one color to another, but it's only affecting its alpha.
Aside from the floor and walls, all the objects just use a circle (mobs and explosion) or a square (the gun and beams). One icon, two icon states.