2x16 LCD Graphics :)

[Art]

Changes for LC2D Version 2 - 18/10/13

Base code:
Reduced program memory, and RAM consumption
(approximately ten more bytes of RAM are freed).
This leaves more RAM in BANK0 for the user program.
Performance win on base code
(first version is still on the site for comparison).
When the demo program is removed,
there's much more resource for your program.

Demo User Program:
Extra resource freed by improved base code is consumed
by the new demo. Now has fifteen demo sections!
The first demo sections are identical, except that the first
demo section inverts the LCD on it's first cycle for LCD test.
The new demo sections expand on a trick appearing to
control the entire LCD display when run on a 2x16 LCD.
Fixed graphic invader animation frame B sprite (legs).

Classic Rolling Odometer Effect
One of the new demo sections is the rolling odometer
effect that also moves around the display.
It looks like a penalty, but is not. It's delayed because it
is the most prone to messing up the display with lag trails
when run on slow LCDs such as the one in the video.
The user program doesn't have to move it around,
or delay any sprite drawing routines.
I ran out of memory in the process of making it able
to reverse direction properly for counting backwards.
Currently, the variable must be incrementing by one.

New Notes:
Pic run at 8MHz telling PBP compiler it's running at 4MHz
results in only 600ms pause time for LCD start up delay.
PBP manual suggests PAUSE 1000 delay to accomodate
slower starting LCDs. If your LCD doesn't start, change to
PAUSE 2200 before compiling the program, or insert the
pic into the socket after powering the circuit with the LCD.

Sloppy bounds checking on demo user program demonstrates
crash proofing in base code. The user program is allowed to
draw off screen. Base code does not check bounds on the
individual X,Y coords, rather that their calculated destination
in the first frame buffer is within bounds of the array.
Crazy shape or line drawing could still have consequence.
I don't know what those routines will do in unusual circumstances.

http://www.freewebs.com/defxev/LC2D.htm

Enjoy

[Art]

I had to write an iPhone simulator App to do the vector rotation on the 3D cube but got it:



It takes sixteen bytes per frame to store a list of coordinates in lookup tables
not compressed in any way. The pic still has to look up the points, and draw lines between them.
This makes a more simple to understand user program.
Now it's produced, it's very simple. The pic program just looks up sixteen bytes and
draws lines between those coordinates for every frame. I took out anything fancy.

If you calculate vector rotation on another platform is it still 3D graphics?

[Art]

3D Point Rotation Demo:




Who said you only get eight custom characters?

LCD Freedom - World's First HD44780 POV!

[spcw1234]

Wow, awesome job Art! Quite impressive!

[Art]

Thanks
It took a 20MHz clock to control the entire display, with all four cubes different,
but I could make videos forever
Since the video framerate is not synced to the pic's clock in any way,
and therefore the LCD backlight strobe frequency, it looks better here than the video comes up.

[Art]

Normally, Noritake will provide you with a dot matrix VFD sample to play with,
but only if you live in US or Canada:

http://www.noritake-elec.com/evalkit-sample.php

That's really quite nice, so ppl should be aware of that.

Suspecting that POV will work great with VFD, I promised a great demo including
their logo, in return for them sending me some 2x16 character modules.
They have replied with a suggestion display which is a HD44780, so it looks good

I don't think I'm finished with them.
I think it's possible to do greyscale graphics on a monochrome dot matrix VFD.

[sougata]

I didn't find the source for your AWESOME 2D LCD Graphics on the link you provided. I do not do PBP much nowadays but your demo is so cool, I want to try it out.
Cheers