ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/04/17/20:04:56

Xref: news2.mv.net comp.os.msdos.djgpp:2822
From: cotool1 AT umbc DOT edu (o'toole casey)
Newsgroups: comp.os.msdos.djgpp
Subject: GRX20 speed/memory access
Date: 17 Apr 1996 16:32:43 -0400
Organization: University of Maryland, Baltimore County
Lines: 21
Message-ID: <4l3khb$dlu@rpc22.gl.umbc.edu>
NNTP-Posting-Host: rpc22.gl.umbc.edu
NNTP-Posting-User: cotool1
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Well, I was thumbing through the GRX 2.0 source and saw that it uses
pokes to write pixels..  This obviously is horrendously slow given
the 30 FPS I am getting just clearing a context and writing it to screen.

So I figured out how to use the 
screen = unsigned char *(0xa0000);
__enable_nearptr()
screen[320*y + x + __djgpp_conventional_base] = color
__disable_nearptr()

Now, I would like to be able to do this but also use GRX 2.0 if need be.
The problem is that when I try to write to the Ram Context it blows up on
me.

i am doing this:
buffer = buf -> gc_baseaddr;
then using buffer just like screen example above.

Anyways... Anyone tried anything like this while still trying to retain
the use of the GRX Library??

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019