LoginLogin

Compact coordinate conversion

Root / Submissions / [.]

MZ952Created:

Integer Implementation

DEF COMPACT(X0%, Y0%, X1%, Y1%, MXW%, MXH%)
 DIM C0% = Y0%*MXW% + X0%
 DIM C1% = Y1%*MXW% + X1%
 DIM C2% = C1%*MXW%*MXH% + C0%
 RETURN C2%
END

DEF EXTRACT C2%, MXW%, MXH% OUT X0%, Y0%, X1%, Y1%
 DIM C0% = C2% MOD MXW%*MXH%
 DIM C1% = C2% DIV MXW%*MXH%
 X0% = C0% MOD MXW%
 Y0% = C0% DIV MXW%
 X1% = C1% MOD MXW%
 Y1% = C1% DIV MXW%
END

Floating-Point Implementation

DEF COMPACT(X0#, Y0#, X1#, Y1#, MXW#, MXH#)
 DIM C0# = Y0#*MXW# + X0#
 DIM C1# = Y1#*MXW# + X1#
 DIM C2# = C1#*MXW#*MXH# + C0#
 RETURN C2#
END

DEF EXTRACT C2#, MXW#, MXH# OUT X0#, Y0#, X1#, Y1#
 DIM C0# = C2#-(MXW#*MXH#)*FLOOR(C2#/(MXW#*MXH#))
 DIM C1# = FLOOR(C2#/(MXW#*MXH#))
 X0# = C0#-MXW#*FLOOR(C0#/MXW#)
 Y0# = FLOOR(C0#/MXW#)
 X1# = C1#-MXW#*FLOOR(C1#/MXW#)
 Y1# = FLOOR(C1#/MXW#)
END
What these functions essentially do is performing mathematical steps to re-represent the given data. COMPACT receives two sets of x-y coordinates (x0, y0, x1, y1) and converts them into a single value which may be stored, and perhaps later passed through EXTRACT, where it retrieves the original two sets of x-y coordinates given that it has the original MXW (maximum width [highest allowed x-value]) and MXH (maximum height [highest allowed y-value]). For the integer method of this, the highest values for MXW and MXH are {320-1, 145} and {320, 145-1}. For the floating-point method, these values are untested.

you could store x in 10 bits and y in 10 bits. That lets it go up to 1023 on both x and y.

Replying to:DFrost
you could store x in 10 bits and y in 10 bits. That lets it go up to 1023 on both x and y.
heck, you could include z, too because ints are 32 - bit so you can distribute these evenly with two bits left over. You could use these as masks or something like that. Maybe a bit to signify that it is a point...

what advantages does this have over RG BREAD?

Replying to:Yolkai
what advantages does this have over RG BREAD?
I thought this was for defining points and putting them into variables

Replying to:Yolkai
what advantages does this have over RG BREAD?
RGBREAD does the same thing, unpacking four 8-bit RGBA values from a 32-bit integer. It's just that (from my experience) it's consistently slower than just writing your own function for the same thing.

Replying to:DFrost
you could store x in 10 bits and y in 10 bits. That lets it go up to 1023 on both x and y.
You're storing not only x and y, but x0, y0, x1, y1 inside of c, versus just an x, y, and z inside of c.

Replying to:Yolkai
what advantages does this have over RG BREAD?
RGBREAD may be more effective for one's purposes if you want to go up to 248 on an x, y, and z parameter, however, this function works with 2 sets of X-Y coordinates, not a trio of values. I believe RGBREAD glosses over a lot of values due to lossy color conversion. Edit: forgot the alpha channel was a thing.

Replying to:DFrost
you could store x in 10 bits and y in 10 bits. That lets it go up to 1023 on both x and y.
well Y goes down to 239(on the screen) and 8 bits are 255 and X goes to 400, so you would need 9 bits for 512. You could use the fifth bit on X for the Y value. It would look like this: XXXXXXXXYYYYYYYYYXXXXXXXXYYYYYYYYY but that would be 34 bits, so you could do this: XXXXYXXXYYYYYYYYXXXXYXXXYYYYYYYY which would be 32 bit. Reread it to understand X needs 8 bits, but with 16 left over. You could use that bit for the y and nullify it for x Or you could use reals

Replying to:Yolkai
what advantages does this have over RG BREAD?
RGBREAD/RGB just convert between four 8 bit values and one 32 bit value. You can increase the range of your system by using floats rather than integers (a 64 bit float can store all integers from 0 to 2^53 (and more, but with reduced precision), rather than 0 to 2^31-1 for a signed 32 bit integer)

Replying to:Yolkai
what advantages does this have over RG BREAD?
Are we just going to ignore the random space?

Replying to:Yolkai
what advantages does this have over RG BREAD?
@12Me21 You know, this is probably the go-to method anyhow, considering that if you go higher than the parameters specified in the post, you'll get an Overflow error on line 4, where it is attempting to stow the resulting expression into C2%. I always thought that SB would just chop the value off at the highest allowed bit, but I guess it elects to error instead. Edit: considering that it's only working with 32-bit integers in the first place, I wonder how it managed an Overflow, unless it processes expressions in floating point, which I guess means that the Overflow happened somewhere in the process of converting float -> int.

Replying to:Yolkai
what advantages does this have over RG BREAD?
If you add 2 integers and the result is too big, it's converted to a float.

Replying to:Yolkai
what advantages does this have over RG BREAD?
I'll take that as a yes.

Replying to:Yolkai
what advantages does this have over RG BREAD?
What random space?

Replying to:Yolkai
what advantages does this have over RG BREAD?
It says RG BREAD instead of RGBREAD

Replying to:Yolkai
what advantages does this have over RG BREAD?
red green bread