Could do with better pan/zoom, and better color choices. Algorithm adapted (badly) from http://slicker.me/fractals/fractals.htm
Pan around with the arrow buttons. Zoom in with A. Zoom out with B.
5 Likes
I wonder what these colorful images could be used for? I clicked on the âshareâ link and get the image in MakeCode but , of what use is it? Just wondering.
Theyâre for looking at.
Does the main link not work for you?
Let me know if anything can be improved with my post, thanks. 
Looks great! Could you add some intermediate rendering steps so that one can âseeâ the fractal being computed?
2 Likes
Sounds like a fun idea. Effectively means breaking the draw() function apart, to make it a kind of resumable âcoroutineâ, to render at various stages of the inner loop, per pixel. Willing to give it a go, unless you want to try!
Edit: In the end, I just did it with a global variable - nice and dirty!
OK try this.
Press A+B together to animate the frame being drawn. Itâs a bit âflashyâ!
You can also now hold down the pan and zoom buttons, instead of repeatedly clicking them.
What I really want to do is give it a different color palette, or - even better - more colors. Is 16 color imposed by the hardware, or by the current pxt-arcade? I see the âDarker Duckâ example doing something with the screen colors themselves, a rectangle at a time, but itâs a bit hard to see exactly what itâs doingâŚ
Somewhat odd behavior in console but at least the image is recognized and installed by F401 processor, Iâll put a stopwatch on it and time how long it takes for the image to be loaded onto the TFT screen, Iâll guess 2 min. at least: Thanks for the program: https://youtu.be/e3mRu1oIGbg .
Quite interesting if there are such major differences between the hardware and the emulator I suppose. Is it just lack of computational power causing it to run at an insanely low framerate on-device?
You should expect the hardware to be 10s of times slower than your browser when doing floating point computation. The device doesnât have 64 bit floating point unit, so operations are implemented in software, which is ~100x slower. On top of that, the MCU on the hardware is ~50x slower than your computer.
Regular games work all right on hardware (similar speed to browser), since our generated JavaScript for the browser isnât very good.
I canât see any response at all to button press on console (s). It could be that A+B button press would do something, eventually, as they do on the computer monitor in simulator but I have not proven that to be true up to this point. Still working on it. I question whether F401 processor even acknowledges an input from buttons on the console for this program at this point in time; but it may prove to be that you can input in this case given enough time.
Pressing and holding buttons does seem to cause a response from the console eventually. i donât know which buttons.
Ah, ok, thanks for the confirmation.
So out of interest: 1) how does the device âknowâ when to do integer math instead of 64-bit floating point, when the variable type is just ânumberâ?; 2) is there any way to force 32-bit floating point (the chip has 32-bit FPU?)
@paul you can try to use our fixed point math numbers (see https://github.com/microsoft/pxt-common-packages/blob/5d7671f5d62383e45f55e33d9576a64a0c59e24c/libs/base/fixed.ts ). Those are used internally in the physics engine to stay fast at the cost of lesser numerical accuracy.
Hi - thatâs good to hear⌠I was going to start considering creating a fixed point lib of my own. Didnât realize there were some already!
However, the chip in question does have an FPU, albeit a single-precision one, unless Iâm mistaken. If the runtime could use that, it would likely be even faster than fixed-point.
OK, well, I quickly dashed through the code and converted everything to Fx8 representations:
Itâs now like molasses in the emulator, although it still âworksâ. I donât have hardware to test at the moment, but would be fascinated to see it running.
(Of course, now the code in this version is strictly Javascript, as there are no Fx8 blocks.)
Would still be interested if there is any method for getting the compiler to use 32-bit single-precision floats, to use the FPU on the device
There is currently no way to use the FPU. We may want to rethink that at some point though there are representation problems.
The runtime represents integers between -1b and 1b (roughly, really 2^30) as integers and everything else as boxed doubles. When the result can be represented as integer, it is (so 0.5+2.5 will be represented as integer and 1/3 will not).
Or to be more exact - the choice of number representation happens at runtime with the fast path assuming integers.
Well, no easy way 
1 Like