Mandelbrot viewer

#1

image

image

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
Meowbit hardware floating point support, or "how I spent an entire weekend adding two numbers together"
#2

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.

#3

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. :beer:

#4

Looks great! Could you add some intermediate rendering steps so that one can ā€œseeā€ the fractal being computed?

2 Likes
#5

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!

#6

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.

#7

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ā€¦

#8

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 .

#9

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?

#10

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.

#11

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.

#12

1%20(1)
1 (1).jpg2448Ɨ3264 2.07 MB
1%20(2)
1 (2).jpg2448Ɨ3264 2.13 MB
Pressing and holding buttons does seem to cause a response from the console eventually. i donā€™t know which buttons.

#13

Ah, ok, thanks for the confirmation.

#14

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?)

#15

@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.

#16

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.

#17

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

#18

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).

#19

Or to be more exact - the choice of number representation happens at runtime with the fast path assuming integers.

#20

Well, no easy way :slight_smile:

1 Like