Yikes, sorry if I started this. I suppose 'easier' might not have been the right term. Mostly, it's the performance difference between using a software based library and using a built in function. Particularly anything that used to require screen objects, or creating new icons. Screen objects have always caused lots of display slowdown on my, admittedly old, computer. So far, animate and translate have been MUCH quicker and I haven't had to spend nearly as much time trying to figure out ways to speed things up. It just works. I guess that was the 'easier' I was thinking of.
I do use lots of libraries, though I more often then not spend as much time reading through them and learning how they work as I would making my own (Probably not as well though). I realize I can just plug many of them in and they'll work, but I do this stuff for fun, and for me, figuring out how Lummox's DmiFonts or Forum_Accounts Sidescroller works is enjoyable. Often, I need to make adjustments to the libraries as they aren't quite set up how I need them. For example, Sidescroller wouldn't play nicely with my lighting system, so I had to play with it a bit. But please don't think I'm downgrading libraries. Absolutely not.
And to Ter13: Not yet. I downloaded it after I had already created something a bit like it for myself. I like yours better, and will be using it for future projects though. Thanks :)
Flick wrote:
I do use lots of libraries, though I more often then not spend as much time reading through them and learning how they work as I would making my own (Probably not as well though). I realize I can just plug many of them in and they'll work, but I do this stuff for fun, and for me, figuring out how Lummox's DmiFonts or Forum_Accounts Sidescroller works is enjoyable. This. I do this often. I only just really sat down and figured out how DMI Fonts works. But I really just tear through the more renowned libraries to see how it works, to tinker or whatever. It's a learning experience. At some point, I may tear through an old version of Darke's lighting library, but that's a tad beyond me at the moment. | |
How would you make this look more fluid / smooth (more updates per second). I can easily see that as the ball moves in an arc it skips a ton of pixels between updates.
| |
Ter13 wrote:
You might give that library a shot, and try a fracture effect. Break the block up into a series of pieces, then shoot the particles off in a random direction, with random rotation velocity and scale/fade at the same time. Extra points if you apply gravity to each of the particles. Would be a neat effect to try for a block-breaker kind of game. I've played around with animate() a little for particles (first time I've tried anything with particles). I can handle the random directions, velocity, scale and fade ok. I've had some trouble with rotating more than 179 degrees (180 causes it to scale down), and also moving particles along a curved trajectory using animate(). | |
Another little effect.
 | |
That looks awesome! Another neat effect might be sequentially having the blocks above collapse, and do a jello-like effect when they hit the block below them by scaling axes but preserving total area.
| |
Very impressive.
| |
I like it. Fantastic job!
I guess I should get around to messing with the new features. I'm behind on the times, brah. | |
I myself am having some degree of difficulty understanding the new features right now (matrix() baffles me), but I think once more content on the subject arises (Tutorials, Demos, Libs, How-To Topics) I'll get a better understanding of what can be done and how to do it efficiently.
For now I'm pretty content with trying out some effects on my little block game (which I probably should rewrite), and Ter13's been giving some nifty suggestions. EDIT: Just realised someone gifted me a membership, not sure who it was, but it's very much appreciated. ^_^ | |
matrix is easily understood as such:
matrix(a,b,c,d,e,f) matrix(x_scale_x,x_scale_y,x_offset,y_scale_x,y_scale_y,y_of fset) When blitting, each, pixel will be transposed through the matrix like this, for the provided icon_x,icon_y x = icon_x*x_scale_x + icon_y*x_scale_y + x_offset y = icon_x*y_scale_x + icon_y*y_scale_y + y_offset Or: x = x*a+y*b+c; y = x*d+y*e+f Make sense? | |
Just about, but I don't quite get the difference between x_scale_x and y_scale_x.
| |
I don't think I like thinking of matrices like that, as if "a, b, d, and e correspond to scaling". The transformation matrices are all found on Wikipedia, and they're used by multiplying the matrices together to get the matrix that atom.transform eventually gets set to. I don't think it's good to make direct connections like that, especially if you're mixing scaling and rotation.
The important thing though is that you rarely need to use the matrix() proc with 6 numbers. You can just use the Turn() or Scale() or Translate() procs. This is all in the DM Reference. Sure, there's math behind it, but you really don't need to know any of it to make use of this feature. | |
I don't suppose more of these demos will be open source, will they?
| |
Most of these really aren't that hard to replicate once you get a good grasp of matrices. And as Kaio already said, using them is rather simple when you use the matrix procs. I believe that the only function that requires making use of the matrix() proc variables is skewing.
| |
Good thing no one is using the raw-er form of the procedures...
#define MATRIX_COPY 0 | |
Nothing at all, move along.
| |
Looks sort of like the "namespace" identifier in C++
| |
I see that you posted the video in question a year earlier, but in Ter's defense, I am speaking of the thread at ID:1320998 (in which Yut Put posted the video, and Ter commented with the notion of "crunchy" games).