Search results for:

Just in case anyone finds this interesting or would like to make suggestions:

Before trying to implement texture mapping, I decided to try lighting support.
For that I need to calculate each triangle's normal vector, to find out if it is facing towards the light.
This requires a bit of math: inverseLength = 1 / sqrt(x * x + y * y + z * z)
All of the code so far has been using 23.8 fixed-point math, and while the formula above can be implemented without floats, it'd be much slower.

Of course, we can't use math.h in compiledC code, so this is where the fun begins:

int __attribute__((naked)) v_invlength(int x, int y, int z) {__asm__ volatile(
        push {lr}
        VMOV.F32 S0, r0
        VCVT.F32.S32 S0, S0, 8
        VMUL.F32 S0, S0, S0

        VMOV.F32 S1, r1
        VCVT.F32.S32 S1, S1, 8
        VMLA.F32 S0, S1, S1

        VMOV.F32 S2, r2
        VCVT.F32.S32 S2, S2, 8
        VMLA.F32 S0, S2, S2

        VMOV.F32  s1, #1.0e+0

        VSQRT.F32 S0, S0
        VDIV.F32 S0, S1, S0
        VCVT.S32.F32 S0, S0, 16
        VMOV.F32 r0, S0
        pop {pc}
);}

(quotes and newlines omitted for clarity. It would've been nice if we could use raw string literals for inline assembly)

Unfortunately that doesn't work either because gcc really doesn't want to work with floats. To get around that, I assembled that function locally and replaced each instruction with the result as data:

int __attribute__((naked)) v_invlength(int x, int y, int z) {__asm__ volatile(
".short 0xb500 \n               \n"   // push	{lr}
".short 0xee00 \n .short 0x0a10 \n"   // vmov	s0, r0
".short 0xeeba \n .short 0x0acc \n"   // vcvt.f32.s32	s0, s0, #8
".short 0xee20 \n .short 0x0a00 \n"   // vmul.f32	s0, s0, s0
".short 0xee00 \n .short 0x1a90 \n"   // vmov	s1, r1
".short 0xeefa \n .short 0x0acc \n"   // vcvt.f32.s32	s1, s1, #8
".short 0xee00 \n .short 0x0aa0 \n"   // vmla.f32	s0, s1, s1
".short 0xee01 \n .short 0x2a10 \n"   // vmov	s2, r2
".short 0xeeba \n .short 0x1acc \n"   // vcvt.f32.s32	s2, s2, #8
".short 0xee01 \n .short 0x0a01 \n"   // vmla.f32	s0, s2, s2
".short 0xeef7 \n .short 0x0a00 \n"   // vmov.f32	s1, #112	; 0x3f800000  1.0
".short 0xeeb1 \n .short 0x0ac0 \n"   // vsqrt.f32	s0, s0
".short 0xee80 \n .short 0x0a80 \n"   // vdiv.f32	s0, s1, s0
".short 0xeebe \n .short 0x0ac8 \n"   // vcvt.s32.f32	s0, s0, #16
".short 0xee10 \n .short 0x0a10 \n"   // vmov	r0, s0
".short 0xbd00 \n               \n"   // pop	{pc}
);}

The result of this abomination is attached below.

It's a clock because that's simpler to start off with, and I wanted to make something animated to entertain my kids. They're two year olds, so they can't actually play games, but they do have fun watching and poking at the screen.

I do plan on making games out of this, though. I already have a ship being controlled by the gyro, but I'm not sure if I'm going to turn that into a full game or just a slightly interactive clock.

Awesome! Thanks!

I still haven't gotten around to benchmarking the drawing routines, but I've been experimenting and made a second watch face (also in the PR above). With JS being the bottleneck, benchmarking the triangle function wouldn't help. And maybe I'm going to need texture mapping for the next watchface. :)

I haven't tried the ArrayBuffer Graphics yet. In part because of the RAM it'd take up, and even if it's fast enough, it's better to access the buffer directly and let the CPU sleep a bit more, right?

Is adding a function to get the buffer an option? I'd sure prefer that instead of probing for it with peek8! :P

Indeed, working with that framebuffer isn't very easy, but that's part of the point for me. Having to deal with these weird details is fun.

My first attempt at this did involve an ArrayBuffer Graphics object. I still don't have a proper grasp of the Bangle.js code, but I was under the impression that it doesn't do a quick blit from that to the framebuffer. There's also the RAM cost.

Writing the code that finds the buffer in RAM was fun too, but of course it would be better to have a safe API that takes DMA into account. That said, I don't notice any tearing. Before writing to the framebuffer I call 'g.drawRect(-1, -1, 0, 177)' so that all of the rows get marked as dirty. I imagine this blocks until DMA is done?

I haven't checked the speed yet, nor am I sure of the best way to do so. What is the highest resolution timer I can use? Date.now()? I noticed that adding more ships makes the framerate drop, not because of the graphics code, but because of the javascript that controls the movement. Adding the equivalent amount of triangles as stars (controlled by C) has a much lower impact.

To better demonstrate what I wanted this for (from the PR linked above):

If you're on Chrome, it might help to press and hold the reload button, then click on "Empty cache and hard reload".

Since the BangleJS has a framebuffer, I expected its Graphics Object to extend the arraybuffer one, but that is apparently not the case as g.buffer is undefined and g.asImage("object") returns a copy.
Is there any way to access the framebuffer directly?

Edit: Couldn't find a good way to do it, did it anyway.

Also, I think 'LCD' was meant to be 'g' in https://www.espruino.com/Graphics (or does that not apply to the BangleJS2?):

On the few boards that do contain LCDs, there is a predefined variable
called 'LCD' (which is an instance of the Graphics Object).

Indeed, it's fixed! :)

Hello!

The IDE at https://www.espruino.com/ide/ doesn't load correctly, throwing the following error in the console:

Uncaught ReferenceError: exports is not defined
    at index.js:99995:23

Because of that, it seems all of the javascript is broken. The IDE at https://espruino.github.io/EspruinoWebIDE/ works OK though.