LB5-347 AND

[Rod]

This code runs on 4.5.1 but halts on the line: col = (r(x) + g(x) + b(y)) and 255 "message not understood #bitand"


WindowWidth = 400 'DisplayWidth
WindowHeight = 400 'DisplayHeight

PI = 3.141593

dim r(WindowWidth)
dim g(WindowWidth)
dim b(WindowWidth)
dim color(2, 256)


graphicbox #1.gb, 0, 0, 400, 400
open "Plasma" for graphics as #1
#1 "trapclose [quit]"

#1.gb "down ;fill black"
for x = 1 to WindowWidth
   r(x) = sin(x / (128))* 256
   g(x) = sin(x / (64)) * 128
   b(x) = sin(x / (32)) * 64
next x

for i = 0 to 255
   color(0,i)=  abs(int(128 - 127 * sin(i * PI / 32)))
   color(1,i)=  abs(int(128 - 127 * sin(i * PI / 64)))
   color(2,i)=  abs(int(128 - 127 * sin(i * PI / 128)))
next i

for x=0 to WindowWidth
   for y = 0 to WindowHeight
               col = (r(x) + g(x) + b(y)) and 255
               #1.gb "color ";color(0,col);" ";color(1,col);" ";color(2,col)
               #1.gb "set ";x;" ";y
   next y
next x

wait

[quit]
close #1
end

[fretinator]

That seems like code that would be very difficult to handle in a cross-platform language. Taking a potentially 32-bit or 64-bit floating-point number and using a mask to retrieve the "last" four bits, which might run on a little-endian vs big-endian system.

[tsh73]

Likely same problem as
lb5-347 Win 10. AND on floats errors (Unhandled exception)
Adding INT helps
col = int(r(x) + g(x) + b(y)) and 255

(and it DOES work faster then LB4!)

---

EDIT
actually, on my machine about 2x faster then LB4

And if converted to LB5 syntax
 #1.gb color(color(0,col),color(1,col),color(2,col))
 #1.gb set(x,y)
it goes more 30% faster.

[Rod]

fretinator Yes, I should find a new way to draw plasma. It is old code rehashed and rehashed.

[Carl Gundel]

Mar 1, 2019 11:19:27 GMT -5 fretinator said:

That seems like code that would be very difficult to handle in a cross-platform language. Taking a potentially 32-bit or 64-bit floating-point number and using a mask to retrieve the "last" four bits, which might run on a little-endian vs big-endian system.

It might be tricky at the assembly language level, but even at the level of C the problem goes away because it manages the endian-ness for you.

[tsh73]

Program works high-level (not like writing double to memory and reading bytes from it to make Int)
float sin() - scaled - taken lower part (AND 255).
Somewhere it should be truncated to Int but that's all.
As well could use MOD for that.

Nothing here could depend on endianness, at all.

[fretinator]

I would disagree slightly on C being Endian agnostic. It usually is with integers. For instance, shift operator dividing/multiplying by 2. But even with integer, the size of the integer can matter, and truncating a 32-bit integer to 16 bits can "chop" off the wrong end on some platforms. The really trouble starts with signed numbers and floating point numbers, which becomes very implementation dependent. Anyhoo, converting to integer (especially if always greater than 0) seems like the safer option to me. Using a bit operator is riskier in by opinion. OK, there's my $0.02.

[Rod]

Yes, as I have said, my code was old and crap. I am browsing lodev.org as I type looking at int() ways to create plasma.

[fretinator]

Old and Crap - I resemble that remark!