Mail Archives: djgpp/2001/07/20/10:31:12
me:
>> #include<go32.h>
>> int main() { // gcc video3.c -o video3.exe
>> _farpokeb(_dos_ds,0xb8000+12*160+40*2,1);}
>>
>> compiles and runs fine. (gcc2.03)
DJ Delorie:
>If you run it on my old laptop it will fail, because my laptop has a
>monochrome screen (0xb0000). It will fail on my newer laptop because
>the screen is not 80x25 cells. It will fail if the center cell has a
>black-on-black attribute already (or any other same-on-same
yes, I'm aware of this. I did have this b000 vs. b800 problem with older
cards. I checked this by calling int 16 with ah=15 in assembly.
>attribute). Just because it happens to run on your machine does not
>mean you have learned a proper and useful technique.
it does. Once you know how to do it on one system , it's easier
to do the same on another system or to make it work on many systems
simultaneously.
>If your purpose is to do graphics programming, then you are learning
>the wrong techniques anyway. You want to learn about the _farns*
>functions and nearptrs, or use Allegro (which hides the hardware
>layer, allowing you more than 640x480 without having to know what kind
>of card you're using) or GRX. *Especially* if you're teaching people
>how to program! Give them a high-level library like Allegro and
>they'll see better results faster, which will encourage them to
>continue.
>
>See also http://www.delorie.com/djgpp/doc/ug/ which has a chapter on
>graphics programming for DJGPP.
maybe later. ATM other things are more important to learn for me.
You won't start with the heavy stuff . First do some easy things
and enjoy the little successes , then slowly advance and extend.
At this point I'm not sure , whether I will ever need that
Allegro etc.
Probably it takes many hours , before I understand it and will be
able to use it.
>As for general C, you should get in the habit of adding spaces and
>sparsely populated lines (appropriately, of course) to make your
>program more readable .
I tend to disagree (although that might change once I know
more about DJGPP)
Why should I deliberately add spaces and sparsely
populated lines ? They only make the program larger.
I can't see why it should increase readability.
I prefer compact programs which fit on one printed page
or monitor page rather than wandering through many pages ,
when trying to find a function or just finding the "}"
corresponding to the "{" some hundred lines below.
> (DJGPP's indent tool can do this for you). {einruecken
I couldn't find it. So I can write short code and "indent"
makes it more readable for people like you ? That's fine.
Is there also an unindent-tool , which compresses sparse lines ?
>This is especially important if you want someone else to read your code
>to help you solve a problem.
maybe some (most ?) people think so.
But when I see long programs, I become discouraged.
>Before:
>
>int main() { // gcc video3.c -o video3.exe
>_farpokeb(_dos_ds,0xb8000+12*160+40*2,1);}
>
>After:
>
>int
>main ()
>{
> // gcc video3.c -o video3.exe
> _farpokeb (_dos_ds, 0xb8000 + 12 * 160 + 40 * 2, 1);
>}
>
>You should get in the habit of returning a valid exit code, either by
>calling exit() with a suitable value (zero for success, nonzero for
>failure) or returning a suitable value from main (rather than just
>falling off the end as you do).
because this is transmitted to DOS , I assume (?)
I never used this return code in DOS-programs ,
but OK, it could be useful.
Guenter
- Raw text -