2x16 LCD Graphics :)

[Art]

You are kidding me, right?

Unbelievable graphics on this LCDs!!! Wow, Art. Supercalifragilisticexpialidocious!

Ioannis

Thanks

I always get that last little nice feature working AFTER the distribution

Happens every time on every platform.
I suggest, if you would like some cool new feature in a program you write,
that you upload a distribution, and give it away to the public.
Then within a day or two, you have changed the way you think about it,
and have a moment of insight Oh, and the implementation is a breeze also.

[Archangel]

CONGRATULATIONS ART:
You have been featured on Hackaday
http://hackaday.com/2013/10/16/teach...s/#more-105170

[Demon]

Congrats Art!

[andywpg]

Been following this thread with interest. Congrats on an awesome job AND your HackaDay feature!

[Art]

Thanks Guys
I finally joined their forum, they would have got it from that.
I've been watching H-A-D for years... certainly some interesting stuff.
My 144 LED game ended up there too back when I was doing that.

Anyways that'll be some nice traffic for ya!

It makes me wish I'd waited tho
I'll have to do a version 2.

[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?