Mail Archives: djgpp/1999/11/22/17:49:02
> My philosophy is that: If Allegro can do it I can do it too.
> BTW. I'm treating that game as learning in programming C and Asm using
> various algorithms.
Way to go Chaos! It's nice to see someone trying to learn by
experimenting instead of relying blindly on high level library API's.
Thnx!
BTW. I've just reviewed most of Allegro code. It's written very nice, but it
covers every aspect that can be found. Speed and size suffers a little,
probably. That's why I love to write my own routines (and messing with bugs
:-) ). Not mentioned about happiness after solving problems.
Sure, Allegro is a great library (my favourite) but one must not
depend on library's without having a understanding of what they do.
for ex;- If you have a understanding about various algorithm's for
texture mapping ...etc you can think of other faster, innovative
ways of doing it....(and maybe write a new 3D rendering engine
which will get you lot's of $$$) .
Thatt's the point. IMHO basics are very important. If it wasn't we all will
be "coding" in Visual Basic ;-)
>>None of VESA works when compiling for M$ Windows
If the video card supports VESA then you shouldn't have any
problems acessing it under Win95/98. AFAIK NT doesn't allow
direct access so this might not be possible under NT.
Hmm .... Unfortunatelly NT is what it is. But I think most of the ppl that
have NT also have Dos booting hidden in some area of boot loader.
Some card's have buggy VESA implementations however this can
be corrected by installing SciTech Software's Display Doctor.
The great game Quake v1.00 uses VESA 2.0 for video acess.
Do you think that using SciTech Univbe can protect any unwanted errors from
video card? After some time of coding I have realized that one of tha major
problem was not having acces to other testing machines than mine. Does
recent Univbe can provide 100% compatibility?
>Now i'm wondering if I can do it safelly. Can I stick with printing >text
messages such as timer or player name using only printf->family functions.
Are there any limitations in using those functio
ns >in graphics modes?
AFAIK printf is dependent on the BIOS to print the strings. So the
BIOS must be able to acess the video memory you are using for
your graphics at the same time (it must understand the graphics
mode).
Ehm. Eli Zarestkii told me the same thing.
In my video card the bios writes to 0xA000 segment for printf call's.
So when you use bank switching printf will work (the BIOS writes
text to 0xA000 and the video card also uses 0xa000 for the
screen).
I get it.
However if you are using the Linear frame buffer mode the buffer
may be located somewhere around 128MB so the video card will
be using the 128MB location for the screen. So when you use printf
my BIOS will still be writing text to 0xa000 and there will be no text
output on the screen because my video card in LFB mode ignores
what is written to 0xa000 (because it reads the LFB located at
128MB).
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.
Regards,
Kalum
Take care.
-=| 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 -