Hello.
Is it possible that 128x64 KS0108 based GLCD is to slow for running tetris game? Code is from AVRlib.
Rendering is so slow that you can actually see pixels turning on/off at very low speed (refresh every 300ms).
Platform: AVR core running at 16MHz
Thank you for your answer!
Do you redraw the whole screen every time?
128x64 pix is only 1K. I'd draw into a 1K ram buffer in the AVR, then copy 1K to the LCD. I bet you can redraw the screen faster than the lcd will respond. Shoot for redraw 5 times a sec and see what it looks like.
madid87 and I are working on this together.
@jayjay1974
No, I only clear pixels that I need, and then draw the "brick" again (displaced). I do this cca. 5 times per sec and it seems to me that LCD doesn't have enough time to turn the pixel on completely. madid87, however, thinks that it should work.
@bobgardner
We don't really have too much memory to waste, but that's not the problem. I think you're right when you say that I can redraw the screen faster than lcd can respond.
Here's a silly thought - I ran into this using a 64*128 display - and discovered I was using the internal 1MHz clock, not the 8MHz I had intended. :roll:
Neil
128x64 pix is only 1K. I'd draw into a 1K ram buffer in the AVR, then copy 1K to the LCD. I bet you can redraw the screen faster than the lcd will respond. Shoot for redraw 5 times a sec and see what it looks like.
Heh, that wasn't my question :)
Of course the AVR is fast enough. LCD is extremely slow, is this normal for this type of LCD?
Thank you !
I have a 16 bit high character text scrolling on a display with KS0108 chip. Two different routines scroll either vertical or horizontal.
Have found on/off time for pixels annoyingly slow so the text get blurry if you scroll to fast. When I compared datasheet for my LCD to another one same size also using KS0108 rise/fall time was double as fast so maybe LCD screens are different in speed.
Hello to Madid and Pylo. I searched google for 'tetris c source' and saw one with a lot of german comments, but it seemed to be for a pc, because there was RGB and file io and some other stuff that would have to be changed for an avr. A lot of others were in C++. Did you guys write your own tetris, or modify something you found? I might try to get it to run on this 160x128 lcd I have here but of course it is only 1 color...
I think the LCD is simply too slow :( The panel itself, not the driver chip.
I think the LCD is simply too slow :( The panel itself, not the driver chip.
@bobgardner
We write our own stuff. I am using existing libs ("drivers") for this LCD, though.
Anyway, thanks for replys.
I've been using a similar device. It takes around 8mS to copy a 1k memory buffer to the display - any faster and I have issues with the display controller not being fast enough.
I'd suggest you isolate the code that does the drawing vs code that talks to the display. Then do some timing measurements to see what is taking the time. But I can say the display controller is none too speedy.
I think the LCD is simply too slow :( The panel itself, not the driver chip.
It'll depend on the type of LCD technology the display is composed of. But if it's Super Twist Nematic (STN) as many of them are then the pixel switching latency is typically 200ms-250ms so making more than 4 or 5 frame updates per second does not make much sense as the pixels will not switch quickly enough.
I designed and was the project manager for this and also wrote the Tetris-like program on it:
http://en.wikipedia.org/wiki/Ams...
It too had a ~200ms STN screen and while it was quite possible to play the Tetris we implemented on it the fact is that it did look kind of "blurry" because these type of screens don't really lend themselves to fast movement. (which is part of the reason we chose to do Tetris on it and not something else as the movement, on the whole, is actually quite slow as 5 frames per second doesn't hinder the gameplay too much). We actually set out to do a "gameboy style" platforms and ladders game (thankfully not with a plumber or a hedgehog) but the latency of the display was just too much for the sprite movement so we abandoned that idea and went for Tetris in the end.
Cliff
