For Loops discussion

Zero Division

Maybe I should also say: it makes sense that there would be a performance hit if the type of the variable "j" were to change inside of the loop (making that go fast involves a VM optimization which Nintendo might not allow, namely polymorphic inline cacheing.) But if the variable has already been allocated within the loop's lexical context and its type doesn't change in the program, it should just be assigned to, rather than being re-initialized.

Jongjungbu

That’s not how a for loop usually works. Each iteration is unique. What you suggest is the interpreter (or compiler in other cases) treats the first iteration as a unique one where variables are initialized and declared. All further loops it should ignore any new variables and check if that variable already exists solely in a previous for iteration. That would be nice but contrary to how iterations are normally handled.

Zero Division

@Jongjungbu said in Hints and Tips:

That’s not how a for loop usually works. Each iteration is unique. What you suggest is the interpreter (or compiler in other cases) treats the first iteration as a unique one where variables are initialized and declared. All further loops it should ignore any new variables and check if that variable already exists solely in a previous for iteration. That would be nice but contrary to how iterations are normally handled.

I don't see the point of doing it the way it is currently unless you want programs to run more slowly. If I'm guessing right, we aren't really talking about one variable. It sounds like the entire block context is being discarded and rebuilt every time through the loop. That doesn't seem right to me, at least not in a dynamic language. There's clearly an available optimization here, because this:

0 to: 19999 do: [ :i |
    | j |
    j := 1
]

takes about the same amount of time to run as

| j |
j := 1
0 to: 19999 do: [ :i |
    j := 1
]

...in my Smalltalk environment, and both are just garden variety Smalltalk for loops. So I know I'm not crazy. Both consistently execute between 0.00005 and 0.0001 seconds on my machine; the variance is about the same for both, and are mostly caused by other things vying for cycles, like my OS.

Jongjungbu

What you don’t see behind the scenes (what is more obvious in other languages) is in the “for loop” you would see “int j = 1” in the loop block.
Then in the second “for loop” iteration, this would be an error because you’ve already declared and initialized this variable as an integer equal to 1. You can’t do it again, unless you treat each iteration of the loop as a new scope.

faz808

This is very fast - but can it be improved on?
BTW, see if you can spot the two syntax errors...

for y =  1 to 10 loop
 clear()
 for I = 1 to 100000 loop
  point1 = {random(gwidth()),random(gheight()}
  point2 = {random(gwidth()),random(gheight()}
  col = {random(101)/100,random(101)/100,random(101)/100,1}
  line(point1,point2,col)
 repeat
 update()
repeat
sleep(2)

I'm having loads of fun with FUZE. Thanks.

Discostew

@faz808 Missing the close parenthesis on your use of random on the 2 points.

As far as speeding it up, you currently have your points and color variables created each iteration of I. Just throw their creation outside of the loops.

pianofire

@Discostew Just timed this and it improves performance from 5.6 secs to 3.4

faz808

In the mid eighties Elite for the Spectrum home computer was released. This very successful space game used a simple line routine to draw a dozen or so space ships. I can remember it being a bit jerky, but as it incorporated hidden line removal and only took up about 40 kB of Z80 code this was a bit of an achievement. The secret to hidden line removal is to define all your 3d points in a clockwise direction. The rear facing polygons will appear anticlockwise and a simple calculation will enable you to jump over the drawing routine and only plot the clockwise faces.
I've already written a simple spinning wire cube in qbBasic and it runs ok. How easy it will be to convert the qb code to FUZE I'm about to find out. But it will certainly keep me out of mischief for a while!

pobtastic

@faz808 Check out this Pico-8 game video

At some point I might try and make a demo similar to this, I'm sure if Pico-8 can do it then we certainly can!

Spacemario

@pobtastic Holy buckets is that cool! I love the faux reflection effect. I totally bet Fuze can do something like this.