Hi, These solutions are pretty cool, The one that render the whole page once and then only scroll up/down/left/right when need is the best one in my point of view.
However the one that redrawn only the needed area is easy to implement. What you guys don't realize is that we don't need to save things in menu, since the process to (re)generate that is easy/fast. The slow part is to blit them on the screen. So we don't need to save anything, only redraw the not-selected-anymore item and paint the new selected one. It's really easy. But we should really thing at the solution that render a big part of the page and then display subparts of it. We could use draw 3 pages: 1 page above, the current page and 1 page below. Gustavo --- Thomas Schueppel <[EMAIL PROTECTED]> escreveu: > hi, > > this may be completely trivial bullshit because it's just > theoretical thoughts when reading your post. Feel free to > ignore it. > > In Computer games you usually solve this problems the > following way: > For smaller moving objects (like the cursor) you use a sprite. > Rendering is performed background first. Then sprites are draw > on top of it. Sprites usually have at least a one bit alpha > channel. More than one bit is not supported by direct-x and > may be slow. (I'm not sure if linux is any better there) > (Should be okay for a low number of sprites though.) > > For scrolling or panning you usully use the following > technique: > Use a larger surface than the displayed area. This would > be the whole guide if the memory required is acceptable. > Since this whole guide needs to be drawn only once, this > will only require time once in the beginning. > For rendering you chose a rectangular area and draw the > needed sprites (cursor) in that and set the video buffer > to that area. > If the surface would become too large, then you chose > a surface that is one row and one column larger in each > direction than the viewable surface. Now you still can > scroll very fast and then rebuild the surface once it > is shown in the backbuffer. This way the rendering is > always one step ahead of the user and reactions are > much faster. > > As I told before this is the standard way panning games > are implemented. You should be able to find a lot of > info about that in the pygame world. > > l8r... > Thomas > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Freevo-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/freevo-devel _______________________________________________________________________ Busca Yahoo! O servi�o de busca mais completo da Internet. O que voc� pensar o Yahoo! encontra. http://br.busca.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
