> I just found out that I was wrong: I have 2MB of VRAM in the card, so
> perhaps the 800x1200x16bit= 1920000 mode might work, right?
Technically speaking: Yes.
> >Please read vesafb.txt somewhere under /usr/src/kernel/Documentation/* .
> >There is an option that allows higher virtual heights.
> I did as you told me and read the vesafb documentation under the kernel
> documentation dir, but I found out that I've been using the
> video:vesa=ywrap boot argument for a while now (actually, it was you who
> told me about it a few years ago on this list :-). Setting video:vesa=ypan
> doesn't seem to do the trick, either. The calls to ggiCheckGraphMode()
> with a virtual visual size larger than the physical one still fail (return
> -1)...
Try doing them with all AUTO and see what it reads.
> >I think you misunderstood each other here. Marcus is talking about using
> >a single "ggiCopyBox" for the whole screen - how far you scroll then is you
> >choice. I think he had the impression that you wanted to move it
> >row by row or something ...
>
> I did... :-) But I now understand that I can use a single copy of
> ggiCopyBox() when scrolling gradually if I have a longer virtual visual.
You can always do it . No matter how long the visual is.
Say you have a 640x480 with a 8x16 font (i.e. 80x30 text), and you want to
scroll up by v pixels (or w lines with means v=w*16), you do:
ggiCopybox(vis,0,w,640,480-w,0,0);
and then redraw the up to now duplicated part at the bottom that starts at
line 480-w.
> >Either draw as needed from a virtual plane you just "imagine", like text
> >editors do, or allocate a large enough Background buffer in a memvisual
> >(read targets.txt in the doc dir for that) and use ggiCrossBlit.
>
> Concerning the first option you mentioned, could you explain it to me in
> just 1 or 2 sentences? How do I use such a "virtual plane"? In how far is
> this different from using a memory visual?
Very. The idea is, that you have some abstract description of how the output
should look like, like the text file itself in the case of text editors.
Now you e.g. want to display the text starting with line 23, column 42 at
the top/left position. You would then do something like:
textfile_go_to_start();
textfile_skip_lines(23);
for(y=0;y<num_lines;y++) {
for(x=0;x<num_cols;x++) {
chr=read_one_char();
if (chr=='\n') break;
ggiPutChar(vis,x*chrwidth,y*linheight,chr);
}
if (x==num_cols) while(read_one_char()!='\n')
}
I think you get the idea.
> If, after having read targets.txt, I am understanding you correctly, the
> second option you referred to consists in having a "regular" visual sized
> 800x600 (and V800x600) - which always contains whatever is being displayed
> to the user -, and then creating a dyn allocated memory area "longer" then
> the visual (was this what you meant by "[allocating] a large enough
> background buffer in a memvisual"?) which I'll tell GGI to handle as if it
> were a visual, and on which I can, therefore, use all the ggi functions to
> draw things although it is just "normal" memory instead of a "real" visual
> - is this a memvisual?
Yes. You just open it using ggiOpen("memory"); .
> When I wish to scroll the screen, I just copy a (screen-sized) section
> from the memory visual to the "real" visual using either ggiCrossBlit()
> and flush that visual, right?
Yes.
> or ggiPutBox() and flush that visual, right?
No. PutBox is not intended to be used between visuals. Formats might differ.
> But this raises a question: using this method, if I wish to allow the user
> to vertically scroll over a virtual area of, say, 800*(3*600) (three
> "screens" at 800x600, not *that* much!), I need 2,88MB of memory just to
> store the memory visual (from which I would then copy screen-sized
> "chunks" when scrolling)...
Yes. But note, that all you loose as compared to using the larger virtual
size method is:
1. The memory used for the _visible_ window.
2. The memory used for the virtual plane is now from main memory as opposed
to graphics card memory.
> Do the apps that allow users to scroll over multi-page documents (e.g.,
> text-editors, browsers, etc) keep a n*980KB graphical representation of
> the document in memory
Of course not. See above. They "render" the right view on demand as I
described with my pseudocode above.
> (where n is the number of "physical screens" it would take to display the
> entire document)? Or are these high memory requirements the reason why
> they use the "virtual planes" method instead?
Yes. Usually. In some cases rendering is painfully slow, in which case one
often "prerenders" and "caches" a little ...
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
