🚀 go-pugleaf

In article <1992Aug4.222047.57853@cc.usu.edu> sl8nl@cc.usu.edu writes:
> I'm curious.  What are the speed differences between ModeY and 13h?  In
> my tests, 13h has always come out on top many times over (even copying
> 4 bytes at a time in VGA RAM).  Why is this?  As offered to me by a friend,
> the VGA card is on an 8 mhz bus...so graphics transfers are only at 8mhz.
> If this is the case, the ratio between ModeY and 13h should be fairly
> close.  This is not happening, though.  Can anyone offer a valid explanation
> of why this is?  ModeY offers some very valuable techniques (panning,

	I tested the speed of 320x240x256 mode X and normal mode 13 by
	a simple C program which symply did 10000 byte long memset()
	to screen 10000 times. (486/33, 11MHz bus, Trident 8900 card)
	I did not test moves within the display memory.

	The execution times: almost identical! (note: it did not
	matter whether write was enabled to one or all planes in Mode
	X, the time was the same => ModeX does indeed have four times
	faster performance, if you can update all planes with single
	access).

	I was surprised since usually Trident's planar (16 color) modes
	are much slower than 256 color modes with similar resolutions
	in raw access speeds (according to VIDSPEED 3.0).


--
/*-- Jari.Karjala@hut.fi -- The World is Just a Huge Fractal --*/
float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<L?--_
%6:6:7)+"World! \n",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;}

> 	I tested the speed of 320x240x256 mode X and normal mode 13 by
> 	a simple C program which symply did 10000 byte long memset()
> 	to screen 10000 times. (486/33, 11MHz bus, Trident 8900 card)
> 	I did not test moves within the display memory.
> 
> 	The execution times: almost identical! (note: it did not
> 	matter whether write was enabled to one or all planes in Mode
> 	X, the time was the same => ModeX does indeed have four times
> 	faster performance, if you can update all planes with single
> 	access).

The problem with updating all four planes in a single access, is that your
images have to be in VGA RAM.  Unfortunately, in some programming scenarios,
this cannot be.

I've had no luck reaching my display speeds of 13h.  I've even gone right
down to storing each plane together, making sure that the size of the image
is always word-aligned (for rep stosw), making sure that the starting X 
coordinate starts on a multiple of 4, and making sure that the total X size
of the image is a multiple of 4.  My speeds still won't compare.

OK, everyone else, lets hear your ideas on this.  I need to be convinced 
that I can pull it off.

Josh

"Josh" writes:
>The problem with updating all four planes in a single access, is that your
>images have to be in VGA RAM.  Unfortunately, in some programming scenarios,
>this cannot be.

Using the VGA's latches to move 4 bytes at a time around in video memory
is the only way you are going to get better speeds drawing bitmaps in 
a 256 colour planar mode over mode 13h.  You can also get better speeds
doing some simple pattern fills as well.  You are not going to get better
speeds coping bitmaps from main memory to video memory and you're not
going to get terrible performance drawing things like lines and circles
in a 256 colour planar mode.

Mode Y doesn't make your video card or computer any faster.

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //

In article <1992Aug5.095902.57866@cc.usu.edu> sl8nl@cc.usu.edu writes:
>
>I've had no luck reaching my display speeds of 13h.  I've even gone right
>down to storing each plane together, making sure that the size of the image
>is always word-aligned (for rep stosw), making sure that the starting X 
>coordinate starts on a multiple of 4, and making sure that the total X size
>of the image is a multiple of 4.  My speeds still won't compare.
>
>OK, everyone else, lets hear your ideas on this.  I need to be convinced 
>that I can pull it off.

Sorry for popping in in the middle of discussion and without a clear
knowledge of what exactly are you comparing, but I have some information
regarding the speed differences of mode 320x400x256 and mode 13h.

Background: I am working on a 3D space game that uses 256-color shaded
polygons, among other things. I have a viewport on the screen (256x240
pixels on 320x400 mode and 256x122 pixels on mode 13h). I need to clear
this viewport and draw all the polygons on it during every frame. My
320x400 mode uses double-buffering, naturally, and mode 13h uses a separate
256x122 memory buffer which is then copied to screen (rep movsw).

I have found that in this situation the 320x400x256 mode is MUCH faster.
On my 486/33 machine I can reach around 50 frames/sec in that mode, where
mode 13h (although it has only half the number of pixels to update) runs
at less than 30 frames/sec. The speeds may seem slow, but that is because
my game plays digitized four-channel tracker music in the background at
the same time, and the polygon boundaries are anti-aliased in real time.

I think the speed difference is a direct result of the ability to clear
or draw 8 pixels per one STOSW or MOVSW instruction on 320x400 mode,
where it only draws 2 pixels on mode 13h. Very important.

Was this what you were comparing?

Patrick Aalto
ap@tukki.jyu.fi

Ps. I also support S3 86C911 graphics processor in 800x600x256 mode.
With it (viewport size is a huge 640x400 pixels) I can reach around
32 frames/second, and the game is visually absolutely stunning! Compared
to this the old mode 13h looks like a collection of big LEGO blocks.
Awfull!

> Sorry for popping in in the middle of discussion and without a clear
> knowledge of what exactly are you comparing, but I have some information
> regarding the speed differences of mode 320x400x256 and mode 13h.

No problem.

> Background: I am working on a 3D space game that uses 256-color shaded
> polygons, among other things. I have a viewport on the screen (256x240
> pixels on 320x400 mode and 256x122 pixels on mode 13h). I need to clear
> this viewport and draw all the polygons on it during every frame. My
> 320x400 mode uses double-buffering, naturally, and mode 13h uses a separate
> 256x122 memory buffer which is then copied to screen (rep movsw).
> 
> I have found that in this situation the 320x400x256 mode is MUCH faster.
> On my 486/33 machine I can reach around 50 frames/sec in that mode, where
> mode 13h (although it has only half the number of pixels to update) runs
> at less than 30 frames/sec. The speeds may seem slow, but that is because
> my game plays digitized four-channel tracker music in the background at
> the same time, and the polygon boundaries are anti-aliased in real time.
> 
> I think the speed difference is a direct result of the ability to clear
> or draw 8 pixels per one STOSW or MOVSW instruction on 320x400 mode,
> where it only draws 2 pixels on mode 13h. Very important.
> 
> Was this what you were comparing?
> 
That's what I wanted to know...
Josh