Xref:	news2.mv.net comp.os.msdos.djgpp:2562
From:	nicolas AT dsys DOT ceng DOT cea DOT fr (Eric NICOLAS)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: GRX20 Help!
Date:	9 Apr 1996 05:45:22 GMT
Organization:	Commissariat a l'energie atomique Grenoble (France)
Lines:	28
Message-ID:	<4kcthi$oqv@news.cea.fr>
References:	<4k3vit$20m AT soap DOT news DOT pipex DOT net>
Reply-To:	nicolas AT dsys DOT ceng DOT cea DOT fr
NNTP-Posting-Host:	hudson.ceng.cea.fr
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

>>Second.. Is there anyway to access the memory of the buffer directly so I
>>dont have to use the putpixel function everytime?
>
>and nicolas AT dsys DOT ceng DOT cea DOT fr (Eric NICOLAS) replied:
>
>>In the GrContext datas, you have somewhere a gf_baseaddr which is the adress
>>of the screen. But be aware that you'll have to manage *far* pointers, which
>>is not obvious with gcc. PutPixel and others libgrx functions are REALLY fast,
>
>What's this about far pointers? I thought they didn't exist under gcc.
>AFAIK all pointers are capable of specifying any memory address... the
>far keyword is not defined...

Yes, *far* keyword is not defined, but under DPMI, when you want to access screen or
whatever, you have to acces to another segment that CS=DS=ES=SS djgpp one. To do that,
you must use a DPMI selector and put it in DS. So it is like a 'far' pointer. There
are functions and macro-definitions in a djgpp's header (don't remember the name) that
provides equivalent to 'far' keyword.

Hope it helps.

-- 
Eric Nicolas <nicolas AT dsys DOT ceng DOT cea DOT fr>

Take a look to the SWORD home page :
	http://mimine.iut.univ-metz.fr/~borysgr/sword.web/home.html

- Raw text -