In response to Wizkidd0123
Wizkidd0123 wrote:
Green Lime wrote:
hmm O.o so If I made a GetPixelColor() function you would download and use it? I just dont want to do somthing like that and no one use it.

If you made a GetPixelColor() proc, then yes, we would download it. However, at the moment, as far as I can tell, it's completely impossible. The only efficient way to do it is to binarily read the icon. Although we know the .dmi format, to binarily read a file, as Foomer is requesting, ascii2text() would have to be used. Unfortunately, since BYOND can't doesn't handle certain ASCII characters very well, the most notable one being 0, it isn't possible, at the moment, for BYOND to read a file binarily.

Why doesnt ascii2text() handle certain ASCII characters well? Is it a conversion problem? So like ascii2text(0) to text form and then text2file() the text I just converted wouldn't be the ascii value 0? Cause the text converts the 0 to what null or nothing? What about � in the text would that work?

Ps what would you want this function to do exactly? Like GetPixelColor(x,y) and it would output what RRGGBB?

Yup: GetPixelColor(px,py). However, preferably, it would output a hexidecimal RGB value: all of the other rgb-related procs do. rgb() itself, is, in fact, just a dec2hex() proc: it converts its three numerical arguments and returns them as a hexidecimal value. The return value of rgb() is a text value.
In response to Crispy
Crispy wrote:
Whoops! My bad. Normally I check to make sure people are replying to who I think they're replying to; must've forgot this time. =)

Typical - the one time I don't check...!

But wouldn't it always be the one you didn't check? and whats Typical mean?
In response to Wizkidd0123
Wizkidd0123 wrote:
If you made a GetPixelColor() proc, then yes, we would download it. However, at the moment, as far as I can tell, it's completely impossible.

Icons become data like this when you save them as text:
filedata("name=px.dmi;length=41;crc32=0x75a5bbbc;encoding=base64",{" BERNSQECAMDAwAAAAAEAAQABAAEAAAAAAAAAAAYA////4wEfEAIABAA= "})

All the data about the icon is present, so one could extract the information about any pixel in any frame of any icon_state, if they knew the format.
In response to Shadowdarke
The format is explained in [link]. To get that inofrmation, as far as I can tell, I would have to be able to read the bytes.
In response to Wizkidd0123
Wizkidd0123 wrote:
The format is explained in [link]. To get that inofrmation, as far as I can tell, I would have to be able to read the bytes.

You can do that with what Shadowdarke mentioned. All you need is a proc to convert at least part of the base64 encoding to numbers in a list. I've used this technique to successfully extract the palette of an icon.

Lummox JR
In response to Green Lime
Green Lime wrote:
Why doesnt ascii2text() handle certain ASCII characters well? Is it a conversion problem? So like ascii2text(0) to text form and then text2file() the text I just converted wouldn't be the ascii value 0? Cause the text converts the 0 to what null or nothing?

Basically. If you want to make a file that consists of bytes:
<code> 0,0,0,0,1,0,5,0</code>

And you convert it to text, you'll get the 1 and the 5 converted, but all the zeros will be ignored. Thats the only problem I'm aware of, anyway.
In response to Foomer
Foomer wrote:
Green Lime wrote:
Why doesnt ascii2text() handle certain ASCII characters well? Is it a conversion problem? So like ascii2text(0) to text form and then text2file() the text I just converted wouldn't be the ascii value 0? Cause the text converts the 0 to what null or nothing?

Basically. If you want to make a file that consists of bytes:
<code> 0,0,0,0,1,0,5,0</code>

And you convert it to text, you'll get the 1 and the 5 converted, but all the zeros will be ignored. Thats the only problem I'm aware of, anyway.

I don't think you'll even get the 1 and 5 converted. Strings in C are terminated by the null character(ascii 0). I don't think that BYOND loads anything from a file that's found after an ascii 0 character.
In response to Lummox JR
Lummox JR wrote:
All you need is a proc to convert at least part of the base64 encoding to numbers in a list.

I know absolutely nothing about base64 encoding. How would you do that?
In response to Shadowdarke
Shadowdarke wrote:
Wizkidd0123 wrote:
If you made a GetPixelColor() proc, then yes, we would download it. However, at the moment, as far as I can tell, it's completely impossible.

Icons become data like this when you save them as text:
filedata("name=px.dmi;length=41;crc32=0x75a5bbbc;encoding=base64",{" BERNSQECAMDAwAAAAAEAAQABAAEAAAAAAAAAAAYA////4wEfEAIABAA= "})

All the data about the icon is present, so one could extract the information about any pixel in any frame of any icon_state, if they knew the format.

I tried to save the icon object as a text but it just outputed /icon. Uhh I guess Im not sure what you ment about the above.
In response to Wizkidd0123
base64 encoding is pretty straightfoward. We'll take a simple text string for example: Dog

base64 takes 3 bytes and encodes them as 4 base64 characters, with the leftmost character being the most significant bits.

D is ascii 68, o is 111, and g is 103. Lets puts those together to form a 24-bit number, which will then be broken up into 4 6-bit numbers which correspond to specific base64 characters:

01000100 01101111 01100111

The base64 table is as follows:
0-->A
...
25->Z
26->a
...
51->z
52->0
...
61->9
62->+
63->/
= is used as a pad, basically 0's are used to pad the number.

So now we need to break up the 24-bit number into 4 6-bit numbers and then turn them into base64 characters:

010001 = 17 = R
000110 = 6 = G
111101 = 61 = 9
100111 = 39 = n

So Dog encoded in base64 is RG9n. Not too tough.

Decoding itself isn't too much of a pain, but with BYOND, you only have a 16-bit shifting range, so you need to break things up(unless I overlooked something). The easiest way would be to read in 4 base64 characters at a time, get the value that correpsonds to the base64 characters, and then use some bit maniputlation to get the 3 bytes that correspond.
In response to tenkuu
I understand now. Thanks, tenkuu! =)
Page: 1 2