Matrix Orbital Corp

Hello!

Im looking for the best approach to draw graphics.
Here is what I did: I have a signal (I made a sine wave for simplicity but it can
be anything else). I want to draw it with line segments, so what I'm using is
BEGIN LINES and then for each segment, I enter its 2 extremity points.
See picture. The problem is that it takes huge amounts of data, because I enter every point
twice. This means that for an array of 640 values, I need to draw 640 segments,
each of which need 2 points which is 4 coordinates of 2 bytes each.
5K bytes only for one curve. And if I need an oscilloscope-like display with n curves,
then I have to multiply everything by n, and I don't even know if it's possible to have
so many drawing instructions due to FT815's internal buffer limitation.
Is there a kind of graphic mode that can make things a little bit easier?
For example a kind of LineTo function, that starts from current point and goes
to the next one?

What would be the best strategy for drawing graphics?

Thanks for any hint!

R.

I faced a similar problem and explored many approaches.
What I settled on was to create an empty image in gRAM and to directly write the pixels of the curve into the image at the appropriate addresses. For some image formats, this is only one byte/pixel, so it can be quite fast. Note that changes made in this way will update on the screen immediately--no special action required.

I have been very happy with this approach.

Why not use LINE_STRIP ? then you would just need to pass the coordinates of each vertex and the EVE engine would join them up, ie 4 bytes per point.

Have you read the programmers guide ?
https://brtchip.com/wp-content/uploads/ ... _Guide.pdf

or looked at the sample projects ? https://www.ftdichip.com/Support/Softwa ... #Example13

Turby wrote: Tue Dec 08, 2020 3:57 am Why not use LINE_STRIP ? then you would just need to pass the coordinates of each vertex and the EVE engine would join them up, ie 4 bytes per point.

Have you read the programmers guide ?
https://brtchip.com/wp-content/uploads/ ... _Guide.pdf

or looked at the sample projects ? https://www.ftdichip.com/Support/Softwa ... #Example13

That is a good approach for line graphs, where relatively few points are required.

But, OPs example involves a continuous curve, which requires a LOT of points to be sent. This gets expensive fast.

This means that for an array of 640 values, I need to draw 640 segments,
each of which need 2 points which is 4 coordinates of 2 bytes each.
5K bytes only for one curve.

But, OPs example involves a continuous curve, which requires a LOT of points to be sent. This gets expensive fast.

Well, with a line-strip, and I was to suggest the same, this is only half of what the OP calculated.
640 segments are 641 coordinates or 2560 bytes for one curve.
The next step would be to reduce the resolution, using half the points does not make much of a difference.
The "curve" in the attached images is using a line-strip with 64 points.
There is annother issue though, VERTEX2F is a badly designed command that can take a lot of time to process.
Shifting the coordinates into position is the issue.
Using a pre-calculated array of 32 bit values with 0b01xx xxxx xxxx xxxx 0000 0000 0000 0000 would speed things up by a lot.
Note that bit 15 actually is bit 0 of the x-coordinate, setting this bit to a fixed '0' allows a much simpler copy/paste operation:
pixel_array[counter] = (x_array[counter] & 0xfff000) | y_array[counter];
The compiler should not even bother to mask out the lower 16 bit and only write the y-word directly.
With VERTEX_FORMAT set to 1 this still could be used for every x-pixel but the y-coordinate would need to be multiplied by 2.

Well, lots of ways to do it. Of course you can save bytes by reducing resolution, but that is true for any technique.

But, the 'write to RAM" approach is pretty empowering. For one thing, you can do local updates anywhere in the image without having to resend the whole curve. Plus you can use any image as a canvas. And, of course, you have all the image scaling and rotation operations at your disposal.

Maybe it violates the zen of display-list displays, but it works very well in certain situations.

Hello everybody!

Thanks for all your replies, sorry for the delay.

Why not use LINE_STRIP ?

Mostly because I didn't know about its existence. Yes, apparently line strip is the way to go for me.
Drawing directly to RAM would be (I think) more expensive because I have to draw segments,
not points. For the above sine wave, it's almost the same because the sine slope is limited, but
in case there are some almost vertical parts, then I will have to draw segments pixel by pixel
between 2 points. Therefore I would need to transmit a lot of data, in most cases more than
with the line strip method. And beside this, if I want to write 2 non-contiguous pixels, I think I
would have to transmit them with one 32-bit address each, which would quite eat resources.

Anyway, thanks for your comments!

R

Update: It took me about 5 minutes to modify the code, from standing start. Plug the emulation
probe, start the IDE, modify the code (from LINES to LINE_STRIP), compile, run. Many thanks!

Example of using LINE_STRIP https://brtchip.com/wp-content/uploads/ ... VM800P.pdf

Another one to try (not that I have) is the BARGRAPH option when drawing a BITMAP, will need to generate two bitmaps with the Y offset slightly reduced in order to produce a line when two bitmaps are merged. You are limited to 256x256 bitmaps, but this can be scaled as required.

See page 99 of https://brtchip.com/wp-content/uploads/ ... _Guide.pdf

I would be interested to know if this approach works and how efficient it is.