double buffered displayproblem

jeryslovenia

Hi!
I am working on a project that would read some data from adc and inputs and show it on LCD display. Everything seems to work fine until i reach the "display_base" adress with the code. My question is how to lower number of longs in display_base and bitmap_base. I am using double buffered display to avoid flickering.I could also decrease resolution but dont know how to do that. I am using graphics and tv object to draw image on LCD. If you need some more information feel free to ask for it!
Thanks

Mike Green

Unfortunately, doing graphics while minimizing flicker takes a lot of memory. You can eliminate the 2nd buffer and try to do the screen updating in such a way that it minimizes flicker. Decreasing the resolution may not be practical since that's usually done in powers of 2 (half the resolution) and that will affect how much data you can show. You could go to a text-only display and use text characters to do simple graphing. It's possible to combine text and small areas of graphics on a display, but it's not something for a beginner to take on and certainly isn't something that could be explained in a few forum messages nor is there any "drop-in" code available.

It would help if you attached your source code to a message (use the Go Advanced button to get the Attachment Manager).

jeryslovenia

Ok this is the code whitch is comented in my native language but i think that you would find the way it is sopose to work. This one actualy works but i need to add some more in the main loop and risipisi routine, but i am almost at the display_base = $2000 limit. Maybe there is a way to decrease number of colors and later decrease number of longs for buffer that way. Any help or ideas are welcome!

Mike Green

Each of your display buffers is 12K bytes (display_base to display_base+$2FFF and bitmap_base to bitmap_base+$2FFF). You could go from 2-bit pixels to 1-bit pixels (black & white only), but it would take a bit of work to modify the graphics object to work with 1-bit pixels. You could reduce the resolution, but it's not a matter of just trimming a few pixels off each dimension. Usually this works best when you use a power of 2 relationship to the display itself. It'll take a bit of experimenting to see what's possible. The easiest thing to do is to eliminate the double buffering. You have to be careful about what you rewrite in order to avoid significant flicker, but selective erasure works for a lot of things. If you have a gauge, you erase the pointer only rather than redrawing the whole gauge before you display the new pointer.

potatohead

http://forums.parallax.com/showthread.php?134294-Partial-Buffer-Graphics-Demo

That might give you some ideas too. In addition to the selective drawing and erasing concept Mike just wrote about, you might consider dividing your display into one or more strips. Your double buffer becomes one single buffer + whatever a strip is. The more strips you use, the smaller the partial buffer can be, but the lower the overall frame rate of a completed display is. On the other hand, this is an easy technique due to how the graphics library COG will perform clipping operations for you.

Basically, you draw one strip, copy it to the primary buffer, then draw another strip, and another, and another, one per TV frame. The complexity of your display will determine what can be done in one frame. If it's really complex, you might take two frames, etc...

In that thread, I've got the graphics demo partially buffered and running at full speed without the double buffer graphics. There are some trade offs, like tearing or misalignment of images, due to one strip being current and the one next to it being from the past. Whether or not this makes sense for you will depend on what the display looks like.

You can also build graphics in a smaller buffer that isn't a strip too, and those can be done off-screen and copied to the main screen when you want them to be seen. In either case, the key is to take the time off screen, but only for a portion. The time it takes to copy it to the main, always visible screen is small, and that is what makes it work well without doing a full buffer.

My blog contains a short video: http://forums.parallax.com/entry.php/381-Much-better-single-buffer-graphics which shows the graphics in action.

Ariba

You can reduce the resolution with the x_tiles and y_tiles parameters. Every tile is 16x16 pixels.
The picture will get smaller on the screen, but you can compensate that with the hx and vx parameters in DAT - tvparams.
hx= horizontal expansion, vx= vertical expansion factor.

Then you must adjust bitmap_base and display_base values to the new picture size, so that the spared memory is usable by Spin.

Attached is an example with 224 x 160 pixels. I have made my own Main methode, so that I don't need all the included objects.
You will need to scale the width of the gauges so that they fit into the new horizontal resolution. Maybe you can make them scalable with a x- and y-scale variable.

The smaller resolution gives you 6.5 kByte more memory for Spin.

Andy

jeryslovenia

Thanks a lot guys!
Now i am working on Andy`s solution which i think will give me just enough extra space to add the remaining program. I chose it also because it is the simpliest. It does affect a little bit to the upper and lower margin of the screen because i can´t draw on it,while its impossible to change the vx factor since primarly its set on 1, but this is sacrifice i am willing to take, unless someone has a solution. Thanks again!

Ariba

In vertical direction the scaling is a bit limited, because the visible lines of NTSC or PAL are fixed at ~220 / ~250.
You can set vx=2 if you reduce the vertical resolution to 96 or maybe 112 (y_tiles=6 or 7), then two NTSC lines show the same pixel.

My code is made so that you can play with the x_tiles and y_tiles constants, all the related parameters are calculated from them. Only the vx parameter needs to be adjusted if you go < 8 y_tiles.

Andy