bytes and ints frustration!!

General Discussions
#1

So I am trying to adapt some c++ code into java, because I wasn’t unable to find an example in java for what I wanted.

Basic problem
no unsigned bytes in java
byte = -127 to 127
unsigned byte would be 0 to 255

so I use int instead, which is fine

except, when I try passing it to the GL11.glTexImage2D
which requires a bytebuffer, which I can convert bytes to bytebuffer no problem.

So basically what I am trying to accomplish is converting a int to a byte
all the examples I find are shifting a single byte into a 4 long array of a byte. for the added potential values
all my values of int are 0 to 255, so I dont need the added values.

but I need to shift my int down -127 so it falls into proper range of byte, then convert to byte.

Any suggestions?

All online things show int to byte arrays, though I just need an int to byte

or a conversion process that supports int arrays, an easy way to discard the unnecessary 0s of the byte array[][]

Sorry for the hugely wordy/messy example.


int[] pix = new int[250000];

// blah blah random shit

//each value of pix is between 0 and 255


ByteBuffer bb = ByteBuffer.allocate(pix.length);		
bb.put(pix);
GL11.glTexImage2D( GL11.GL_TEXTURE_2D, 0, GL11.GL_RGBA, 256, 256, 0, GL11.GL_RGBA, GL11.GL_UNSIGNED_BYTE, bb);   //for lwjgl,

//plan B, rewrite the whole thing to use bytes -127 to 127(from the start), which requires a painfully manual modification of a huge reference table :frowning:

///edit
So one possibility?

int[] pix = new int[250000];
byte[] b = new byte[250000];

//large for loop…

b[value]=(byte) (pix[value]-127);

#2

Casting already does this for you:

int x = 0…255;
byte b = (byte)x; // -128 … +127, this is not done through subtraction, but a side effect of how the values are represented in bits.
int y = b & 0xFF; // back to 0…255

#3

???

I probably miss the point but… in case of

int i=-100;
byte b=(int)i;
//now b=-100 and is a byte

EDIT :
ha ok !

yes as mentioned by riven, in “byte format” 255 == -1 this is the same representation in bit => 11111111b

#4

Just think of it like this: when casting to a byte, we take the least significant 8 bits of the int, and put it in the byte, as is. Due to two-complement interpretation of the byte, you end up with negative numbers if the upper bit (of the 8) was 1.

hence:

(byte)-100 == -100
(byte)+156 == -100

other way around:
+156 & 0xFF = 156
-100 & 0xFF = 156

#5

the problem with the (byte) was

sure
int i = 50;
byte b = (byte) i;

b is 50

but if
int i = 128;
byte b = (byte) i;

b is -127 so that when i is 254, b is -1

I also tested i is 256 and b i think turned out to be 1 ? (I am not at same computer anymore, so from memory may be slightly off)
it wraps it around the wrong way, where I need my int = 0, to be my byte = -127
But anyways, I went with the (byte) and a subtract 127 method, which led to other problems I need to figure out though.

Thanks all!!

#6

[quote]but if
int i = 128;
byte b = (byte) i;

b is -127 so that when i is 254, b is -1
[/quote]
:o

yes ??

128 should give -128
254 should give -2

#7

There are two options:

  1. you’re doing it wrong, again and again
  2. everybody else never noticed this bug you speak of

Pick one.

I explained it already, and if you’re still claiming that (byte)256==-1, no matter how vague your memory is, it’s starting to get rather silly.

Let me spoon feed you:
System.out.println((byte) 256); => “0”

Why? Just as I said: the 8 least significant bits are taken from the int.
256 == 00000000 00000000 00000001 00000000

You can clearly see the lowest significant bits (righthand side) are zero, no way this yields 1.

#8

I never meant/said it was a bug, I meant the way it was implemented behaved differently then what I thought my goal was.

(byte)-100 == -100
(byte)+156 == -100 this part just threw me off, for how the 156 and 100

I apologize. I got it now. Thank you

Also, this thread should probably be moved to “Newbie & Debugging Questions”
My mistake on wrong subforum :confused:

#9

You really sure you don’t want int=0 to be byte=0?

#10

:-\ become hard…

you got input from 0 to 255 and wanted them to be in range -128 to 127 ?

byte b=(byte)(inputInt-128);

no ??

#11

He wanted it to be in the range -128…+127 for the wrong reason. Nobody should do that, if the goal is to convert between ints and bytes, simply cast & mask.

#12

The problem is solved for me, so I am no longer personally needing anything further on this.

Although its no longer an issue, because DzzD asked and because of a little confusion earlier.

int[] ext_data = {0,50,75,100,125,150,175,200,225,255};
		
		byte[] b = new byte[ext_data.length];
		
		
		for(int i=0;i<ext_data.length;i++){
			b[i]=(byte) ext_data[i];
		}
			
		for(int i=0;i<ext_data.length;i++){
			System.out.print(ext_data[i] + " ");
		}
		System.out.println();
		for(int i=0;i<ext_data.length;i++){
			System.out.print(b[i] + " ");
		}
		for(int i=0;i<ext_data.length;i++){
			b[i]=(byte) (ext_data[i]-128);
		}
		System.out.println();
		for(int i=0;i<ext_data.length;i++){
			System.out.print(b[i] + " ");
		}

i[] = 0 50 75 100 125 150 175 200 225 255 // original data example (I don’t have control over this)
b[] = 0 50 75 100 125 -106 -81 -56 -31 -1 // a direct (byte) casted
b[] = -128 -77 -52 -27 -2 23 48 73 98 127 // is what I had wanted

The importance wasn’t on a direct 10=10, but the importance of keeping the data in the same relativity of the number before/after it was the same. A direct cast causes a hiccup in the middle that I couldn’t have.

#13 

         for (int i = 0; i < 256; i++)
         {
            System.out.println(i + " => " + ((byte) i) + " => " + (((byte) i) & 0xFF));
         }


0 => 0 => 0
1 => 1 => 1
2 => 2 => 2
3 => 3 => 3
4 => 4 => 4
5 => 5 => 5
6 => 6 => 6
7 => 7 => 7
8 => 8 => 8
9 => 9 => 9
10 => 10 => 10
11 => 11 => 11
12 => 12 => 12
13 => 13 => 13
14 => 14 => 14
15 => 15 => 15
16 => 16 => 16
17 => 17 => 17
18 => 18 => 18
19 => 19 => 19
20 => 20 => 20
21 => 21 => 21
22 => 22 => 22
23 => 23 => 23
24 => 24 => 24
25 => 25 => 25
26 => 26 => 26
27 => 27 => 27
28 => 28 => 28
29 => 29 => 29
30 => 30 => 30
31 => 31 => 31
32 => 32 => 32
33 => 33 => 33
34 => 34 => 34
35 => 35 => 35
36 => 36 => 36
37 => 37 => 37
38 => 38 => 38
39 => 39 => 39
40 => 40 => 40
41 => 41 => 41
42 => 42 => 42
43 => 43 => 43
44 => 44 => 44
45 => 45 => 45
46 => 46 => 46
47 => 47 => 47
48 => 48 => 48
49 => 49 => 49
50 => 50 => 50
51 => 51 => 51
52 => 52 => 52
53 => 53 => 53
54 => 54 => 54
55 => 55 => 55
56 => 56 => 56
57 => 57 => 57
58 => 58 => 58
59 => 59 => 59
60 => 60 => 60
61 => 61 => 61
62 => 62 => 62
63 => 63 => 63
64 => 64 => 64
65 => 65 => 65
66 => 66 => 66
67 => 67 => 67
68 => 68 => 68
69 => 69 => 69
70 => 70 => 70
71 => 71 => 71
72 => 72 => 72
73 => 73 => 73
74 => 74 => 74
75 => 75 => 75
76 => 76 => 76
77 => 77 => 77
78 => 78 => 78
79 => 79 => 79
80 => 80 => 80
81 => 81 => 81
82 => 82 => 82
83 => 83 => 83
84 => 84 => 84
85 => 85 => 85
86 => 86 => 86
87 => 87 => 87
88 => 88 => 88
89 => 89 => 89
90 => 90 => 90
91 => 91 => 91
92 => 92 => 92
93 => 93 => 93
94 => 94 => 94
95 => 95 => 95
96 => 96 => 96
97 => 97 => 97
98 => 98 => 98
99 => 99 => 99
100 => 100 => 100
101 => 101 => 101
102 => 102 => 102
103 => 103 => 103
104 => 104 => 104
105 => 105 => 105
106 => 106 => 106
107 => 107 => 107
108 => 108 => 108
109 => 109 => 109
110 => 110 => 110
111 => 111 => 111
112 => 112 => 112
113 => 113 => 113
114 => 114 => 114
115 => 115 => 115
116 => 116 => 116
117 => 117 => 117
118 => 118 => 118
119 => 119 => 119
120 => 120 => 120
121 => 121 => 121
122 => 122 => 122
123 => 123 => 123
124 => 124 => 124
125 => 125 => 125
126 => 126 => 126
127 => 127 => 127
128 => -128 => 128
129 => -127 => 129
130 => -126 => 130
131 => -125 => 131
132 => -124 => 132
133 => -123 => 133
134 => -122 => 134
135 => -121 => 135
136 => -120 => 136
137 => -119 => 137
138 => -118 => 138
139 => -117 => 139
140 => -116 => 140
141 => -115 => 141
142 => -114 => 142
143 => -113 => 143
144 => -112 => 144
145 => -111 => 145
146 => -110 => 146
147 => -109 => 147
148 => -108 => 148
149 => -107 => 149
150 => -106 => 150
151 => -105 => 151
152 => -104 => 152
153 => -103 => 153
154 => -102 => 154
155 => -101 => 155
156 => -100 => 156
157 => -99 => 157
158 => -98 => 158
159 => -97 => 159
160 => -96 => 160
161 => -95 => 161
162 => -94 => 162
163 => -93 => 163
164 => -92 => 164
165 => -91 => 165
166 => -90 => 166
167 => -89 => 167
168 => -88 => 168
169 => -87 => 169
170 => -86 => 170
171 => -85 => 171
172 => -84 => 172
173 => -83 => 173
174 => -82 => 174
175 => -81 => 175
176 => -80 => 176
177 => -79 => 177
178 => -78 => 178
179 => -77 => 179
180 => -76 => 180
181 => -75 => 181
182 => -74 => 182
183 => -73 => 183
184 => -72 => 184
185 => -71 => 185
186 => -70 => 186
187 => -69 => 187
188 => -68 => 188
189 => -67 => 189
190 => -66 => 190
191 => -65 => 191
192 => -64 => 192
193 => -63 => 193
194 => -62 => 194
195 => -61 => 195
196 => -60 => 196
197 => -59 => 197
198 => -58 => 198
199 => -57 => 199
200 => -56 => 200
201 => -55 => 201
202 => -54 => 202
203 => -53 => 203
204 => -52 => 204
205 => -51 => 205
206 => -50 => 206
207 => -49 => 207
208 => -48 => 208
209 => -47 => 209
210 => -46 => 210
211 => -45 => 211
212 => -44 => 212
213 => -43 => 213
214 => -42 => 214
215 => -41 => 215
216 => -40 => 216
217 => -39 => 217
218 => -38 => 218
219 => -37 => 219
220 => -36 => 220
221 => -35 => 221
222 => -34 => 222
223 => -33 => 223
224 => -32 => 224
225 => -31 => 225
226 => -30 => 226
227 => -29 => 227
228 => -28 => 228
229 => -27 => 229
230 => -26 => 230
231 => -25 => 231
232 => -24 => 232
233 => -23 => 233
234 => -22 => 234
235 => -21 => 235
236 => -20 => 236
237 => -19 => 237
238 => -18 => 238
239 => -17 => 239
240 => -16 => 240
241 => -15 => 241
242 => -14 => 242
243 => -13 => 243
244 => -12 => 244
245 => -11 => 245
246 => -10 => 246
247 => -9 => 247
248 => -8 => 248
249 => -7 => 249
250 => -6 => 250
251 => -5 => 251
252 => -4 => 252
253 => -3 => 253
254 => -2 => 254
255 => -1 => 255

No hiccups in the middle…

#14

^^ Riven is correct. ^^

127 => 127 => 127
128 => -128 => 128

I had previously thought that would cause problems for the glTexImage and not have a smooth transition for a bumpmap/heightmap

#15

Just for completeness, someone might have needed to explain, that signed numbers are encoded in two’s complement:http://en.wikipedia.org/wiki/Two’s_complement