Apr 23 2011, 12:19 pm
|
|
Bravo1
 |
It's up on the forum now in Libraries and demos in a thread called "Camera Lag" I hope you find it useful and I hope I made it understandable, though you'd probably manage to understand it even without comments, it's pretty straightforward.
|
I found a mistake you made in your Region library. See the comment I left on your hub for more details.
| |
I'm thinking of modifying collision detection for Darkness so that when you bump against walls it checks your bounding box and when bumping against mobs it checks the center of the bounding box, compares it to the center of the other mobs box and then works off of an absolute distance between both centers, essentially making bumping between mobs circular. The only problem is, how would bump() detect which side the mob is on. I'm thinking of adding it as just an angle instead of up, down, left, or right. I'll see how it turns out because ultimately, I need to do it if I want the mobs to damage the player based on "reach", and if I'm calculating from the origin of either mob (bottom left corner) it comes out wonky, especially with larger mobs.
On a side note, if you haven't made them already, I've made 2 procs that may help. px_dist() calculates distance between 2 mobs (in a straight line so only 1 number is returned) and px_cdist() does the same, but instead checks the centers of both mob's bounding boxes. Let me know what you think, in the meantime I have to go shut up my dog o__o | |
I was thinking of splitting the pixel_move proc into two procs. The second proc would handle the collision detection, so you could override just that proc to do this. You'd override the proc to say "is this a circle-circle collision? If so, handle it, otherwise call ..()".
You'd have to write the collision detection code for circles, which would call bump and pass whatever you need. The bump proc would check if the first arg is a mob - if it is, it was a circle-circle collision. | |
Okay, a few things I have to ask/talk about.
1. Is there any way to assign multiple keys to K_UP, K_DOWN, etc? I could do it myself, but I'd rather not override the library too much as I don't want any strange behavior unless it's absolutely necessary. 2. There's an issue with bump() when returning VERTICAL on isometric world format. If you bump an object from below you get stuck inside the object. I'm fixing this by just checking the pz of the src and the object it's bumping and then making vel_z equal to the max fall speed, but it feels hacky. 3. There's no offset_z variable and when it comes to isomeric, sometimes turfs overlap and cause issues. I implemented my on version of it which works exactly the same as offset_x and offset_y but I'd feel safer if you were the one who implemented it, as I don't know if there's any behind the scenes issues with adding it. It'd be much appreciated if these issues are addressed. This is one of the best libraries on BYOND and I just want to see it perfected. Sorry if I sound pushy. =P | |
1. There is no easy way to do that currently. I am considering a solution for this, but I'm not sure if I want to add it.
2. Ok, I'll fix this. It's just something I haven't looked into. 3. Ok, I'll add that. It's not pushy at all. These are good feature requests :-) | |
Also, it seems like you can't walk under a ramp block even if it's pz is highly elevated.
I haven't looked at how ramps work in isometric mode, but if it breaks ramp functionality then don't worry about fiddling with it, as it's not a big deal if I can't walk under ramps. | |
That should be a really easy fix. I knew it would happen, but the situation never came up.
| |
There's an issue with stacked atoms, if you walk into a stack of atoms while falling you'll bump the top of the atom under the highest one, basically allowing you to walk on walls while moving towards them.
If there's any other bugs/glitches I'll let you know. Oh also, I've made a Sonic the Hedgehog demo that works with the current library. If you want to add it in then just let me know and I'll get it to you. It's nothing amazing though, really, it's just a curved ramp that you can move across at high speeds, but still It though it was interesting. | |
I'm not entirely sure what the issue is that you're describing. Can you post a more elaborate description on my forum?
About the demo: I'm always looking for more demos to include. Ideally, I'd like it to get to the point where people make hub entries for their own demos about how to use my libraries. For now, I'll take a look at anything to consider it for inclusion in the library. I'd like to add some more significant and complete demos, so maybe it'll be more appropriate if the demos grows into something larger first. | |
http://www.youtube.com/watch?v=tcbAlrnyhFs
There's a link to the video of what the full demo comprises, I'm going to add more to it of course. As for the issue, I'll try to get a video of that so you can better see what I'm talking about, since it's a little funky to explain... | |
About the demo: Adding some more things would help: moving platforms (with a twist: ones larger than 32x32, circular paths, etc.), enemies with AI, or something else.
About the issue: It might help if you give me some code so I can generate it on my end. If it relies on how objects are positioned, you can write code to generate the object placement. | |
Anyway i could get in contact with you?
| |
Zane444 wrote:
Anyway i could get in contact with you? You can post a comment here, post on my forum, or page me. If none of those are sufficient, I also have Yahoo Messenger. | |
Just to let you know I'm going to make a system that allows you to remap the movement keys. I've also made something which allows you to move in the correct direction in case client.dir is different than default, but I don't expect many people to even do that. If you want to see what I come up with then let me know, you probably don't need it at all for the library but I figured I'd keep you in the loop.
| |
Ok, let me know what you come up with for the key mappings. I have an idea for how to handle it but I don't really like it.
| |
I haven't gotten to work on either of those things I talked about but I was about to make some more modifications to pixel_movement I wanted to make you aware of. I'm trying to figure a way to process collision from the center of a mob instead of the bottom left pixel and as I'm typing this I may have just figured it out. Regardless, I'll keep you updated.
| |
Basically when detecting the atom, the edges are currently detected as
x1:px y1:py x2:px+pwidth y2:py+pheight Instead you could calculate it as x1:px-pwidth/2 y1:py-pheight/2 x2:px+pwidth/2 y2:py+pheight/2 Thsi will cause the atom to have a px and py relative to the center of the bounding box. This is a little bit better (in my opinion) because it doesn't cause issues when changing client.dir, which causes graphical bugs (especially in isometric.) If it's possible to implement this without removing the former system then great. Even better, if the bounding box could be offset from the px and py then even better. basically it could be something like: bounds_offset_x=-16 bounds_offset_y=-16 This would essentially center the px and py within the center of the box after normal calculations. I notice I'm kind of ranting but I think I got the idea across. I'm not saying the current system is bad, quite the opposite, but in some cases it causes graphical issues and could be easily addressed. Thanks for taking the time to read my ramblings XD | |
Also, I'm having an issue with the optimization code included in Pixel_Movement. It seems to work perfectly except mobs the mobs don't activate. I'm overriding movement() for the AI but it does return to ..() I'm wondering if that's an issue...
On a side note, I also expanded front() to include diagonals. | |
The problem could be one of a few different things:
1. It's never getting added to the list. This is handled by the mob's constructor. 2. It gets added to the list but it's getting removed from the active list when it shouldn't be. This is handled by the mob's movement() proc. 3. It's getting removed ok but it's not getting added back when it should. This is handled by the player's Move() proc (yes, with a capital M). | |