It would be nice if the image proc supported the use of planes.
Currently doesn't work.(unless I'm using it wrong.)
ID:2064547
 Apr 4 2016, 12:59 pm (Edited on Apr 4 2016, 3:48 pm)
|
|||||||
| |||||||
|
Apr 4 2016, 1:20 pm
|
|
Ter13
   |
The image proc returns an image object. The image object supports planes. But yeah, you aren't using it wrong. The image function doesn't support a plane argument.
|
Avidanimefan wrote:
It would be nice if the image proc supported the use of planes now instead of layers. I wouldn't say "instead of layers". Mainly, that would break backwards compatibility, but also, they're two different things. | |
Yea I'm aware.(on both issues)
The document says "going forward" planes is the preferred method. It's a bit inconvenient to have to use image(), then explicitly set the planes of an image thereafter. | |
The document says "going forward" planes is the preferred method. The preferred method of replacing EFFECTS_LAYER and BACKGROUND_LAYER yes (with some exceptions). Plane was not introduced to replace layer. Planes were introduced to solve a complexity with the rendering loop that made the code a nightmare to deal with and also made rendering significantly slower overall. The reason that planes were introduced was to simplify the rendering process by preventing objects on the screen from inter-layering with objects on the map by default. | |
If you do want to preset planes on an image, then I would suggest making an image subtype.
E.g.: image/target // show a target icon to players who've selected a given monster Calling new/image() should work the same as calling image() alone, but image() gives you a generic /image type whereas new() can give you a subtype. | |
I already have preset planes on all images.
Using the image proc is nearly the equivalent of using new/image as well. That's sort of what bought me here...... The impression I'm getting is "just write your own image initialization proc to support use of planes instead of using the default one". (Which..yea I could do.) That approach just fixes the problem for one person-namely me, not everyone else and doesn't solve the problem which has been bought to attention. (Which seems like a pretty simple fix honestly.) As a side note,this sort of response on something so small is also why I don't frequent the request forum with more finds I have had. There's tons of minor things I often have to code "work arounds" for which should probably be included, but when I visit the board with something small like this it usually gets brushed off or dismissed so why would I go out of my way to post other finds? The major one being the massive memory leaks the BYOND pager puts off occasionally that nearly grinds my PC to a halt. Which could also possibly account for poor gameplay experiences in general while using the pager. If something this small can't be taken seriously then ... why would I feel comfortable posting about ^ ? | |
Actually, - nevermind. I've been writing my own SDK tools for a while now due to a response on a post like this one in the past. I guess it doesn't really matter.
Forget I mentioned it, I'll just add it to my set of stuff. | |
@Avid: It's not a bad suggestion overall, only took issue with the "replace" bit. Originally popped in to let you know you weren't using it wrong though, to at least assuage that concern.
TBH it'd be nice to be able to specify any appearance-related variable in the image() proc. In general though, I don't really care for the global convenience functions as opposed to specific initializers, but that's just one man's opinion and has no bearing on the suggestion itself. | |