Welcome to the return of snippet sundays. I'll only be doing these infrequently from here on out, and I'm only going to be showing off things that I myself find particularly interesting. If you have an idea for a snippet Sunday, or a particular problem that "BYOND can't do", bring it up and maybe I'll see about taking a look at the problem on a lazy Sunday in the future.
Anywho, today's writeup is going to be all about /image objects.
What are they?
/image objects are a purely visual atom, which act sort of like a cross between normal movable atoms and overlays. Normally, when a movable atom is in the contents list of another movable atom, it doesn't render anywhere. Images are unique in that they can be assigned a location of another atom, and appear on top of their location as a visual effect. Images can also be used on top of areas and turfs. One thing that not many people know, is that an area will render at every turf location that is included in the area's contents list, effectively allowing you to render a single image object in multiple places at once.
What can you do with them?
Image objects allow you to control which players have the ability to see them. You can also use image objects to override the visual appearance of an object completely. Let's take a look at one particularly interesting use of this approach: Rooves.
There are a number of roofing libraries on BYOND that all do roughly the same thing:
This roofing library has so much wrong with it I can't even begin to detail it all. Basically, it uses at least nine image objects per client, and adds them all to the client when they can be seen, rather than hiding only a single roof at a time. On top of that, image objects are deleted using the del instruction, rather than simply removed. There's even more wrong with it, but I won't go into it all here. Needless to say, stay away from this approach as though it were the plague.
This roofing library uses invisibility, rather than image objects. This means that you can't use the invisibility variable for anything but roofing. Therefore, it can't be used if you plan on using invisibility for anything else. It is, however, incredibly simple.
This roofing library uses images, which is great. Unfortunately, Shadowdarke's library adds all roof images that the player is currently able to see to the images list of the client. I'll detail why this is bad further on. Also, ShadowDarke's roofing library is missing some features that would make it truly great, Such as being able to customize roofs on the map, and being able to have roofs use more than a single image for the entire area.
As for why adding the images for all roofing tiles to the client's view list when they are visible, this is bad because every frame for every client, the server checks for changes to any image in the client's images list. This will cost you a chunk of CPU, and it makes the images list of the client just a bit harder to use.
So, we're going to spend some time putting together a roofing library that doesn't suffer from any of these weaknesses.
Let's outline what the roofing system SHOULD do before we get started building it.
1) It should use no more than a single image object per unique roof tile.
2) It should be paintable on the map.
3) It should not require placement of special objects that determine the entry points and exit points to the building.
4) It should not require the user to paint a bunch of complex areas on the map to get it to work.
5) It should only use the images list for the single roof that we are NOT showing, rather than for all of the roofs we ARE showing.
Now, #5 might give you some pause. "But Ter, we can only use the images list for images the player CAN see! Players can't see the images by default!". Well, I hate to break it to you, but that's a faulty assumption and it's plagued just about every system I've ever seen written that uses /image objects since 2002.
Per usual, I'm here to explain to you why everything you know is wrong. Let's get started, shall we? (To be continued in two more posts)
Mar 1 2015, 5:15 pm