GLCD Megademo :)

[Art]

Hi Guys :)
This isn’t in PBP, so off topic, but if you remember the graphics I did with character LCDs,
I started on a dsPic with 128x64 GLCD a week ago, and did a multi part demo :D

https://www.youtube.com/watch?v=bj_9MKgnPyo

[mark_s]

Art, that's really impressive.

Are there any links to code? I would like to understand frame buffering techniques.

Thanks

[Jerson]

Very nice. Good frame rates too.

[Ioannis]

Great! Very fast indeed! 5* Art.

How do you rotate 3d objects?

Ioannis

[Art]

Hi, Thanks :)
It’s written for the public, but that’s not a promise yet.
It does go: user program, library, hardware driver... but it’s still less than a week into the software part.

Jerson, I want to mux the 8 data lines with a shift register next time, and slow it down to gain 6 pins,
but I don’t think it will suffer much. Part of the reason the final thing will be different, or configureable.

Ioannis, To rotate the objects, every pixel in the object has to be rotated on one axis or another.
Only one axis for 2D rotation. For the cubes, I was able to do that on the character display in PBP
because the points for the 3D cube were pre-generated on another platform first.

To draw the cube you only have to rotate it’s 8 points, and draw lines between the rotated points, so it’s not very costly.
The code to rotate one point in C reads like BASIC. The x,y input data is destroyed, and the x,y value a that end is the rotated value.
Rotated around a centre point approximation for 128x64 display. rotation is an integer input in degrees 0-359.



double d2r = 0.0174532925199433; // (PI / 180.0)
long double theta;
long double thetab;
int rotation;
int xx;
int yy;
int xnew;
int ynew;
int rx;
int ry;
int ox = 64; // screen centre pixel coordinates
int oy = 32; //


theta = rotation; // pre calculation
thetab = 360 - theta;
thetab = d2r * theta;

xx = x; yy = y;
rx = xx - ox; ry = yy - oy;
xnew = cos(thetab)*rx - sin(thetab)*ry;
ynew = sin(thetab)*rx + cos(thetab)*ry;
xnew = xnew + ox; ynew = ynew + oy;
x = xnew; y = ynew;


That was the only reason to use a dsPic and C30 for this.
The display isn’t written in sequential horizontal lines, so everything else in the software is
bit manipulation which would all be much better done with PBP/asm with a slower micro.

[Art]

I can’t seem to edit my first post. It was updated enough that I didn’t like the older one up on YouTube, so here’s the new link:

https://www.youtube.com/watch?v=87ayBuvcvn0

[technotronix]

Interesting.
Appreciate for sharing.

[Art]

I don’t really know if this one has been done, but tonight I got a third colour by using a second frame buffer,
and toggling between the two for every frame. The framebuffer for the grey colour also has the black drawn on it,
so the black colour ends up 100% duty cycle, and the grey, 50%.

http://img.photobucket.com/albums/v186/ArtArt/Tri_Colour_zps3efxvrxy.png