A) Freeze a KEEP_TOGETHER overlay
I outlined this in my reddit post about my light system already (which probably nobody apart from Lummox actually saw): make it possible for a KEEP_TOGETHER overlay to be frozen when it's composite appearances don't change. From what I understand, KEEP_TOGETHER probably produces a surface and renders all those overlays onto it every renderstep. Some KEEP_TOGETHER overlays, like my lights on my light system, might never (or almost never) actually change, so it would be good if the surface could be kept around to be reused the next time those overlays need to be drawn. This could probably be done automatically in that changing the overlays that are components of the KEEP_TOGETHER overlay will mark their root node dirty and dirty forces the surface to be redrawn. This is building on the assumption that the KEEP_TOGETHER surface actually draws a surface every drawstep and would mostly be a performance improvement. (Also appearance -> icon is not a very good fix for this)
B) 'Glueing' two atoms together
Probably a feature that has been suggested atleast once before. Say we have two atoms, A and B. It would be cool if it was possible to have the draw location of B always be the draw location of A without B being an overlay of A. This would make a large number of things possible, for example: say we have a stone tablet. We want this stone tablet to show up differently to cultists of Cthulhu. We can now do a few simple steps to ensure this functionality:
- assign an empty image with override enabled and loc as the stone tablet to the cult member's client's images list
- make a fake atom called "stone tablet of cthulhu" and have it drawn at the location of the actual stone tablet
- assign an empty image with override enabled and loc as the stone tablet of cthulhu to any client that is not a cult member
(you can probably easily come up with better pseudocode for this, this would be atrocious in an actual game)
voila, we would now have a stone tablet that either displays "stone tablet" or "stone tablet of cthulhu" dependent on whether we are a cult member. This is a weird example, but in general this would allow atoms to have properties that differ between clients, and it would also allow atoms to "ride" other atoms.
C) More control over SEE_SELF
Being able to determine that a specific atom needs to always be drawn by a client would also be a very helpful feature. My original idea involved a list on the client in the same vein as screen and images, somebody in the IRC came up with it being more fine-grained control over SEE_SELF or something.
ID:2045074
 Feb 28 2016, 9:17 am
|
|||||||
| |||||||
In my experience, A was always a huge performance gain, dependent on how many composite images you're actually drawing. It's basicly a stock optimization. We're talking something around 60-70 overlays per light source here, and needing to be redrawn every single time is uh... well... expensive is a bit of an understatement.
B is essentially saying that i want an atom in the exact same clientside location as another atom. This can be done serverside, but it's iffy with animate and gliding (legacy features woo), etc etc, it would be much better for the client to handle it. C is an extension to SEE_SELF, SEE_OBJ, SEE_TURFS etc, in that a seperate list of atoms would exist on a client that contains atoms that must be displayed to that client. This niche exists because screen objects will always be drawn, but they move with the screen and can't be anchored to a certain maptile or atom location, so this would become redundant if you allow for B and also allow screen objects to have a draw_loc set. | |
it seems like for C that what you really want is client images.
var/image/I = new(atom_to_attach_to) I.icon = blah client.images += I It boils down to what you mean by this: LordBistian in that a seperate list of atoms would exist on a client that contains atoms that must be displayed to that client. is this list a list of instances or types. if it's a list of instances, then you can do the same with client images. how ever I suppose allowing the client images list to support atoms directly to override invisibility might be a worth while feature. (in that vein, it would be nice if there was a way to have client images store a list by reference rather then merge it so we could "subscribe" clients to a given global list and then update that list directly rather then have to also store subscribed clients, remove the old list from every client, and add the new list to every client every update. (or other more fine grain updates that still involve looping thru all clients) (That being said, at ss13 we already made such a system that basically lets us do this in higher level code.) | |
Make no mistake to think that I haven't worked with client.images, it's simply not powerful enough in this situation. There's very obvious limits that you'll very quickly reach if you have a list of atoms that will only display at a specific, STRING-BASED coordinate (vector types wheeeeeen!?) and a list of images that will only be drawn if their parent atom is also being drawn.
1) appearances currently will not auto-update to reflect the atom they were created from using image(atom) if added to client.images 2) they would need to override any form of invisibility, we're talking darkness, fov, etc etc (hence the word regardless was used in my prior description) If we're going to delve a little more into space station code, you might recall the mining scanner that's a subtype of some other scanner that i forgot about. It only works when you have mesons on, as it applies client images to turfs you can't see and mesons give you SEE_TURFS. This is one example of something that could easily be circumvented if we could just set an atom to always be drawn. | |
Point.
| |
LordBistian wrote:
1) appearances currently will not auto-update to reflect the atom they were created from using image(atom) if added to client.images This I really don't understand. Appearances are not added to client.images; images are. An image, once created, has its own appearance. Images aren't created from atoms; they're created and then attached to atoms. 2) they would need to override any form of invisibility, we're talking darkness, fov, etc etc (hence the word regardless was used in my prior description) Indeed, it is in the nature of images that they're impacted by the visibility of their parent atom. But I don't see a separate images list being wieldy at all, for many reasons. | |
What he means is, he wants to add an atom, and the atom's appearance to a list that acts like see_* in that it overrides everything else that could occlude it. and he doesn't want to have to use an image middle man because the image has its own appearance, and thus you would have to update the image's icons if the target atom's icon changes.
| |
Occlusion is considered on a per-tile basis, so that would be extremely difficult to setup.
| |
you can do it for turfs or mobs using see_turfs or see_mobs.
so expanding that would be helpful and make sense. None the less you know the code. Hopefully you can figure out some sort of system to expand see_* but that's one of the lesser requests on this thread, request A sounds interesting, as this is one of the cases where dirty marking might be worth it performance wise | |
For B, if I'm reading that right you want something that's more like a real atom than an image, but otherwise works the same? It's hard to wrap my head around that.