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
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>

- Raw text -