I looked at that library and discovered you can do overlay:icon, knowing this has solved all my problems, thanks
for future reference, what type are overlays then? atom? because they can be obj or image? they have a layer and an icon too, just like obj and images
Overlays are appearances.
| |
Coming for 512 right Lummox :D
| |
Oh god, I forgot about this.. Did this make it in the 512 features?
| |
Not yet, and the main reason is that I haven't been able to figure out a good way to go about it. Truth be told it's a thorny problem.
Ultimately this relies on rendering code. If it's done at the server end that means something has to be built on the server to do all that. If it's done on the client end, then it has to be rendered offscreen (preferably using the hardware renderer) to work properly. So it's been a matter of figuring out the best way to go about it, and I haven't decided on anything yet. | |
I think you might be taking it too far.
atm, just something to take a appearance or a atom and get an icon that has all of that things layers merged up would be what 99% of the people are looking for. This is a proc that does this in soft code: https://github.com/tgstation/tgstation/blob/ d144c88fb5b84341cd4ec147a8ba57731a926e12/code/__HELPERS/ icons.dm#L648 Just start with something to merge layers into one icon then work your way up. Actually, just start with making sure you have everything needed to support icons from images and appearances in compiled code for 512's first release and then you can add it as a feature in a later release. =P | |
MrStonedOne wrote:
I think you might be taking it too far. The problem is that the server has no rendering context, and the client cannot reliably transport those files safely back to the server for use after creation. It's not a problem of actually doing the render. It's entirely a problem of consistency of design. | |
My thinking here is that the main use for this really isn't for server stuff anyway; that is, I don't see this ever being used in, say, icon math. So with that being the case, it seems reasonable that a single special reference could be used to point to an appearance--or, in more complicated form, versions for each atom type and /image could also be used--and the client would simply build that appearance on an on-demand basis.
| |
I don't see this ever being used in, say, icon math. But, thats exactly what we want it for. Most of the images created with such a system would go to browse_rsc and be sent to browsers. ie, it has to be an actual compiled image of the atoms current appearance, and it has to exist on the server. The other use would be the minimap, and that is cached on the server as a png. | |
The problem is that the server has no rendering context It doesn't need a rendering context, it needs to blend a bunch of overlay png's together into one png. if Blend() wasn't so laggy, i'd just do this in softcode. (in fact we already do, and it consistently becomes a dos vector) Supporting advance things, like keep together and plane masters would be nice. but atm ss13 would settle for a way to collapse an atom and it's overlays into a single image that could be written to disk or sent to browsers that doesn't take 5ds+ on a 28 layer atom. The rest can come later. | |
But if this is a client-side thing, that's not incompatible with browse_rsc(). I'm already considering a change that would make resources easier to send along if they're already in the .rsc file, and sending along a reference that says "use the static appearance of X" could simply trigger a hidden rendering and then a callback to create the needed .png.
| |
It doesn't need a rendering context, it needs to blend a bunch of overlay png's together into one png. Yes it does. Because of how appearances are rendered. Appearances are not just a series of icons. They are a series of icons modulated by matrix transformations, color matrices, etc. There is a whole shader pass involved in rendering now that didn't exist in previous years. Duplicating the shader in software mode is just straight up a massive time sink. If we're talking about generating the appearance of an object, it has to match how it is rendered. BYOND's server is renderer agnostic because we have elected to allow the server to live on linux as well as windows, not only that, but the server lives in a pure data world. DirectX is windows-only. This would be less of an issue if we weren't using DirectX, but that kind of a change is not a small one. | |
Yes it does. No, it doesn't. If i can do it in softcode (and i can) byond can do it in hard code, and it can do it in a way that isn't anywhere near a massive cpu hog. Thats like saying we can't have view() because that requires context only the client code has. view() is not the same as the clients view calculation, there are some edge cases where the two differs, but we acknowledge that there is benefit to the server being able to get an approximation. | |
If we're talking about generating the appearance of an object, it has to match how it is rendered. No, it doesn't. I am perfectly ok with certain things not being supported. | |
MrStonedOne wrote:
If we're talking about generating the appearance of an object, it has to match how it is rendered. The more I think about this feature as a language addition, the more it feels like a bandaid that only serves to shore up existing bad implementations/ideologies that could be otherwise solved in better ways. And you are right. This could totally be implemented poorly. | |
Lummox JR wrote:
But if this is a client-side thing, that's not incompatible with browse_rsc(). I'm already considering a change that would make resources easier to send along if they're already in the .rsc file, and sending along a reference that says "use the static appearance of X" could simply trigger a hidden rendering and then a callback to create the needed .png. /tg/ uses getflaticon for a few things. I'm going to detail all of them. 1. previewing characters in the setup character browser window. We take 3 images (side, front, back). of the same atom (a human mob) and Blend() them onto a full black canvas that is then browse_rsc 2. In game photo camera images. We take a 3x3 range around where the user clicks, and generate this in a image using blend(). we send to the user (as well as anybody who gets their hands on the in game object) then upload to the website so anybody can view images created in previous rounds. 3. Minimap generation. a 1/8th scale version of the map is created. only showing turfs and certain objs. This is cached on the server since it takes awhile to generate and is only regenerated on map change. 4. Mob "Mug shots" in the in game security records computer. (same image as 1. usually) 5. Proposed use: (pending this feature) generic \icon for browser things. icon is saved to a save file, then exported as text to get a base64 encoded string of the icon. that is embedded in a img html string to be sent out. This is used when the users who can see an icon is not known at generation time, but browse_rsc()ing it out to everybody would be a info leak. This system currently only supports the atoms current icon, none of its overlays. | |
Ter13 wrote:
MrStonedOne wrote: See: Thats like saying we can't have view() because that requires context only the client code has. view() is not the same as the clients view calculation, there are some edge cases where the two differs, but we acknowledge that there is benefit to the server being able to get an approximation. | |
MrStonedOne wrote:
/tg/ uses getflaticon for a few things. I'm going to detail all of them. This would work fine with the client-side implementation I proposed; the only change is you'd have to display three <img> tags in one spot. 2. In game photo camera images. We take a 3x3 range around where the user clicks, and generate this in a image using blend(). we send to the user (as well as anybody who gets their hands on the in game object) then upload to the website so anybody can view images created in previous rounds. This one I find problematic to reproduce. But there is absolutely no way to do that quickly on the server end. (Even with client-side icon math like we have now, this kind of thing would always be done by the server.) Icon blends are much slower than the rendering done on the client. 3. Minimap generation. a 1/8th scale version of the map is created. only showing turfs and certain objs. This is cached on the server since it takes awhile to generate and is only regenerated on map change. This case is tricky as well. 4. Mob "Mug shots" in the in game security records computer. (same image as 1. usually) The client-side appearances would fit this just as well as the #1 case. 5. Proposed use: (pending this feature) generic \icon for browser things. icon is saved to a save file, then exported as text to get a base64 encoded string of the icon. that is embedded in a img html string to be sent out. This is used when the users who can see an icon is not known at generation time, but browse_rsc()ing it out to everybody would be a info leak. This system currently only supports the atoms current icon, none of its overlays. That too seems like a good fit for the client-side thing. The minimap and mini screenshots are the two cases I think are problematic. There's no way to handle them quickly using icon math, and icon math also can't currently handle transforms and various other features. If I try to put more of that on the server, what I basically end up with is a server-side software rendering engine, and as it is I'm looking to get away from the software rendering engine on the client. | |
http://www.byond.com/forum/?post=2039888
This is already on the list for 512:
http://www.byond.com/forum/?post=2180072
Here's a library that somewhat does this already:
http://www.byond.com/developer/DarkCampainger/GetFlatIcon