Xref: news2.mv.net comp.os.msdos.djgpp:7366
From: John Luebs <jkluebs AT sprynet DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: buffer -> screen transfers
Date: Tue, 13 Aug 1996 20:25:18 -0400
Organization: EpiCenter Software
Lines: 32
Message-ID: <32111CEE.4194@sprynet.com>
References: <320647A3 DOT 5827 AT cadvision DOT com> <4ud6d8$7j4 AT mack DOT rt66 DOT com> <320A825D DOT 3098 AT cadvision DOT com>
Reply-To: jkluebs AT sprynet DOT com
NNTP-Posting-Host: dd03-082.compuserve.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: John Meilleur <meilleuj AT cadvision DOT com>
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

John Meilleur wrote:
> 
> > If at all possible, arrange to not have to clear the parts of the
> > screen that are overwritten anyway. 640*480 makes for a lot of bytes.
> > Don't write to them twice if you can.
> >
> > For clarity's sake, I'd just use memset instead of the first asm,
> > and fmemcpy on the second. Well , *I* wouldn't, but I recommend it
> > anyway.
> 
> Thanks a million!  I tried it out and man was there ever a speed
> increase.
> One of my next issues to tackle is to have minimal overdraw.  The asm
> will be fine with me cause I understand Intel assembler but I defintly
> need work with my AT&T asm.  THANX!
> 
>                                                 -John Meilleur
>                                                  meilleuj AT cadvision DOT com
Why not use something like this ...
#define SCREEN_XFERS 16000
#define VRAM_LOC

void Draw_A_Screen(char* data)
{
	
	_dosmemputl(data,SCREEN_XFERS,VRAM_LOC);
}

This would work for a mode 13h screen (could be modified for any mode)
it would write 32 bits at a time and there is no slow for loop!

John Luebs <jkluebs AT sprynet DOT com>