Issue:
 Problem description: Whenever I shrink the bounding boxes on my projects icons to where a 'person' would actually stand, I seem to run into this issue. Is anyone currently aware of any fixes to this issue outside of extending the bounding box. Thank you very much in advance, I'm looking forward to your diligent responses. | |
|
Jun 15 2016, 9:10 am
|
|
FKI
 |
Not descriptive enough; add more information, including exactly what you are doing, how you are doing it, and the exact problem we're supposed to see in your cropped screenshot.
|
You could add really small decimals to the layer value depending on the mobs absolute pixel y location every time they move, you would have to also call it on objects as well
| |
In mob/Move() I pretty much put this: layer = y + (step_y / world.icon_size)
Works fine for me to keep mobs layered how they should be | |
Zagros5000 wrote:
You could add really small decimals to the layer value depending on the mobs absolute pixel y location every time they move, you would have to also call it on objects as well Related: | |
Be aware that this will absolutely murder framerates. If it can be helped, use SIDE_MAP format. The new atom plane feature should have fixed the problems that we were having with that map format.
Microlayering on a large scale will cause the per-frame layer-plane-y sort to eat up a huge amount of resources on low end machines. | |
Appearance churn would be part of the performance issue, although one slowdown due to changing appearances has been addressed in 510.1346.
| |
Ter13 wrote:
Be aware that this will absolutely murder framerates. If it can be helped, use SIDE_MAP format. The new atom plane feature should have fixed the problems that we were having with that map format. SIDE_MAP is fixed now huh... What is this "atom plane" thing, is that something I have to work with manually or should SIDE_MAP "just work" now? | |
Overlay flickering still seems to occur, however it is on a very rare occasion and that is something I can deal with...
Thank you for your responses, my problem has been resolved! | |
if ur still seeing overlay flickering then its going to get a lot worse once players actually log in
| |
Overlay flickering still seems to occur Set your overlays to use FLOAT_LAYER. What is this "atom plane" thing Look it up. Seriously. F1->Plane. Plane is like layer but has a higher precedent. Anything on the same plane will render with anything else on the same plane. It's hard to explain fully, but it's documented. | |
What are some code examples of adding overlays as FLOAT_LAYER?
| |
layer=FLOAT_LAYER
add the overlay | |
The layer of the mob or what? That's what I'm confused about.
Or this: var/image/i = image(icon = 'whatever.dmi') | |
That's correct. The overlay you're adding is a snapshot of the image. Giving it FLOAT_LAYER means it will appear above your mob, and it will take on the nearest non-float layer (which would be your mob's layer).
| |
Yea but should I be using images as overlays? I thought that was bad. What's the best general purpose way of adding an overlay as FLOAT_LAYER? Thanks
| |
Or if you care about performance:
obj/character_appearance | |
I suppose that works for me although I have always avoided adding objs as overlays because I thought it was probably bad for performance. But you say it's fine so, I'll try it out, thanks.
| |
I have always avoided adding objs as overlays because I thought it was probably bad for performance. You aren't adding objs in FKI's example. FKI's example adds a prototype. objects and images aren't stored in overlays or underlays. Those lists store appearances. Creating objects or images to create overlays in most cases is pointless. It doesn't matter what you add so much as you understand what you are doing when you do it. | |
