|
|
| Submitted By: thepenguin77 Date: December 03, 2011, 11:29:15 pm Views: 1374 | |||
| Summary: If you want flickerless grayscale, you will have to understand everything in this tutorial, even if you don't learn it from me. | |||
With my recent work on Chess, people have been asking me how I make my grayscale so perfect. So here is a tutorial! First, a little background, most of it can be read in this topic. A while ago, I made a program that displayed 16 level grayscale pictures. It worked pretty well, but it was clearly not flickerless, it had major scrolling patterns and some spots literally flickered. Then I thought, if I can do 16 with 120 refreshes per frame, why not do 64 level grayscale with 100,000 refreshes per frame. This was accomplished using z-addressing and I put 1 pixels in the first column, 2 in the second, 3 in the third, and so on until the screen was full. Then I scrolled that at 100,000 fps. What I noticed was that at certain frequencies, the images would slow down, stop, then reverse direction and go back into oblivion. After a little bit of playing with it, I figured out that the LCD actually has a refresh rate. And that rate is 60Hz. This little refresh rate is what causes all of the problems with the LCD. Lets say that you quickly change the screen color, if you've used your calculator long enough, you know that there is a diagonal line going up your calculator for a split second while it is clearing. This is caused when you and the LCD driver are updating the screen at the same time. The LCD driver has two parts, and each part works independently of the other. First you have the LCD ram, which is just like regular ram. And then there is the LCD driver which updates the screen 60 times per second, at a speed of about 100 pixels / (1/60 second) from top to bottom. In common practice, the LCD ram is filled one column at a time, starting at the left, and working your way across. This operation takes about 1/120 second. What can happen is that while you are updating the LCD ram, the LCD driver decides that it is going to start displaying the screen. It displays 1 row at a time, and as it falls down the rows, it displays whatever is currently in ram. So you can see that if you are updating the screen while it is reading it, there will be some spots where you as the writer will cross over what the driver is displaying, effectively making the driver display part of two different frames. For your average game, this is no problem, a minor graphical glitch that is only present for about 1/60 second and that only happens about 1 time per second. But grayscale is an entirely different case. This graphical glitch is very obvious because it screws up your careful pixel timing. Instead of ON ON OFF ON ON OFF, sometimes you will have ON OFF ON ON OFF ON, which spread over the whole screen, just looks bad. Also, let's say that you don't know about this whole refresh thing and you update the screen at either 80 fps or 40 fps. At 80 fps, some of your frames are never going to even make it to the LCD, you are updating it so fast that you will update it again before the driver has time to display it. And at 40 fps, some of your frames are displayed twice. After hearing that, I'm sure there are a few of you that could go out and write your own display routines, but there are also those who can't. Here is an example of what we don't want.  You can see that the LCD driver and the displayer are not in sync and scan lines are clearly present. (Technically since that is in wabbitemu, I had to do something entirely different to get that effect, but you get the drift.) Now, to get away from this, you have to learn the way of the LCD driver, and try to basically run away from its display line. First off, it displays rows, not columns. So we will obviously have to write a 07 to port (10h), and work horizontally across the screen. This does have some speed drawbacks, but that's just how grayscale goes. Now that that is out of the way, you will notice that your grayscale routine actually looks a lot better, but we're not done yet. The next step is to get in sync with the driver, which is accomplished with the crystal timers. Our goal is around 60 Hz, so the timer that gives us the most flexibility around this range is timer 40h, it runs at 10922.667 Hz. Then you have to apply your multiplier to it 10922/60 = 182, so a counter of 182 will get you 60 Hz. I of course prefer 178 as that is what my calculator is synced to, but to each his own. (The typical range is about 160-180). To put this into code. 40h to (30h), 0 or 2 to (31h), and 178 to (32h). That's it, do that and you will have perfect grayscale. And why did I mention 100 pixels / (1/60 seconds)? That's because you can't perfectly match the frequency of the driver and there will always be a small glitch line. But if you do it right, the line is off screen for 1/3 of the time. Here's an example of implementing what I just talked about. It's commented quite nicely, but I left it up to you to make your own calibration screen (I don't want all the games to look the same  )
|
|||
Rating: This article has not been rated yet. |
|||
|
Powered By SMF Articles by CreateAForum.com