Sep 20 2010, 12:59 pm
|
|
Jamckell
 |
I like the miner game as well, actually. Just don't have lots of time to play it.
|
Thing I like about the miner game is that it's new and original lolz. And it's got a bit of a story, and I keep wanting to get past this one door, but there's no key, so my friend and I are left in the dark about what happens next! I also like the water falling thig, and the scary as shell monkeys.
| |
I read the Enemy AI help. I love it, your detailed with the quotes and I'm actually learning from it! Thanks for creating it and please continue to do so.
If I had some money, I'd donate, but I don't have paypal...or money.. if(money) donate else thank him return I know that's not coding or even good, but either way, I'm learning, thanks a bunch. | |
Why can't your pixel movement demo be a library? Now I can't use it in the 8kb contest, I just realized this...
| |
OrangeWeapons wrote:
Why can't your pixel movement demo be a library? Now I can't use it in the 8kb contest, I just realized this... He posted a minified version of it in his forum for this reason. | |
OrangeWeapons wrote:
Why can't your pixel movement demo be a library? Now I can't use it in the 8kb contest, I just realized this... It's not the easiest thing to turn into a library because there are so many ways you can use pixel movement. That's where the complexity comes from - how you use it. A library wouldn't save you much code in this case but it's still easy to fit into 8k. Also keep in mind that the minified code is for my sidescroller demo. Basic pixel movement (like in this demo) is much simpler and the code is much shorter. | |
Despite the previous comment, I did turn my sidescroller demo into a library. Here's a link to the hub entry.
| |
new page layout looks great, I always liked purple.
| |
The color was carefully selected. It's a blue-gray color that's equal parts red and green and slightly more blue. Being more blue than red (and being equal parts green) it should not appear purple.
But yeah, it looks purple and I love it =) | |
Yo, check your forum please when you get a chance. 0_o
| |
Hey F_A, send me a message when you can, I've worked on your isometric pixel movement demo a bit and after much trial and error, I'm very close to making it possible to move above and below objects in the world.
I'm still working out some quirks but, instead of just detecting turfs, it'll detect objects as well when it uses pixel_move. This way, you can set objects with offset and walk below them, making stuff like bridges/ceilings available. I'm also thinking, if it's a single player game, of making them become transparent when moving under them. I wanted to see what you thought about this and if you liked it, perhaps we could come up with an idea for how to implement this. | |
Bravo1:
I'm not sure how my isometric library handles it, but in the sidescroller library each mob has a can_bump proc. The proc takes an atom as an argument and returns 1 if the mob can bump into it and 0 if it cannot. This way you can have a mob that bumps into dense turfs and objs but doesn't bump into other mobs. Or it does bump into other mobs - however you want it to work. This is a fairly simple model and I've found it to be adequate. | |
OMG Fourm account I love your demos! you make like some of the best demos on the site^--^ you're such an awesome person for doing this! Please keep it up^^.
| |
Why is there so much code in your demos? There has to be easier ways to go about it, it seems very general and intertwined. For instance, I am going through your Isometric library, and I do not understand why you are complicating things with so many lists and returns.
| |
OrangeWeapons wrote:
I am going through your Isometric library, and I do not understand why you are complicating things with so many lists and returns. I'm not sure exactly what you're referring to. I sent you a pager message regarding this too. If you can post on my forum and provide more details (file names, proc names, line numbers, etc.) it'd be easier for me to help. | |
Hi Forum_account, I have a question regarding your 'Handy Stuff' library. Specifically the icon rotation procs. I am not very well-versed in the math involved so I was just wondering if and how it is possible to modify the rotation proc to be able to:
A. Rotate icons larger than 32x32 B. Rotate non-square icons. Thank you for your hard work. | |
That's a good question. I didn't think that anyone was even using that library. I don't have the code handy right now but I'll probably have time to post an update later today.
To explain how it works: each point in the image is rotated around the center of the icon. For larger or non-square icons you just need to compute a different center. The rest of the calculation is the same. It was probably hardcoded to work for 32x32 icons, but removing that restriction isn't hard at all. | |
Thanks very much. One other thing though: what's the difference between cosine and bilinear interpolation?
| |
The first link explains how the rotation works and what the interpolation is doing. The seconds explains different interpolation methods. Cosine interpolation uses the part of the cosine curve from zero to pi to create a smoother transition. For this application I'm not sure if it really makes a difference.
http://files.byondhome.com/Forumaccount/rotation.html http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/ interpolation/ | |
I would just like to say that I truly appreciate this update you made to Pixel Movement!
| |