Color value from GETPIX_P returns unexpected result

[alexgt]

This is the cross post from CW, so is there a bug with the colors stored into GROBs?

Original post: http://codewalr.us/404/31183

I ran into a slight (ok very major) problem. It is going to be very hard to use GROBs to store data in, the values I found increment by eight. so if you store 20 in a pixel it will round to 24 (ok so no big deal just add 8 instead of one and when you need to get a value just divide the GETPIX_P() val by 8) but logically the next step would be 32, right? Well nope, it is 33 ??? I don't know why but it just does that, I have used other values and it isn't too major. 80 turns into 82, that can be fixed by doing this: IP(GETPIX_P(G9,0,0)/8) but if it fluctuates to much it could display the wrong block. I will look and see if I can get around this tomorrow. If this is a bug I hope can solve it :-\

[cyrille de brébisson]

Hello,

Prime uses 16 bit per pixels, not 24.
1 bit it transparency and then 5 bit per color.
Since user facing colors are ARGB8888, a conversion takes place.
In order for white to stay white and black to stay black in both domains, the conversion from ARGB1555 to ARGB8888 on the color channels is done by doing:
result= 5 bit input*8 + 5 bit input/4 to generate an 8 bit result. This is standard procedure in graphics.

At least this is what happens if my memory serves me well.

Cyrille

[alexgt]

Ok, so how would I convert the input I get from GETPIX_P() to 1,2,3,... respectively. Or pretty much how can I store data into GROBs as a substitute for matrices?

[cyrille de brébisson]

Hello,

If this is what you want to do, you really only have 15 bits of data in your grob per pixels.

The 'rule' is: ((pix>>8)&0x1f) + ((pix>>(16-5))&0x3e0) + (pix>>(24-10))&0x7c00)

You probably are better of storing your data in a string, it will be faster access and require less fiddling... I would advise storing data in packs of 15 bits and adding 1 to avoid using character 0.

Cyrille

[alexgt]

I was thinking about using a string, but if I had a 500x150 world I would have to have a string 75000 in length, and accessing rows would suck >.<

[Tim Wessman]

(02-02-2016 01:25 PM)alexgt Wrote:  I was thinking about using a string, but if I had a 500x150 world I would have to have a string 75000 in length, and accessing rows would suck >.<

Why? 75000chars*2 bytes, will be much smaller then a graphical representation.

my_string:="1234"
mystring(3) --> 3
mystring(3):="4" ->"1244"

That last one will even do direct access to the string - no memory allocations involved - so it should be rather fast too.

[Carlos295pz]

Apparently the string can only store up to 128 KB.

For large data structure, you may notice a little better speed chains, although the allocation of data is much faster with PIXON.

The use graphics requires conversion, making it inefficient.

The use of string seem appropriate while not exceed 128KB.

[alexgt]

(02-02-2016 03:47 PM)Tim Wessman Wrote:  

(02-02-2016 01:25 PM)alexgt Wrote:  I was thinking about using a string, but if I had a 500x150 world I would have to have a string 75000 in length, and accessing rows would suck >.<

Why? 75000chars*2 bytes, will be much smaller then a graphical representation.

my_string:="1234"
mystring(3) --> 3
mystring(3):="4" ->"1244"

That last one will even do direct access to the string - no memory allocations involved - so it should be rather fast too.

I think what I will do is make a list that is the height of the world and store strings in each of those elements

EDIT: I tested it and you can also store values into it, 65 = "A"

[Carlos295pz]

A string variable can contain up to 65,535 chars, and stored data can be from 0 to 65,535 (2 bytes).

mystring (1):= 0;
mystring (65535):= 65535;

If larger values are assigned, the data is cut:
0 = 0
1 = 1
...
65535 = 65535
65536 = 0 (don't use)
65536 + 1 = 1 (don't use)
65536 + 2 = 2 (don't use)
...
65536 * 3 + 1 = 1 (don't use) .....

[Tim Wessman]

Doesn't happen in the ios app... believe we addressed that problem in the shared code already.

[alexgt]

Well, I did some measuring and it just takes to long to use strings. If I made strings in a list and the list length is the height of the world it would be a nightmare to render all the blocks going vertically. I would have to store the list into a var, look at the selected spot on the string, then draw the block to the GROB.

If I skipped the list and just used one string I would have to figure out when it is time to go down to the next layer, this would also make world gen horrible to code.

So now I am thinking about going to matrices, would that be space effective or no?

[cyrille de brébisson]

Hello,

Matrices are stored as one blob of data. 8 byte per number.
Each number is stored with 4 bits (one nibble) for the sign, 12 (nibbles) for the mantissa in DCB (ie, used at 10/16 of capacity), normalized, and 12 bits for the exponent (hex, limited to +/-999).

If you use the m(x,y):= format, they will not lead to data duplication/copy and be quite fast.

But, they also have a size limitation, just like strings.

How much data do you want/need to store?

Lists are quite inefficient. They are a list of pointers to objects. So, you have 4 bytes per object in the list, plus the objects themselves. A real, for example takes 16 bytes (plus the 8 bytes used by the OS to manage memory allocation).

Cyrille

[alexgt]

I would ,ike to have a map 500x150 in size or 500x100. so really big matrices <_<

[cyrille de brébisson]

Hello,

Yep, that sounds like a reasonable use case of large data...

Unfortunately, some of the protections that we had to put in place to stop people shooting themselves on the foot are in your way here...

Unfortunately, I think that your only solution is to use a mixed list/string or list/matrix structure.

remember that you can access to sub list elements in "one go" using the variable(index_in_list, index_in_object...):= syntax.

Cyrille