Mail Archives: djgpp/1999/11/24/18:59:52
Kalum Somaratna aka Grendel napisał(a) w wiadomości:
<94339412201 AT out DOT newmail DOT net>...
On 22 Nov 99, at 22:03, Chaos wrote:
>
> First, I'm wondering what is your "magic" video card. Secondly, I
have
> tested LFB method on my RIVA 128 (VESA 3.0). Using fprintf
didn't cause any
> sudden errors or screen garbage. The text was appearing right as
it supose
> to. I will do some more intensive test to ensure correctness. Eli
Zarestki
> (big thnx 4 that) also mentioned about checking no of columns
and rows in my
> specific mode(ScreenCols() and ScreenRows() functions),
640x480x256c - 0x101
> in my case. It turned out that there is 80 columns and 30 rows.
The number
> of rows can make some problems but I'm looking forward to solve
it.
>
First of all my "magic" card happens to be an ancient Cirrus Logic
GD5430 with 1MB video ram and it supports VESA 1.2 (BTW
Please don't laugh as I am prone to having heart attacks). To get
VESA 3.0 support I use UNIVBE.
No way!! Long time ago I also had had CL 5434. I was really happy about it
until apearing of S3 Virge.
BTW. Do you know what the heck is VBE/AF statement for. I've noticed such
thing in dcumentation and sources of Allegro. Is it another level for VBE
after VESA 3.0?
Rather than using printf to draw text I think you should try to write
your own font drawing routines which directly write to memory. If
you want you can check out the allegro library for examples on
how it handles fonts.
Yeah! It crossed my mind. I would have to implement all used types of
characters (digits in my case) by drawing and coppying bitmaps.
It sure would be harder than little fprintf but I think much faster because
of fprintf using INT 0x10 (mode switching etc.).
The reasons for using Font drawing routines IMHO are,
1. When you draw a font you are directly writing to video memory.
Yup.
printf on the other hand is much slooower because it generates an
interrupt (10h) which is intercepted by the DPMI server which
switches the CPU into real mode and generates the interrupt which
is handled by the BIOS which draws the text (BTW BIOS routines
are often very slow) afterwards the DPMI server switches the CPU
into Protected mode and your program resumes etc...
I thought (as you see above) about the very same thing.
As you can see IMHO just a simple printf can take a lot of time
and instructions relative to a Font routine which draws the text
directly to screen.
And BTW I don't think it's possible to use printf to position text
exactly at certain x,y coordinate's on the screen (for ex if you want
to print some text starting at x=337 and y=108 how do you instruct
printf etc.. to do it? On the other hand a graphics mode based font
routine will have no problem as you can give the coordinates
directly to it).
I thought about it too. If fprintf uses INT 0x10 (probably function 0x13)
maybe it will work to instruct BIOS to position cursor on specific position
(x and Y) the same way by INT 0x10. I've searched for such function. For me
function 0x2 of INT 0x10 does that job:
(input)
=> AH = 2
=> BH = number of video page.
=> DL, DH = X, Y of position of cursor.
Anyway, I'll try to figure something out.
So I think that although coding for a Font Drawing routine might be
harder it's worth it, because It will be faster than printf and it also
will be fully compatible with the graphics mode you are using.
I think that too. Changing in stead of typing text to draw a text.
Happy Hacking!
Kalum
Thnx!
3mcie sie.
-=| Chaos |=-
e-mail: chengin AT alpha DOT net DOT pl
chengin AT polbox DOT com
_______________________________________________
The statistics on sanity are that one out of every four people is
suffering from some form of mental illness. Think of your three best
friends. If they are okay, then it's you.
_______________________________________________
- Raw text -