3.5" Color LCD code example

[Demon]

Wow, he has PBP 6.0 !

Robert

[DaveC3]

Art

OK, I have another post using the same glcd as a analog clock http://www.picbasic.co.uk/forum/cont...t-Analog-clock

I don't don't recall any problems with the math. You can call any of the graphic routines in any sequence. You need to use a glcd that the display ram can be read. In this case I use the glcd in 8-bit parallel. If you SPI you can not read the display ram so objects get over written. Also with a display this big it is faster to run with parallel rather than SPI.

[Art]

Wow, he has PBP 6.0 !

Probably disappeared writing for chips we don't have either.

Art

OK, I have another post using the same glcd as a analog clock http://www.picbasic.co.uk/forum/cont...t-Analog-clock

I don't don't recall any problems with the math. You can call any of the graphic routines in any sequence. You need to use a glcd that the display ram can be read. In this case I use the glcd in 8-bit parallel. If you SPI you can not read the display ram so objects get over written. Also with a display this big it is faster to run with parallel rather than SPI.

I'll look at the clock, you must have got lines then.
I don't want to look at the LCD RAM, hopefully..
Take a look at my recent posts, the way I did double buffering
was set aside a RAM array of the capacity of a screen frame,
and draw (your circles etc.) to the RAM array, then copy the RAM array to display
RAM as fast as PBP can do it, then begin drawing the next frame to your RAM
array while the current frame is being displayed.
In that case the second buffer is the LCD's RAM.
(So no raster, and you can't see any drawing).

The big BUT is 320x240x3 colour components might be
asking a lot of RAM even of the most modern pics.
I'll need to be looking into that I guess.

However, there's no law saying the first buffer has to be the full size
of a screen frame, and cannot move around the physical screen.

[DaveC3]

Art

I have done the same with smaller GLCDs. This display is to large to fit it in ram (I think)

[Art]

I thought the RAM buffer would be a very tall order, and admittedly
have never looked past 16F pics yet, except dspics in C.
But I think that whatever you need to handle quickly such as display panels,
a wave, a meter, or clock, probably doesn't need to be colour,
or the full size of the screen, I think that whatever RAM can be afforded
can either follow the sprite around the display,
or the RAM buffer actually used to move the sprite around the display.



So you can either move the position the display buffer is drawn (X-70,Y-50),
or move the sprite within the buffer, or if it's a panel, just forget about it.
Then your panels shouldn't interfere with the full colour static display RAM
that can just sit there unless you overwrite it.

I assume you can write a data slab to the display from a variable coordinate (or video RAM) address.
I think I like the idea of cheating