A way to export appearances as icons.

Page: 1 2 3
Aug 20 2017, 1:29 pm
That too seems like a good fit for the client-side thing.

nope.

icon is saved to a save file, then exported as text to get a base64 encoded string of the icon.

The ability to export it as a base64 text is required for this feature, other wise we would just use the asset cache system to send the icon.

This system is used for code that has to generate icon html, but can not, at that moment, know what clients will receive the html, and sending it to all clients would be a balance breaking info leak.
Aug 20 2017, 1:41 pm
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.)

The key thing here, is that if its done in icon math by softcode, bland() has to extract, decompress, then re-extract, then re-compress the png FOR EACH LAYER.

Not even to mention that sometimes byond starts doing this to disk, adding that extra overhead.

Like, let me remind you, /tg/ already does this in softcode and its *okish*

a built in byond system would be able to skip that repetition of overhead for all but the beginning and end. A significant saving over Blend().


Icon blends are much slower than the rendering done on the client.

Each Blend() on a 32x32 icon should take at max 16k cpu cycles (4ns). MAYBE 65k cycles (16ns) with less-then-optimal use of registers. if you aren't hitting that mark, you are doing something wrong.

Aug 20 2017, 3:05 pm
The server wouldn't save much of anything. It too would have to decompress the icon files to use them. Anything the server can do currently in soft code, it wouldn't do much different hard-coded.
Aug 20 2017, 3:09 pm
What i mean, is it would only have to do it once for the target image, rather than repeatedly re-compressing and re-decompressing for each edit, as I assume it's already doing.

Furthermore, since most overlays tend to be in the same dmi file, it would be trivial to make it check if the last opened dmi file is the same the as the to be opened file, and shortcut past that and just use the already unpacked version. (Something the client could also benefit from if it's not already caching unpacked icon files.)
Aug 20 2017, 8:50 pm
In response to MrStonedOne
MrStonedOne wrote:
What i mean, is it would only have to do it once for the target image, rather than repeatedly re-compressing and re-decompressing for each edit, as I assume it's already doing.

It's not doing that. The /icon datum exists specifically to avoid all that. Decompressing an icon need only be done once, as long as there's room in a memory cache that keeps a certain number of icons open, and compressing into a .png is only done if the icon is finalized by saving it to the cache. Even then, with client-side icon math that's actually been changed considerably so the server doesn't really do any of it unless it explicitly needs pixel data like via GetPixel().
Aug 20 2017, 10:04 pm
IMO
I don't care if this is done on the client or in timbuktu, we just need a way to get a flattened version of what appears on screen after the renderer has had it's way with it and resend that to others

If that means running a trusted client on the server VM to do the work by god I'll make it happen

ON further reflection being able to refer to an atoms appearance clientside and have it displayed would be pretty neat as well, that solves one class of problems.

The photo and minimap stuff for me was always stuff that was stretching byond to it's limit.
Aug 20 2017, 10:09 pm
although actually, it would be nice to programatically be able to access a given clients render output and save to disk.

That lets us build an API using a trusted client that can run alongside the server to build photos and map images.

Even if it does sound somewhat insane
Aug 20 2017, 10:13 pm
In response to Lummox JR
Lummox JR wrote:
MrStonedOne wrote:
What i mean, is it would only have to do it once for the target image, rather than repeatedly re-compressing and re-decompressing for each edit, as I assume it's already doing.

It's not doing that. The /icon datum exists specifically to avoid all that. Decompressing an icon need only be done once, as long as there's room in a memory cache that keeps a certain number of icons open, and compressing into a .png is only done if the icon is finalized by saving it to the cache. Even then, with client-side icon math that's actually been changed considerably so the server doesn't really do any of it unless it explicitly needs pixel data like via GetPixel().

So, thats likely where the overhead is coming from then.

Since /icon/ is clearly not our gal, what's the likelihood of native image manipulation that doesn't assume it will be used in an icon? Because this abstraction you are doing is the issue.
Aug 21 2017, 9:32 am
In response to MrStonedOne
Actually it's the opening of the .png file on demand (DS can often do that in advance) and the subsequent software-based blending that are the main issues. The /icon abstraction, the fact that the code looks for multiple states to work with if present (if a specific state/dir/etc. isn't chosen), and the time to run soft code are all relatively minor, IMO, compared to the opening of the icon and the software blending. The software blending is, I think, as fast as I was reasonably able to make it.

Rendering on the client, even in software mode, can take advantage of things built into the GPU or the operating system.
Aug 24 2020, 3:18 am
I am still waiting for this.
Oct 23 2022, 3:55 pm
Lummox JR resolved issue with message:
client.RenderIcon() can now be used to create an icon file from an appearance, leveraging the client's rendering capabilities. Additionally, appearance reference strings (from the ref() proc or \ref operator) should be usable in outputs and browser controls.
Page: 1 2 3