Hi Andreas,
Thank you for your reply;
>In that case it's a HW-limitation:
>
>800x600= 480 000 byte , 800x600x16bit= 960 000 byte ... no room for double height.
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?
>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)...
>>(...)
>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. E.g., I just copy the lower 4/5 of the screen plus a part of the
invisible visual which follows them at higher
values of y - further down - (sized 1/5 of the visible part of the visual) onto the
entire visible visual with a single ggiCopyBox()
call. Right?
>> But if I really don't manage to get a longer virtual visual, what can I do about
>it?
>
>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?
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?
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() or ggiPutBox() and flush that visual, right?
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)...
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 (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?
Once again, thank you for any information.
Bye,
Manuel
