Blittering to VGA memory is lame!!!
Thomas Nielsen
fastest way to update the VGA screen is to reserve a memory
buffer, do the screen updating in this buffer, and then copy
the buffer to the VGA.
When I first heard that this is what people do, I could not
believe my ears. To me, it seems totally stupid to write
something to the memory, just to move it again later?!?!
Personally, I use mode-x, update a non-visible VGA area, and
change the display start address.
I can easily do a lot of scrolling and sprite moving at 60 fps.
I have ofcourse tried reserving a memory buffer and the
blittering this to the VGA. I used:
MOV ECX,4000
CLD
REP MOVSD
which, as far as I know, is the fastest way to do this. This
took up 50% of the processor time on my Pentium 75 PCI bus
machine. And this does NOT seem satisfying to me!!! On slower
machines you would have to lower the frame rate to around 20
fps using this.. Something which is CERTAINLY not acceptable to
me nor any other gamer who has spent more than 500 quid on a
PC.
Now I would like someone to tell me if I am lame, or all those
people using a memory buffers are lame. Am I doing this wrong,
or should this buffer-updating really use this much processor
time??.
If I am doing this right, I really can not see why anyone would
use a memory buffer, when transferring it to the VGA takes up
this much time. I know liniar memory is an advantage when
working with vector and stuff, but I know many of you work with
2d, and I really do not see any reason to use a memory buffer
then.
Somebody discuss this with me :)
Thomas Nielsen, Progressive media.
(Thomas_...@online.pol.dk)
Saulnier
: In article <49datl$7...@www.cybercity.dk>,
: Thomas Nielsen <Thomas_...@online.pol.dk> wrote:
: [Speaking about using a buffer vs. page flipping...]
: >Now I would like someone to tell me if I am lame, or all those
: >people using a memory buffers are lame. Am I doing this wrong,
: >or should this buffer-updating really use this much processor
: >time??.
: >
: Abrash and friends at ID use a buffer and move in the new sure to
: be smash hit QUAKE. Do you think they are lame?
I'd check your sources before stating something like this!
I agree with the original person who started this thread that using an
off-screen buffer is lame. If you do texture-mapping, you'll be using an
off-screen buffer, but it ain't gonna be pixels that you'll be storing there.
Writing directly to the screen will always be faster than a write to off-screen
buffer and a copy anyday. Sorry, but write+copy > write!
And if you know what you're doing, you won't write more than once each pixel
on the screen!
: SRP
: <Check out http://www.mcs.com/~poschs/GDK/gdk.htm for info on GDK95>
--
----------------------------------------------------------------------------
Cleo Saulnier p8...@unb.ca
Author of the Official EOS Assembler
FileSystem Team Leader and Committee member for EOS!
EOS, THE ultimate Entertainment Operating System!
Prlkovsky
(Saulnier) wrote:
> Scott Posch (pos...@MCS.COM) wrote:
> : In article <49datl$7...@www.cybercity.dk>,
> : Thomas Nielsen <Thomas_...@online.pol.dk> wrote:
>
>
> : [Speaking about using a buffer vs. page flipping...]
>
> : >Now I would like someone to tell me if I am lame, or all those
> : >people using a memory buffers are lame. Am I doing this wrong,
> : >or should this buffer-updating really use this much processor
> : >time??.
> : >
>
> : Abrash and friends at ID use a buffer and move in the new sure to
> : be smash hit QUAKE. Do you think they are lame?
>
> I'd check your sources before stating something like this!
>
> I agree with the original person who started this thread that using an
> off-screen buffer is lame. If you do texture-mapping, you'll be using an
> off-screen buffer, but it ain't gonna be pixels that you'll be storing there.
>
> Writing directly to the screen will always be faster than a write to
off-screen
> buffer and a copy anyday. Sorry, but write+copy > write!
But is write bytes + copy words video > write bytes video, since mode X uses 4
pages it is sometimes difficult to write words to a page. I guess that
writing bytes to a fast memory buffer, setting up 4 buffers, and than writing
each buffer to each video page with word writes might be faster than writing
each vertical line in video memory with byte writes.
Just a thought, since I haven't tried it.
Doug McCreary
> Writing directly to the screen will always be faster than a write to off-screen
> buffer and a copy anyday. Sorry, but write+copy > write!
>
> And if you know what you're doing, you won't write more than once each pixel
> on the screen!
>
> : SRP
This isn't actually true in most software graphics architectures.
The reason this isn't true is that your two writes are not
equal. You may have been implying this in your second statement,
but it is in fact your second statement which I think is
further from reality.
Supposing that write_to_video = 10*write_to_memory
which is true in many systems. Then suppose that you are
attempting to build a ~128k screen. If your game supports
four layers of graphics, that is 512k. Now lets compare
numbers:
double_buffer_in_memory:
512k to memory * 1 = 512
128k to video * 10= 1280
total = 1792
direct_to_memory:
512k to video * 10 = 5120
total = 5120
Obviously, this isn't a complete comparison, but it demonstrates
well that in any system where the video memory is slower to
access than the system memory (which is basically EVERY system)
there are certain game designs which will clearly benefit
from having a double buffer in system memory.
In addition, even if you do have a graphics architecture which
eliminates layering, you probably have implemented what
effectively IS a double buffer in memory, you just don't
realize it (and such systems are frequently slower and
rarely faster than a true double buffer).
--doug
da...@ix.netcom.com
Jason Pollock
Saulnier <p8...@jupiter.sun.csd.unb.ca> wrote:
>Scott Posch (pos...@MCS.COM) wrote:
>: In article <49datl$7...@www.cybercity.dk>,
>: Thomas Nielsen <Thomas_...@online.pol.dk> wrote:
>
>
>: [Speaking about using a buffer vs. page flipping...]
>
>: >Now I would like someone to tell me if I am lame, or all those
>: >people using a memory buffers are lame. Am I doing this wrong,
>: >or should this buffer-updating really use this much processor
>: >time??.
>: >
>
>: Abrash and friends at ID use a buffer and move in the new sure to
>: be smash hit QUAKE. Do you think they are lame?
>
>I'd check your sources before stating something like this!
>
>
>: <Check out http://www.mcs.com/~poschs/GDK/gdk.htm for info on GDK95>
>
>
>--
>----------------------------------------------------------------------------
> Cleo Saulnier p8...@unb.ca
> Author of the Official EOS Assembler
> FileSystem Team Leader and Committee member for EOS!
> EOS, THE ultimate Entertainment Operating System!
I believe the reference is Dr. Dobbs latest sourcebook where Abrash
talks about problems with memcopy, and how their double buffer is faster
than page-flipping because of dword copies.
Jason Pollock
jason.pollo...@nt.com
-- My opinions are my own!
Scott Posch
Saulnier <p8...@jupiter.sun.csd.unb.ca> wrote:
>Scott Posch (pos...@MCS.COM) wrote:
>
>: [Speaking about using a buffer vs. page flipping...]
>
>: be smash hit QUAKE. Do you think they are lame?
>
>I'd check your sources before stating something like this!
I read it in the current issue of Dr. Dobbs sourcebook in M. Abrash's
article on BSP rendering. Right from the horses mouth.
Scott Posch
Thomas Nielsen <Thomas_...@online.pol.dk> wrote:
[Speaking about using a buffer vs. page flipping...]
>Now I would like someone to tell me if I am lame, or all those
>people using a memory buffers are lame. Am I doing this wrong,
>or should this buffer-updating really use this much processor
>time??.
>
Abrash and friends at ID use a buffer and move in the new sure to
be smash hit QUAKE. Do you think they are lame?
SRP
Van Schoenepauck
[some parts snipped away]
: I have ofcourse tried reserving a memory buffer and the
: blittering this to the VGA. I used:
: MOV ECX,4000
: CLD
: REP MOVSD
: which, as far as I know, is the fastest way to do this. This
: took up 50% of the processor time on my Pentium 75 PCI bus
: machine.
As far as *I* know (please correct me if I'm wrong), using REP MOVS*
is NOT the fastest way, at least on a Pentium, as the string ops are not
optimised on that processor. MOV/DEC/JNZ is faster. And loop unrolling
yields an even better performance.
Justin Johnson
p8...@jupiter.sun.csd.unb.ca "Saulnier" writes:
> I agree with the original person who started this thread that using an
> off-screen buffer is lame. If you do texture-mapping, you'll be using an
> off-screen buffer, but it ain't gonna be pixels that you'll be storing there.
It isnt so lame if your programming in 3d. By not storing in offscreen RAM,
I assume your talking modex. Modex is a sucky piece of crap for texture mapping!
It generally forces you to draw polygons in vertical strips rather than
horizontal which isnt so nice for the cache.
> Writing directly to the screen will always be faster than a write to off-screen
> buffer and a copy anyday. Sorry, but write+copy > write!
Probably true, but copying a full screen from RAM takes a few inches of
frame time on my machine which isnt a great worry. Also take into account that
generally, video memory is a _lot_ slower than normal memory. There are a few
cards out where its actually faster though.
If your doing 3d programming and using painters then I reckon that writing
to a video screen is actually gonna slow you down which brings us to the
next point.
> And if you know what you're doing, you won't write more than once each pixel
> on the screen!
Well, for 3d you must be talking about sbuffer. And depending on the
complexity of your 3d scenes, the overhead of such a buffer may not be
worth the trouble - you could end up worse off!
Well, you can call it lame. But I'll wager that a LOT of 3D games out
there ( in fact most of them ) render to an offscreen ram buffer.
Including any that I'm writing. :)
Regards,
-------------------------------------- / | / _ \ / _ \| \| \ ----------
Email:jus...@jjavp.demon.co.uk /()|/ /_\ \/ /_\ | \
3D Programmer and game designer. /(_)|\ \_/ /\ \_/ | |\|\ \
<____||\___/||\___/|_|/\ \_>
BOOM! BABY..Not bad for a humanoid. \____\| \__\/ \__/|/_/ \/_/
============================================== B A B Y =================
John Paul D'India
: this much time. I know liniar memory is an advantage when
: working with vector and stuff, but I know many of you work with
: 2d, and I really do not see any reason to use a memory buffer
: then.
Well, look at it this way, pixel writes are the costliest thing. In
mode-x you can only put on pixel at once, and in 13h you can move 4 at
once (if you have a good video card, which we're assuming everyone
now'a'days does). Secondly, mode-x requires setting up the port before
each pixel write (yes, with some fancy work'a'round, you can do it less
often, but I've never seen anyone with nice RLE sprites in mode-x [have I
not lived long enough?]). Thirdly, most games these says do lots of
parallax scrolling and stuff (we're assuming 2d, as you said before).
When you do parallax scrolling, lots of things overlap, so for each pixel
that overlaps in 13h, the cpu is taxed for once extra memory -> memory
copy. If it's mode-x, then it's a memory -> video copy, which is, as
stated previously, very slow. For my current game, we have lots of
p-laxing going on, and I think the penalties incurred by mode-x would
definately slow it down. However, if it's not a parallax game, mode-x
has advantages (esp. for solid polygon fills). I think there are
advantages to both modes, but given current video cards and 32bit cpu's,
I'd certainly lean toward 13h (back in the 8 bit video card days, I'd say
otherwise).
--
====================================
John Paul D'India - D'India Software
project: 4gen (space shooter)
web page: http://www.ax.com/dindia
====================================
Kevin Baca
>When I first heard that this is what people do, I could not
>believe my ears. To me, it seems totally stupid to write
>something to the memory, just to move it again later?!?!
It starts to make more sense when dealing with banked SVGA
hardware. Even with linear SVGA hardware it may still make
sense if you don't have enough video memory for more than one
page.
John Paul D'India
: on the screen!
Uhm, either you're a genius, or you're not thinking about what you're
saying. Are you trying to tell me that if you're scrolling the screen
around, and you're moving some sprites around, that while updating the
background, you don't copy certain pixels because you know that a sprite
will be overlapping it?
Mads Orbesen Troest
>I have ofcourse tried reserving a memory buffer and the
>blittering this to the VGA. I used:
>MOV ECX,4000
>CLD
>REP MOVSD
Due to the fact that typical cheap Video RAM is extremely slow, it can
actually be the best solution to keep as much as 2 buffers in the
computer RAM, quickly (well, as it can be done ;-) compare the buffers
for changes, and ONLY "upload" the changed pixels. (To speed up things
you could compare DWORDs, at nuke out the entire DWORD if just one of
it's bytes have been changed).
This method is sometimes called "Dirty Pixels", and can sometimes be
quite fast compared to using slow and unchained video RAM directly.
BTW: I saw your ad for "Progressive Media" once (and even considered
joining :-). Have you ever released any stuff?
>Thomas Nielsen, Progressive media.
Once upon a time Steve of X-Factor, right? .-)
On Behalf of Myself,
//====================================================\\
|| Mads Orbesen Troest - MARVIN of SIRIUS CYBERNETICS ||
||----------------------------------------------------||
|| WorldWeb http://www.cybercity.dk/users/ccc3749 ||
|| InterNet mar...@vip.cybercity.dk ||
|| FIDO Net 2:238/39.10 ||
|| ProgNet <Waiting for Address...> ||
|| CM Net 10:450/108.4 ||
||----------------------------------------------------||
|| -=> I Cry Therefore I Am... <=- ||
\\====================================================//
Steven E. Hugg
Don't forget that if your rendering algorithm writes some pixels more than
once, writing to fast memory several times, then copying it all once to video
memory may be faster. Some games, like Disney's Stunt Island, only write the
pixels that have _changed_ to the video buffer, for the ultimate in speed!
This was especially important before the days of local bus.
---------------------------------------------------------------------
Steven E. Hugg
HAMCO Software
Toby Hutton
: It seems to me that just about everyone here thinks that the
: fastest way to update the VGA screen is to reserve a memory
: the buffer to the VGA.
: When I first heard that this is what people do, I could not
: believe my ears. To me, it seems totally stupid to write
: something to the memory, just to move it again later?!?!
: Personally, I use mode-x, update a non-visible VGA area, and
: change the display start address.
: I can easily do a lot of scrolling and sprite moving at 60 fps.
I've found that in a lot of cases it's quicker to use a double buffer
because the time needed to do a single video write (ie. 1, 2 or 4 pixels)
is quicker. The many OUT instructions needed to plot some pixels and to
flip the page, and the extra code needed to handle planar video memory
makes ModeX a bit slower than Mode13h SOMETIMES. I think the real
advantage of ModeX is the access to all the video mem. and the abiltiy to
do hardware scrolls. With local bus video cards now, blitting a buffer to
0a0000 is pretty quick.
Toby.
C.H.Skilbeck
Here we are again in ModeX vs Mode13 !
We have been here before, people....We agreed to differ, as I recall.
We all know that sometimes one is better then the other, and that's about all
you can say about it, eh?
John C. Lonningdal
: It seems to me that just about everyone here thinks that the
: fastest way to update the VGA screen is to reserve a memory
: buffer, do the screen updating in this buffer, and then copy
: the buffer to the VGA.
: When I first heard that this is what people do, I could not
: believe my ears. To me, it seems totally stupid to write
: something to the memory, just to move it again later?!?!
: Personally, I use mode-x, update a non-visible VGA area, and
: change the display start address.
: I can easily do a lot of scrolling and sprite moving at 60 fps.
Well, with an offscreen buffer I can easily do 70fps... :)
Remember that when drawing in videoram your writes are several
times slower than memory writes. Which again means if you have
a lot of writing on the same pixel (i.e. several sprites over
each other or depth sorted polygons) your X-mode implementation
will be very slow compared to the memwrite methode. If you don't
use a lot of drawing on top of eachother you might be better off
with your X-mode implementation as you don't have to copy a
whole offscreen onto videmem after.
Take the example when you want to scroll only a part of the screen one
pixel in any direction. Your X-mode implementation would probably
be very slow compared to a simple move of data in memory. Reading
and writing from videomem is far too slow, so you eventually end
up redrawing the whole screen with offset fetches and pretty
heavy code to do a simple thing.
I've used both X-mode and mode 13h and found that X-mode requires
pretty much work compared to the mode 13h. Eventually the payoff
isn't worth it.. a lot of the time there is no payoff at all.
Of course in X-mode you have the advantage of the cool resolutions.
The twisted 13h 320x200 aspect ratio can sometimes be a pain.
Regards,
John
--
------------------------------------------------------------------------------
John Christian Lonningdal | Web: http://www.himolde.no/~lonning
John.C.L...@himolde.no | Address: BOX 1841, Mek / N-6401 MOLDE / NORWAY
------------------------------------------------------------------------------
Get JOBE 1.3 a sprite editor at http://www.himolde.no/~lonning/jobe.htm
Try out FUSECUTTER! Get it at http://www.himolde.no/~lonning/fusecut.htm
Dr. Cat
: I love it!
: Here we are again in ModeX vs Mode13 !
: We have been here before, people....We agreed to differ, as I recall.
It seems to me a VERY moot point anyway. As they are both much lower
resolution and worse looking than SVGA modes (640*480*256 and up). The
only reason to use any 320*200 or 320*240 mode is that some people still
have machines that are too slow to do some types of games at higher
resolutions. And this is NOT going to be the case for much longer. So
any argument about ModeX vs Mode13 sounds to my ears like:
"In the twilight years of low resolution modes, how should the last
few games for those modes be made?"
Doesn't strike me as hugely important. Five years from now nobody will
care, all PC games will be in SVGA anyway.
***********************************************************************
Dr. Cat / Dragon's Eye Productions ** Come play DragonSpires!
******************************************** ftp.eden.com pub/dspire
Dragonspires is a graphic mud for PCs. ** has everything you need!
***********************************************************************
** http://www.realtime.net/~gauntlet/dspire.html for more info **
***********************************************************************
Ryan Drake
: >I'd check your sources before stating something like this!
: I read it in the current issue of Dr. Dobbs sourcebook in M. Abrash's
: article on BSP rendering. Right from the horses mouth.
Yup. I asked him about some mode-X techniques and the libs he is using for
Quake, and he responded with:
"All the code in Quake is written from scratch, and we're not really all
that Mode X optimized anyway; we draw to a buffer and blt to the Mode X
screen, rather than deal with the mess of drawing directly to the
Mode X bitmap."
--
+-------------------------------------------------------------------------+
| Ryan Drake "The woods are lovely, dark and deep, |
| [EMAiL] stil...@psu.edu but I have promises to keep |
| [URL] To be announced and miles to go before I sleep."|
+-------------------------------------------------------------------------+
uglm...@cc.memphis.edu
Actually, this is quite workable and makes use of techniques similar to those
used by zbuffering. The trick is that, for certain types of drawing, the
bank switching will still kill you.
Chris Gouldie
scho...@wrcs1.urz.uni-wuppertal.DE (Van Schoenepauck) wrote:
>As far as *I* know (please correct me if I'm wrong), using REP MOVS*
>is NOT the fastest way, at least on a Pentium, as the string ops are not
>optimised on that processor. MOV/DEC/JNZ is faster. And loop unrolling
>yields an even better performance.
On a pentium. But on the ever so popular 486, repmovsd can actually be
faster than the super optimized sequence, at least according to what I've
read.
George Morrison
would be a discussion of the advantages and disadvantages of each mode.
Maybe we could have some professionals tell us which mode they used for
their games (and why).
--
George Morrison
u05...@abdn.ac.uk
http://www.abdn.ac.uk/~u05gdm
Mark Wilczynski
: Obviously, this isn't a complete comparison, but it demonstrates
: well that in any system where the video memory is slower to
: access than the system memory (which is basically EVERY system)
: there are certain game designs which will clearly benefit
: from having a double buffer in system memory.
Doug, you're wrong here! I just tested your theory on my P90
with a PCI Stingray Pro card. Doing a C memcpy() where the
source and destination buffers are in system memory got 20 MB/s.
Doing a memcpy() from a buffer in main ram to a buffer in
video ram got 36 MB/sec! Your assuming things based on how
slow video cards used to be years ago. A "good" modern local bus
card is often faster for writes. (video mem is still slower for
reads). By the way, I checked the C compiler output (Prot. Mode)
and it turns those memcpy() into movsd so you can't get any
faster.
This really surprised me, 20 MB/sec on a P90!!??? That really
sucks! Intel should really work on their memory controllers
instead of the CPU's. Can someone out there try this benchmark
on their machine? Please use a 1MB buffer for both source
and destination (may be hard if you don't have linear frame buffer
support) as this gives real world speeds not inflated by mem
caches.
Chris Softley
How come no-one has mentioned the vertical retrace yet?
One big advantage of buffering is that you can do your time consuming
processing to the buffer whilst the screen is tracing, then blast it
over using a synchronized int 1C or int 8 handler to the video card
during the retrace. The advantages are:
- Less 'flicker' & no half redrawn screens
- Writes to video ram during the reatrace are faster on many VGAs than
writes during tracing as the picture generating logic doesn't have
to read the RAM you're trying to write to.
>>-Chris->
Prlkovsky
Are writes to offscreen video memory also faster during the vsync retrace ?
\|||/
>|- o|< I was never sure about anything anyway...
-----oo0 U -Ooo----------------------------------------------------
Prlkovsky
---------------------------------------------------------------------
CM Killpack
[snip]
: Doesn't strike me as hugely important. Five years from now nobody will
: care, all PC games will be in SVGA anyway.
I don't agree with this statement at all. Reading this statement
sounds like you are putting SVGA as the answer to all the problems about
tradeoffs between Mode X and 13h. Well SVGA has its own bottlenecks in
performance terms as well, mainly that you have to carry out
page-flipping. The solution has always been (in my case) to render to a
flat bitmap and then blast it across to video memory in pages. However you
have to go through the VESA (BIOS) to switch pages. This is slow when you
are talking about trying to push 640x480 bytes to the screen as quickly as
possible through the data bus. The only way to optimise in this case was
to either:
(1) Set the pages directly on the video card,
(2) Use linearly mapped screen memory (only available as a result of VESA
2.00 and newer cards)
(3) Use Win'95
Well the first two are nonstandard so they go out the window
unless you fancy writing all the different drivers for different SVGA
cards and the third, well that should have happened about 3 years ago.
So as it remains, with the main market still on 486's which don't have
33Mhz PCI buses needed to shift the data around at an acceptable speed,
nor the processing power to handle the rendering of 640x480 pixels on the
screenat an acceptable rate then SVGA remains obsolete except for static
screens.
Mode-X or Mode 13h are still the only viable options for
high-frame rate graphics and believe me I know all about tweaked video modes.
Chris Killpack
Sam Vincent
: Dr. Cat (c...@bga.com) wrote:
: [snip]
: : Doesn't strike me as hugely important. Five years from now nobody will
: : care, all PC games will be in SVGA anyway.
: I don't agree with this statement at all. Reading this statement
: sounds like you are putting SVGA as the answer to all the problems about
: tradeoffs between Mode X and 13h. Well SVGA has its own bottlenecks in
: performance terms as well, mainly that you have to carry out
: page-flipping. The solution has always been (in my case) to render to a
: flat bitmap and then blast it across to video memory in pages. However you
: have to go through the VESA (BIOS) to switch pages. This is slow when you
: are talking about trying to push 640x480 bytes to the screen as quickly as
: possible through the data bus. The only way to optimise in this case was
: to either:
: (1) Set the pages directly on the video card,
: (2) Use linearly mapped screen memory (only available as a result of VESA
: 2.00 and newer cards)
: (3) Use Win'95
: Well the first two are nonstandard so they go out the window
: unless you fancy writing all the different drivers for different SVGA
: cards and the third, well that should have happened about 3 years ago.
: So as it remains, with the main market still on 486's which don't have
: 33Mhz PCI buses needed to shift the data around at an acceptable speed,
Oh.. you're right... My vlb is only running at 50mhz.. guess I need
to upgrade to PCI...
: nor the processing power to handle the rendering of 640x480 pixels on the
: screenat an acceptable rate then SVGA remains obsolete except for static
: screens.
Oh.. damn.. right again.. my 486/120 is much slower at integer processing
than your Pentium. My system is obsolete as you say.
: Mode-X or Mode 13h are still the only viable options for
: high-frame rate graphics and believe me I know all about tweaked video modes.
"are" = right now. He was speaking of about 5 years from now.
: Chris Killpack
[ yeah, anyone who knows anything will realize my bus is running at 40mhz
in reality.. but I could easily set it to 50mhz and clock double my cpu to
100 mhz.. (or try for 2.5 times for 125mhz) ]
--
==============================================================================
Microsoft Network, or any service owned in full or in part by Microsoft, is
prohibited from redistributing this work in any form, in whole or in part.
Copyright, Samuel A. Vincent, 1995. License to distribute this post is
available to Microsoft for US$1,000 per instance, or local equivalent.
Posting without permission constitutes an agreement to these terms. Please
send notices of violation to svin...@zippy.sonoma.edu and
postm...@microsoft.com.
==============================================================================
Jason Doucette
Mode X is the best mode to use if your rendering engine does not plot
mutiple values to the same pixel. Games like Doom are like this, which is
why I don't uderstand why heretic uses mode 13h..? Mode X is also good
for drawing single color polygons, since 16 pixels can be written with
the same color, where only 4 can be done in mode 13h. Gouraud shading can
even take advantage of this, for large polygons, you don't have to have
single pixel accuracy. Clearing the screen is 4 times faster in Mode
X, as well. Mode X offers absolutely no flickering, if you program it
right. A disadvantage is that some algorithms slow sown if you program
them for mode X, like texture mapping. but you can always optimize these.
Who says you have to fill in each adjacent pixel consecutively when
texture mapping? Fill in every fourth, then change which plane to write
to, and fill in the missing, the vectors used to scan the bitmaps remain
the same. Mode X easily offers 320x400 mode, and other resolutions which
aren't gauranteed to work on all cards, but who cares. Mode X normally
has 4 pages (320x200 since we're comparing it with mode 13h), allows
hardware scrolling as well as split screens.
Mode 13h is definately the easiest to program. You don't have to know
about double/triple buffering, but this results in flickering. Copying
the buffer to video memory should not take 50% of your processing time. I
timed this on an old 486 Dx-50 with a really shitty Trident card, and I
got 50% of the processing time...My S3 card right now goes 563% the speed
of my old trident card on a 486 Dx2-66. You should use mode 13h if your
engine is infinitely easier to program in a linear addressing mode, and
you don't care about flicker, or if your engine has a lot of
overlapping...although if this is the case, optimizing what is drawn
should be possible...
--
Jason Allen Doucette
Saw Tooth Distortion
--------------------
019...@axe.acadiau.ca
Doug McCreary
> Doug, you're wrong here! I just tested your theory on my P90
> with a PCI Stingray Pro card. Doing a C memcpy() where the
> source and destination buffers are in system memory got 20 MB/s.
> Doing a memcpy() from a buffer in main ram to a buffer in
> video ram got 36 MB/sec! Your assuming things based on how
> slow video cards used to be years ago. A "good" modern local bus
> card is often faster for writes. (video mem is still slower for
> reads). By the way, I checked the C compiler output (Prot. Mode)
> and it turns those memcpy() into movsd so you can't get any
> faster.
Well, certainly the reverse case is true if you have
a system where the VGA memory is faster than the
system memory. In my opinion there may be a couple of
issues which make your test invalid:
1) As you mentioned, you used 1MB blocks. This is
unrealistically large for current games. Even at
33MB/sec this would represent a frame rate of only
33fps, which would be unacceptably slow to many game
designers. While your test voids the memory cache,
it probably shouldn't, as the cache does impact
the memory subsystem performance in real game usage.
2) A blanket memcpy() is only valid for mode13, so
you really need a double-buffer for that mode anyway.
In any case, I'll pull out the bandwidth test program
I wrote a while ago which helped me decide to go with
double-buffer in the first place. Then I'll have to
see if I can find a P90 to run it on. Remember,
as another issue, many of us are still coding to
support the (millions) of 486 class machines out
there. Performance on absolutely top of the line
machines is more important to high-end game designers
with (among other things), budgets. :)
--doug
see my game, gladiator
http://www.ictv.com/~mike
uglm...@cc.memphis.edu
The trick is that 13h is faster than X if you draw a large number of
discrete primitives (like polygons). At best you would normally do one OUT
per vertical scanline per polygon. That can still be a lot of OUTs.
Brian Buie
BB> >is NOT the fastest way, at least on a Pentium, as the string ops
BB> >optimised on that processor. MOV/DEC/JNZ is faster. And loop unro
BB> >yields an even better performance.
BB>
BB> On a pentium. But on the ever so popular 486, repmovsd can
BB> actually be faster than the super optimized sequence, at least
BB> according to what I've read.
On the 386 the rep movsd is the fastest, but on a 486 or pentium the
mov, dec, jnz is faster than the rep movsd, at least on all the
different processors I tested. The mov, dec, jnz was just a little
slower on the 386 than the rep movsd by about .09 seconds for 1000
frames. Well I hope this clears up some of the confussion.
Rainer Deyke
: What would be more useful than this bickering (especially to newbies like me :)
: would be a discussion of the advantages and disadvantages of each mode.
: Maybe we could have some professionals tell us which mode they used for
: their games (and why).
Mode X:
lots of possible resolutions including square pixels
page flipping in video memory
hardware scrolling
fast clear screen
relatively fast flat polygons
relatively fast vram-to-vram copies
harder to program
mode 13h:
320x200 resolution (square pixels possible by leaving top and bottom blank)
requires 64K main memory for page flipping
almost always faster
--
+----------------------------------------------+
| Rainer Deyke (rai...@mdddhd.fc.hp.com) |
| "The Earth shall inherit the meek" - Carcass |
+----------------------------------------------+
uglm...@cc.memphis.edu
> In article <49fs4c$8...@wmwap1.math.Uni-Wuppertal.DE>,
> scho...@wrcs1.urz.uni-wuppertal.DE (Van Schoenepauck) wrote:
>>is NOT the fastest way, at least on a Pentium, as the string ops are not
>>optimised on that processor. MOV/DEC/JNZ is faster. And loop unrolling
>>yields an even better performance.
>
> faster than the super optimized sequence, at least according to what I've
> read.
Not normally. 486s and Pentiums are both usually better, since you can't
unroll a REP.
uglm...@cc.memphis.edu
> Hi,
> How come no-one has mentioned the vertical retrace yet?
> One big advantage of buffering is that you can do your time consuming
> processing to the buffer whilst the screen is tracing, then blast it
> over using a synchronized int 1C or int 8 handler to the video card
> during the retrace. The advantages are:
> - Less 'flicker' & no half redrawn screens
> - Writes to video ram during the reatrace are faster on many VGAs than
> writes during tracing as the picture generating logic doesn't have
> to read the RAM you're trying to write to.
>
>
>
You get that either way.
Neil Graham
>
>Here are my thoughts: Add to them, if you like.
>
>Mode X is the best mode to use if your rendering engine does not plot
>mutiple values to the same pixel. Games like Doom are like this, which is
>why I don't uderstand why heretic uses mode 13h..?
> [other pros/cons of modex/Mode13 removed]
Quite well put. I think it is unwise for people to make a blanket statement
about the mode people should use. My most recent game uses ModeX because It
has a black background and I can clear the background at high speed. I'm
looking at two different projects next, one will be modeX, one will be mode13
The decicion involved considering the style of view, the level of the target
machine and the level of complexity of the game.
If you are coding assuming local bus then you can assume that a mode16 64k blit
will go through in less than a frame. And mode13's easier addresing makes new
effects much quicker to generate. Imagine a image scrolling across warping the
background like the predator effect. With modeX you end up reading from video
memory and also changing which plane you are reading and writing to in a rather
complex manner that is not easy to code for. in mode13 you can just use simple
look up delta's and read from one and write to the other. Other effects like
this, while possible, are difficult to code and place more of a gap between
what you want to achieve and what you have the resources to do.
Neither Mode13 or modeX are better for all purposes, Use the one that will
achieve the result you desire. The main thing to consider is 'what level
machine am I going to write for'. A game written for a p90 should be more
impressive than one written for a 386sx but requires a p90 to work properly.
Once you assume a base level higher than about 486dx2-50 with local bus
the limitations of modex addressing get in the way causing performace
degridation. below this specification you live with the limitations because
thats all you have.
Thomas Nielsen
>C.H.Skilbeck (he...@prog.demon.co.uk) wrote:
>: I love it!
>
>: Here we are again in ModeX vs Mode13 !
>
>: We have been here before, people....We agreed to differ, as I recall.
Sorry :) .. I wasn't on this conference then. But anyway, I am glad so
many people felt provoked when I said that blittering to VGA is lame.
As I wrote then, I realize that blittering from a buffer to VGA can be an
advantage. I do not believe I am superior to people using Mode13, and I
agree with the guy who wrote that you should use whatever method solves
your problem best.
But.. Blittering to VGA DOES take up processor time.. A LOT of time. And
when some of you write that "this can be done extremely fast", you are
wrong! Atleast I do not think that using anywhere from 20%-50% of the
processor time to move data from one point to another is "extremely
fast".
Anyway, what I mean is.. When we get to the point where PC's are fast
enough to update a full screen and transfer this to VGA 70 times per
second, we can all go ahead and use off-screen buffers like mad. Because
it IS the easiest way.
But as long as PC's are not that fast, you really need to consider which
method to use before programming screen update routines - And not just
use off-screen buffering because it is easy. Make an efford.
>It seems to me a VERY moot point anyway. As they are both much lower
>resolution and worse looking than SVGA modes (640*480*256 and up). The
>only reason to use any 320*200 or 320*240 mode is that some people still
>have machines that are too slow to do some types of games at higher
>resolutions. And this is NOT going to be the case for much longer. So
>any argument about ModeX vs Mode13 sounds to my ears like:
>
> "In the twilight years of low resolution modes, how should the last
> few games for those modes be made?"
>
>Doesn't strike me as hugely important. Five years from now nobody will
>care, all PC games will be in SVGA anyway.
REALITY CHECK!!
You are talking 5 years form now!! Ofcourse games will be SVGA in 5
years, but I am NOT going to wait 5 years to release my game.
Fact is that a LOT of people have 486 machines today, and you can NOT
write playable super-vga games for 486 machines.
Thomas Nielsen.
Progressive Media.
NUL
mcd> Due to the fact that typical cheap Video RAM is extremely slow,
Video RAM isn't as slow as some people think. Look at these transfer stats:
Data flow and bus performance video
[Cache] [time] [throughput]
-- video -> CPU ----------
Maximum 4K LODSD (hits) : 272.4#s ( 18241c) => 15.0MB/s (4.45c/Byte)
Minimum 4K LODSD (misses) : 272.4#s ( 18237c) => 15.0MB/s (4.45c/Byte)
-- CPU -> video ----------
4K STOSD : 122.3#s ( 8191c) => 33.5MB/s (2.00c/Byte)
-- memory -> video -------
Maximum 4K MOVSD (hits) : 125.3#s ( 8392c) => 32.7MB/s (2.05c/Byte)
4K MOVSD (miss+hit) : 176.1#s ( 11790c) => 23.3MB/s (2.88c/Byte)
4K MOVSD (clean) : 272.4#s ( 18241c) => 15.0MB/s (4.45c/Byte)
Minimum 4K MOVSD (misses) : 272.4#s ( 18237c) => 15.0MB/s (4.45c/Byte)
-- video -> memory -------
Maximum 4K MOVSD (hits) : 459.0#s ( 30732c) => 8.9MB/s (7.50c/Byte)
Minimum 4K MOVSD (misses) : 376.2#s ( 25193c) => 10.9MB/s (6.15c/Byte)
-- video -> video --------
Maximum 4K MOVSD (hits) : 436.6#s ( 29232c) => 9.4MB/s (7.14c/Byte)
Minimum 4K MOVSD (misses) : 459.4#s ( 30760c) => 8.9MB/s (7.51c/Byte)
[These test where conducted on a 486DX2-66 (256K L2 cache) with a ET4000/w32p-based VLB video card]
As you can see, blitting from the CPU to video RAM is faster than from main memory to video RAM. You only really suffer a performance hit when reading from video RAM to either main memory or the CPU.
_______________________________________________________________________________
|'My greatest fear: that future generations|Comments in this message may not |
| will, for some reason, refer to me as an |reflect the views of any rational |
| "optimist."' - Chad Irby |person. |
|__InfoSeek________________________________|___________________________SUCKS__|
--
| Fidonet : NUL 1:250/820
| Internet: N...@TCSconcordia.tor250.org
Michael Carmack
: c...@bga.com (Dr. Cat) wrote:
: >Doesn't strike me as hugely important. Five years from now nobody will
: >care, all PC games will be in SVGA anyway.
: REALITY CHECK!!
: You are talking 5 years form now!! Ofcourse games will be SVGA in 5
: years, but I am NOT going to wait 5 years to release my game.
: Fact is that a LOT of people have 486 machines today, and you can NOT
: write playable super-vga games for 486 machines.
Maybe not super-fast action games, but RPGs and adventure games can easily
run in SVGA on a 486 because they don't require the insane frame rates of
an arcade-style game. And since they invariably use a lot of text, SVGA
is better; it's very hard to read words in standard VGA modes.
--
========================================================================
"In sports, it's not who wins or loses; | Mike Carmack
it's how drunk you get." | mcarmack@freenet.
- Homer Simpson | columbus.oh.us
uglm...@cc.memphis.edu
> c...@bga.com (Dr. Cat) wrote:
>
>>C.H.Skilbeck (he...@prog.demon.co.uk) wrote:
>>: I love it!
>>
>>: Here we are again in ModeX vs Mode13 !
>>
>>: We have been here before, people....We agreed to differ, as I recall.
>
> Sorry :) .. I wasn't on this conference then. But anyway, I am glad so
> many people felt provoked when I said that blittering to VGA is lame.
>
> As I wrote then, I realize that blittering from a buffer to VGA can be an
> advantage. I do not believe I am superior to people using Mode13, and I
> agree with the guy who wrote that you should use whatever method solves
> your problem best.
>
> But.. Blittering to VGA DOES take up processor time.. A LOT of time. And
> when some of you write that "this can be done extremely fast", you are
> wrong! Atleast I do not think that using anywhere from 20%-50% of the
> processor time to move data from one point to another is "extremely
> fast".
Most of that time is spent in the VGA access. You'd still be wasting the same amount of
time for each access if you drew directly in screen RAM, but you frequently end up doing
MORE accesses. How is this faster?
At the same time, in cases where you don't overwrite pixels often, page-flipping can be
a useful technique.
>
> Anyway, what I mean is.. When we get to the point where PC's are fast
> enough to update a full screen and transfer this to VGA 70 times per
> second, we can all go ahead and use off-screen buffers like mad. Because
> it IS the easiest way.
> But as long as PC's are not that fast, you really need to consider which
> method to use before programming screen update routines - And not just
> use off-screen buffering because it is easy. Make an efford.
I use it because it's faster for my purposes.
>
>
>>It seems to me a VERY moot point anyway. As they are both much lower
>>resolution and worse looking than SVGA modes (640*480*256 and up). The
>>only reason to use any 320*200 or 320*240 mode is that some people still
>>have machines that are too slow to do some types of games at higher
>>resolutions. And this is NOT going to be the case for much longer. So
>>any argument about ModeX vs Mode13 sounds to my ears like:
>>
>> "In the twilight years of low resolution modes, how should the last
>> few games for those modes be made?"
>>
>>Doesn't strike me as hugely important. Five years from now nobody will
>>care, all PC games will be in SVGA anyway.
>
> REALITY CHECK!!
>
> You are talking 5 years form now!! Ofcourse games will be SVGA in 5
> years, but I am NOT going to wait 5 years to release my game.
> Fact is that a LOT of people have 486 machines today, and you can NOT
> write playable super-vga games for 486 machines.
Depends on the type of game, and whether you have linear access to the video RAM, among
other things.
>
>
> Thomas Nielsen.
> Progressive Media.
>
--
"Hello, Psychic Friends Network? Well, I don't really care about my future,
but could you give me the Classic Sub Zero UKK?"
NIGEL HUGHES
Why would you have to do that? Any of the drawing operations in my ModeX
library involve 4 outs no matter what size the object being blitter or
the polygon or line being rendered is. Yes this is slower than 13h by 4 outs
but I can also use some "features" of ModeX to get that back.
Nigel Hughes
Loon P. van
REALITY CHECK!!
You are talking 5 years form now!! Ofcourse games will be SVGA in 5
years, but I am NOT going to wait 5 years to release my game.
Fact is that a LOT of people have 486 machines today, and you can NOT
write playable super-vga games for 486 machines.
Thomas Nielsen.
Progressive Media.
Maybe this is a little off-topic, but you *CAN* write very playable
svga games. I like the Settlers very much, especially in svga mode,
and it's a *VERY* playable game. I like it a lot more attractive than
most 'fast' 3D blast-those-nasties-away games with little gameplay
whatsoever.
But you're probably right if you're talking about VR-like games
or parallax scrollers.
Greetings from Paul.
--
: standard-disclaimer ." All my opinions are strictly my own" ; smudge \ ;)
--> ( vanl...@iclab.ce.philips.nl)
.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
^ [] Paul van Loon .-. .-. v
^ [] [] ___\/___ v
^ [] Bought by the Lamb, ~~~~~~~~ v
^ [] freed by the Word v
*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.
Thomas Nielsen
>>In article <4a25q4$p...@news.iesd.auc.dk> Thomas Nielsen <Thomas_...@online.pol.dk> writes:
>>
>> Fact is that a LOT of people have 486 machines today, and you can NOT
>> write playable super-vga games for 486 machines.
>Maybe this is a little off-topic, but you *CAN* write very playable
>svga games. I like the Settlers very much, especially in svga mode,
>and it's a *VERY* playable game. I like it a lot more attractive than
>most 'fast' 3D blast-those-nasties-away games with little gameplay
>whatsoever.
>
>But you're probably right if you're talking about VR-like games
>or parallax scrollers.
>
>Greetings from Paul.
Sorry.. Ofcourse I did mean games with heavy animated graphics
like big sprites.. I agree that there ARE playable SVGA action
games. But no actiongames with smoothscrollers and the likes.
Thomas Nielsen
Progressive Media.
Eric Jorgensen
:> In article <4a25q4$p...@news.iesd.auc.dk> Thomas Nielsen <Thomas_...@online.pol.dk> writes:
:> REALITY CHECK!!
:> You are talking 5 years form now!! Ofcourse games will be SVGA in 5
:> years, but I am NOT going to wait 5 years to release my game.
:> Fact is that a LOT of people have 486 machines today, and you can NOT
:> write playable super-vga games for 486 machines.
BZZT! Go and check out the beta of Varmint's EITtris:
http://www.rt66.com/smeagol/html/eittris.html
It is a 4-player tetris clone and It uses 800x600 SVGA graphics (using the
SVGACC library). On top of that, it also has animations and sound mixing
in the background.
I have also written more action oriented games in SVGA and about the only
thing I can say is that SVGA is great for games and the only thing you
really can't do well with it right now is scroll a background.
-e
--------------- My WEB page: http://www.rt66.com/smeagol/ --------------------
--------- Ground Up: http://www.rt66.com/smeagol/html/groundup.html ----------
Clay Hellman
If you are doing a game that is expected to run on a 386, that doesn't
have custom routines for each processor, you should go with the REP
MOVSD instead of the optimized loop. This is because when run on a
386, that is when the speed is needed the most, and its fastest this
way on a 386. The optimized loop might be faster on a 486/Pentium,
but the fastest possible speed isn't needed as much on these faster
processors as much as its needed on the slower 386.
Clay.
Peter Breitling
> memory to video RAM. You only really suffer a performance hit when reading
> from video RAM to either main memory or the CPU.
What is the difference between 'blitting from the CPU to video RAM' and
'blitting from memory to video RAM' ?
Cheers,
Peter
--
__ __
/__) \_)reitling * brei...@informatik.tu-muenchen.de irc://LooL / (
( eter )__) * http://www.informatik.tu-muenchen.de/~breitlip/ (_Oo\_
Propel Interactive
Thomas Nielsen <Thomas_...@online.pol.dk> wrote:
>vanloonp@server12 (Loon P. van) wrote:
>
>>>In article <4a25q4$p...@news.iesd.auc.dk> Thomas Nielsen <Thomas_...@online.pol.dk> writes:
>>>
>>> Fact is that a LOT of people have 486 machines today, and you can NOT
>>> write playable super-vga games for 486 machines.
>
>>svga games. I like the Settlers very much, especially in svga mode,
>>and it's a *VERY* playable game. I like it a lot more attractive than
>>most 'fast' 3D blast-those-nasties-away games with little gameplay
>>whatsoever.
>>
>>But you're probably right if you're talking about VR-like games
>>or parallax scrollers.
>>
>>Greetings from Paul.
>
>Sorry.. Ofcourse I did mean games with heavy animated graphics
>like big sprites.. I agree that there ARE playable SVGA action
>games. But no actiongames with smoothscrollers and the likes.
>
>Thomas Nielsen
>Progressive Media.
>
>
>
>
I understand Activision's Pitfall game runs in 640x480x256 mode. I haven't
seen it running (yet), but my friends tell me that it's not bad, and the
package art looks like it's an arcade scroller. So I'd think it _can_ be
done somehow. Also, what I've seen of Wing Commander III looks like it's
in a higher resolution mode than 320x240 (at least the video clips).
uglm...@cc.memphis.edu
Well, I suppose you could draw the polygon in main RAM and blit it by
itself, but then your better off blitting the whole screen in one shot.
Otherwise, I can't see how to do texture-mapping with good performance.
Chris Rossall
>
>In article <1995Dec...@msuvx1.memphis.edu>,
uglm...@cc.memphis.edu writes
>:
>> In article <1995Dec3.2...@relay.acadiau.ca>, Jason Doucette
>e.acadiau.ca> writes:
>
>> The trick is that 13h is faster than X if you draw a large number of
>> discrete primitives (like polygons). At best you would normally do one
OUT
>> per vertical scanline per polygon. That can still be a lot of OUTs.
>
>Why would you have to do that? Any of the drawing operations in my ModeX
>library involve 4 outs no matter what size the object being blitter or
>the polygon or line being rendered is. Yes this is slower than 13h by 4
outs
>but I can also use some "features" of ModeX to get that back.
>
>Nigel Hughes
I would be very interested in seeing your line routine that only uses 4
outs.I have thought a little about doing one myself but i haven't
succeeded in doing a bresenham line without doing 1 out per pixel
-Chris
Paul Hsieh
: >care, all PC games will be in SVGA anyway.
: You are talking 5 years form now!! Ofcourse games will be SVGA in 5
: years, but I am NOT going to wait 5 years to release my game.
: write playable super-vga games for 486 machines.
Uhhh ... you guys maybe want to wake up and smell the coffee? *ALL* new
games now of any importance are supporting SVGA. 5 years from now we'll
be supporting something entirely different (HDTV or something perhaps.)
SVGA is *here* right now! Go out and get yourself a copy of Terminal
Velocity, or Wing Commander III, or NASCAR. *All* pentiums can deal with
SVGA. Fallback to mode 13h or frame dropping exists as alternatives to
the vastly shrinking 486 market. But the days of Mode 13h and Mode X are
waining.
--
Paul Hsieh
q...@xenon.chromatic.com
What I say and what my company says is not always the same thing
John C. Lonningdal
Distribution: world
Chris Rossall (chris....@mailbox.swipnet.se) wrote:
: I would be very interested in seeing your line routine that only uses 4
: outs.I have thought a little about doing one myself but i haven't
: succeeded in doing a bresenham line without doing 1 out per pixel
I remember a year ago when I was doing a polygon fill routine I
had problems with these outs at the beginning and end of the
polygon. I solved it simply by putting the offsetaddress (screen) in
different lists, one for each masksetting (and therefore one list for
each out). I then only filled the all-bitplane-masked pixels (16
pixels at a time) in the drawing routine. After that I ran through
the lists setting one out at a time (for each list). This way I
saved lots of outs. This way I got away with 6 outs (masks 0001 0011 0111
1000 1100 1110) + one for all-plane-masks (1111).
I bet you can use this in your bresenham also. Make a list of the
different outs and put the bresenham result pixel address in the lists
instead of putting them on the screen. Then spin throught the lists one
at a time using the respective out. This will be faster than using
outs for each pixel, depending on the line lenght.
Regards,
John
--
------------------------------------------------------------------------------
John Christian Lonningdal | Web: http://www.himolde.no/~lonning
John.C.L...@himolde.no | Address: BOX 1841, Mek / N-6401 MOLDE / NORWAY
------------------------------------------------------------------------------
Get JOBE 1.3 a sprite editor @ http://www.himolde.no/~lonning/jobe/jobe.htm
Try out FUSECUTTER! @ http://www.himolde.no/~lonning/fusecut/fusecut.htm
jvc
p8...@jupiter.sun.csd.unb.ca (Saulnier) wrote:
>Mark Wilczynski (mwil...@romulus.rutgers.edu) wrote:
>: In <30BB5C21...@ictv.com>, Doug McCreary <do...@ictv.com> wrote:
>: : Obviously, this isn't a complete comparison, but it demonstrates
>: : well that in any system where the video memory is slower to
>: : access than the system memory (which is basically EVERY system)
>: : there are certain game designs which will clearly benefit
>: : from having a double buffer in system memory.
>
>: Doug, you're wrong here! I just tested your theory on my P90
>: with a PCI Stingray Pro card. Doing a C memcpy() where the
>: source and destination buffers are in system memory got 20 MB/s.
>: Doing a memcpy() from a buffer in main ram to a buffer in
>: video ram got 36 MB/sec! Your assuming things based on how
>: slow video cards used to be years ago. A "good" modern local bus
>: card is often faster for writes. (video mem is still slower for
>: reads). By the way, I checked the C compiler output (Prot. Mode)
>: and it turns those memcpy() into movsd so you can't get any
>: faster.
>
>: sucks! Intel should really work on their memory controllers
>: instead of the CPU's. Can someone out there try this benchmark
>: on their machine? Please use a 1MB buffer for both source
>: and destination (may be hard if you don't have linear frame buffer
>: support) as this gives real world speeds not inflated by mem
>: caches.
>
>Then there's the weird trick that on a Paradise and S3 cards I tested
>movsd and movsw from mem to video, the movsw was faster. And yes, the
>memory was on a dword boundary. I've heard that this happens on other cards
>as well.
>
I tested this on a P90 with an ATI video card. The results are:
27 M per second system to system memory.
40 M per second system to video memory.
All memory accesses are 32 bit aligned and movsd is used.
BTW: system to video drops down to 15 Mps if memory access is not 32 bit
aligned. :-(
Andrew Tjew @ JVC Games
Ivan Ganza
I just stumbled upon this article and something came to mind.
When you were doing these test did you sinc the Retrace of the Video
Card? Memory copies from RAM to Video Memory should be much faster if
you only copy when no retrace in happening, since the Video Card will
not impose a wait state.
I've had a 150x150 bitmap flying at 120 frames per second on a
DX2/66 with background replacement with some optimized assembly code and
VSYNC checking. This was on a Cirrus Logic with 1 MEG, not your
greatest card.
Paul Kmiec
>BTW: system to video drops down to 15 Mps if memory access is not 32 bit
>aligned. :-(
How would I go about aligning my "chunk" of memory on a double word
boundry in c/c++?
Paul
Ivan Ganza
I have to agree, SVGA is the ONLY way to go now a days. Almost evey
game if have bought lately is in SVGA!
Bryan Larsen
uglm...@cc.memphis.edu wrote:
>In article <dindiaDI...@netcom.com>, din...@netcom.com (John Paul
D'India) writes:
>> : And if you know what you're doing, you won't write more than once each
pixel
>> : on the screen!
>>
>> Uhm, either you're a genius, or you're not thinking about what you're
>> saying. Are you trying to tell me that if you're scrolling the screen
>> around, and you're moving some sprites around, that while updating the
>> background, you don't copy certain pixels because you know that a sprite
>> will be overlapping it?
>>
>Actually, this is quite workable and makes use of techniques similar to those
>used by zbuffering. The trick is that, for certain types of drawing, the
>bank switching will still kill you.
Yeppers, my engine does this -- no pixel is written more than once, and no
background pixel that doesn't need to be redrawn isn't. Sure it adds some
overhead and is the wrong way to do it on 486/33 VLB, but it sure screams on
ISA bus cards and on Pentiums at high resolution!
Its actually not too complicated -- its a simple scan line system, so it'd
work well on ModeX also.
What do you mean by the bank switching killing? My system switches banks
optimally.... (in high res modes. In modeX it would do an out once per scan
line)
Bryan
=====================================================================
Life is like Calvinball -- you make the rules.
Bryan Larsen, University of Regina Electronic Systems Engineering
In Japan on a work term for Ricoh Company, Ltd.
I do not speak for either organization. Gambarimashoo!
=====================================================================
NIGEL HUGHES
> k...@mn5.swip.net>
> Distribution: world
>
> Chris Rossall (chris....@mailbox.swipnet.se) wrote:
> : I would be very interested in seeing your line routine that only uses 4
> : outs.I have thought a little about doing one myself but i haven't
> : succeeded in doing a bresenham line without doing 1 out per pixel
Sorry I have been away, I have just got your mail as well.
> saved lots of outs. This way I got away with 6 outs (masks 0001 0011 0111
> 1000 1100 1110) + one for all-plane-masks (1111).
You only need 3 or less outs in all for a horizontal line. Worst case is one
for the first 4 pixels, one for the last four and $f covers the rest.
I was being a little brutish about arbitary line drawing, the routine I have
results in between 1 (optimal) and 10 outs for any line. It obvisously involves
a little more precalc than a mode 13 routine, but then again, this can be
gained back with multiple pixel setting. It also watches for special cases
when it can BUUUUUUUURRRNNN, seeing as there are a range of special
cases I have found it to be pretty quick.
I think I might as well upload it to one of the ftp sites, as although it is
going into the games development system we are, um, developing, I am
sick of Mode13h coders without the imagination to see how ModeX can
be used to great effect. Yes I also code in Mode13h, I like both, which
ever best suits me. (Mode13 is a HELL of a lot easier to program really
effcient code for, but then ModeX rewards careful thinkers with excellent
performence).
It is in protected mode assembler, not a problem for people is it?
Nigel
uglm...@cc.memphis.edu
So I take you're using 2D scrolling? I can't think of any other use where you don't have to
clear the screen... Anyway, it seems most of the people on this newsgroup today are doing
3D texture-mapping--something where fast Mode-x graphics becomes VERY difficult.
Eric SAMBACH
: Thomas Nielsen (Thomas_...@online.pol.dk) wrote:
: : c...@bga.com (Dr. Cat) wrote:
: : >Doesn't strike me as hugely important. Five years from now nobody will
: : >care, all PC games will be in SVGA anyway.
: : REALITY CHECK!!
: : You are talking 5 years form now!! Ofcourse games will be SVGA in 5
: : years, but I am NOT going to wait 5 years to release my game.
: : Fact is that a LOT of people have 486 machines today, and you can NOT
: : write playable super-vga games for 486 machines.
: Uhhh ... you guys maybe want to wake up and smell the coffee? *ALL* new
: games now of any importance are supporting SVGA. 5 years from now we'll
: be supporting something entirely different (HDTV or something perhaps.)
: SVGA is *here* right now! Go out and get yourself a copy of Terminal
: Velocity, or Wing Commander III, or NASCAR. *All* pentiums can deal with
: SVGA. Fallback to mode 13h or frame dropping exists as alternatives to
: the vastly shrinking 486 market. But the days of Mode 13h and Mode X are
: waining.
I am loath to say anything to continue this thread, but (you knew I was going
to say that eh? ;)), recently a few friends and I got together for a mini
Doom-Fest. One of the fella's had a P100. We played heaps of games, quite a
few of which supported SVGA (to my surprise). BUT!!! NONE of them had nearly
as fast a frame rate as mode 13h, and few looked much better anyway. Except
for Terminal Velocity, which I hear has two sets of textures, one lot of high-
resolution ones for SVGA, and a low-res set for VGA.
He ended up playing most of them in 320x200 because of the faster frame rate.
I'm not saying that it wasn't playable in 640x480, but it just wasn't as good.
At least, that was the case for polygon based games, maybe bitmapped games
look better...*shrug*.
Obviously the statement that "*All* pentiums can deal with SVGA" doesn't mean
that they deal with it well ;). And this was o a P100...I pity the poor
P60's out there ;).
Just a thought,
Alec Thomas => Forge Software
Chris Hargrove
>This is not about smelling the coffee.. This is about being realistic!!
>Game companies support SVGA in their games because they have to impress
>the game reviewers and the potential game buyers - Not because anyone
>plays the games in the SVGA modes. Gamers want all their games to
>support SVGA, but do they play the games in the SVGA modes? - No.. They
>want to show their friends how "good the game looks". I bet you when they
>want to actually PLAY the game, they go 320x200.
You're very right, at least in my apartment. Both my roomates are
avid gamers, one of whom played Descent with a passion and even ran
the Kali League for it for a while, so he's a good game-freak
representative. He looks at the 640x480, says "Wow, that's damn
sharp...", and then promptly goes back to 320x200 saying "... but this
is playable. If I tried to play in that hires, I'd be toast." I was
a pathetic frame rate. Granted, he's got a DX4/100, but it's PCI with
a Diamond Stealth 64 so he's not exactly on the *low* end of the
spectrum. If anything, he's middle to above average, considering the
common gamers.
Remember - the game freaks will upgrade their machines. But they are
a small percentage of the population, and you aim for mass market
appeal. That means work with the machines that they ALREADY HAVE.
You need to have a game as high up as Doom to get people to upgrade
just to play your game. Anyone else is not that important, and if the
game has insane requirements, it's going to be left on the shelf.
>I just wish this whole industry would stop being so pathetic, and
>finally realize that things are moving in the wrong direction..
>The software companies are forcing people to buy stronger and
>stronger machines by sending out games which require more and
>more processor power, when all the gamers really want are games
>with great GAMEPLAY!!!!.
Agreed! Somebody finally said it! :) I know I've had it for a while,
but I play Epic Pinball with a passion... it's simple, it's
comparatively easy for someone to program nowadays, and man is it fun.
An incredible enjoyable time-waster. On the other hand, I've played
Magic Carpet, Hi Octane, Fade to Black, and other new(er) games... and
absolutely can't stand them. Yes, the graphics are gorgeous, and even
SVGA is there (if I care), but the gameplay is horrid to me. You
design a game to be FUN first. THEN you design it to be pretty, sound
nice, and so forth.
>Vastly shrinking 486 market?! Oh, come on. How many ordinary game players
>do you really think are selling their 486dx2/66 they bought just one year
>ago, in order to get a state-of-the-art pentium, unless ofcourse they
>are freaks like us?!
Exactly, unless they are freaks like us. Re, my earlier paragraph...
>Have you seen the demo of Into The Shadows?. Do you think Triton used
>VGA because they can't figure out how to use SVGA?!
Triton can do SVGA anytime they wish to. But they know that it's not
that important, and sure as hell not playable if you don't have a
P133. So they don't bother for now, and I don't blame them. At least
they're looking at the game itself first.
>Maybe Triton, with their demoscene background, are just good enough to
>challenge peoples minds instead of their wallets, unlike the majority
>of softwarecompanies today.
The demo scene has a lot of good talent, and it seems half the people
on here see that, and half of them don't. I just don't like it when
the ignorant try to classify the demo world as a bunch of immature
children... far from it. If everyone on the scene was so immature,
you wouldn't see the kind of quality evolution that it's undergone.
And many of the people from demo groups go on after the group is over
to be good members of one software team or another... either under
another company, or on their own, like Triton (to an extent; there is
Scavenger... but I would say that Scavenger made ITS just as much as I
would say Interplay made Descent).
>And have you ever heard about Worms?! Do you think this game would have
>been a hit if SVGA was so important to game players as you think it is?!
SVGA does one thing, and one thing only. It looks neat. But some
games, like shooters or light-scale 3D, can handle it... the trend,
which is immersive 3D, certainly cannot.
I've only got one more thing on this... if people want SVGA so damn
badly, they'd make the 3D boards like the 3D Blaster into a standard.
Because hard 3D is the one thing people want, but which SVGA simply
isn't suited to right now. If those boards become popular, you will
have the voice of the masses. Otherwise, concentrate on gameplay, as
that's where the effort should really be going...
--------------------------------------------------------------------------------
Chris Hargrove (aka Kiwidog / Terraformer) | T E R R A F O R M E R
<kiw...@vt.edu> | 1995
"The virtual planet is the ultimate colony" | The USA demo team with no limits.
--------------------------------------------------------------------------------
Thomas Nielsen
>Paul Hsieh wrote:
>>
>> Thomas Nielsen (Thomas_...@online.pol.dk) wrote:
>> : c...@bga.com (Dr. Cat) wrote:
>> : >Doesn't strike me as hugely important. Five years from now nobody will
>> : >care, all PC games will be in SVGA anyway.
>> : REALITY CHECK!!
>> : You are talking 5 years form now!! Ofcourse games will be SVGA in 5
>> : years, but I am NOT going to wait 5 years to release my game.
>> : Fact is that a LOT of people have 486 machines today, and you can NOT
>> : write playable super-vga games for 486 machines.
>>
>> Uhhh ... you guys maybe want to wake up and smell the coffee? *ALL* new
>> games now of any importance are supporting SVGA. 5 years from now we'll
>> be supporting something entirely different (HDTV or something perhaps.)
>> SVGA is *here* right now! Go out and get yourself a copy of Terminal
>> Velocity, or Wing Commander III, or NASCAR. *All* pentiums can deal with
>> SVGA.
> I have to agree, SVGA is the ONLY way to go now a days. Almost evey
>game if have bought lately is in SVGA!
This is simply not true. I have a Pentium 75mhz PCI, and I have played
titles such as Fatal Racing and Fade To Black. I would never - EVER -
consider playing any of these games in their SVGA modes!!
I mean.. 640x480 does NOT make my clock tick when the screen refreshes
somewhere around 9 times per second. I'm sorry, but I can't help it.
I'm a sucker for great gamePLAY! And action gameplay requires much
faster graphics.
This is not about smelling the coffee.. This is about being realistic!!
Game companies support SVGA in their games because they have to impress
the game reviewers and the potential game buyers - Not because anyone
plays the games in the SVGA modes. Gamers want all their games to
support SVGA, but do they play the games in the SVGA modes? - No.. They
want to show their friends how "good the game looks". I bet you when they
want to actually PLAY the game, they go 320x200.
I don't want to flame anyone, but I have to get this off my chest;
I know a lot of you guys think you are really cool and trendy because
everything you do has to be SVGA and have millions of texturemapped
polygons. Well, I'm sorry to have to tell you this, but WE ARE NOT
THERE YET!! People do NOT have machines strong enough to handle these
things. And if they want these things, they are better off buying a
Playstation anyway.
I just wish this whole industry would stop being so pathetic, and
finally realize that things are moving in the wrong direction..
The software companies are forcing people to buy stronger and
stronger machines by sending out games which require more and
more processor power, when all the gamers really want are games
with great GAMEPLAY!!!!.
>> Fallback to mode 13h or frame dropping exists as alternatives to
>> the vastly shrinking 486 market.
Vastly shrinking 486 market?! Oh, come on. How many ordinary game players
do you really think are selling their 486dx2/66 they bought just one year
ago, in order to get a state-of-the-art pentium, unless ofcourse they
are freaks like us?!
>> But the days of Mode 13h and Mode X are waining.
Have you seen the demo of Into The Shadows?. Do you think Triton used
VGA because they can't figure out how to use SVGA?!
Maybe Triton, with their demoscene background, are just good enough to
challenge peoples minds instead of their wallets, unlike the majority
of softwarecompanies today.
And have you ever heard about Worms?! Do you think this game would have
been a hit if SVGA was so important to game players as you think it is?!
>> Paul Hsieh
>> q...@xenon.chromatic.com
Phew. Look Paul, and everyone else: If you feel offended by this, I'm
sorry! I DON'T intend to flame anyone. It's just that I think this whole
industry attitude sucks!!!. Sorry :).
Thomas Nielsen, Low Level ASM programmer, Progressive Media.
E-mail: Progr...@vip.cybercity.dk
(Was: Thomas_...@online.pol.dk)
Paul Hsieh
> Thomas Nielsen <Thomas_...@online.pol.dk> wrote:
> >This is not about smelling the coffee.. This is about being realistic!!
> >Game companies support SVGA in their games because they have to impress
> >want to actually PLAY the game, they go 320x200.
>
> sharp...", and then promptly goes back to 320x200 saying "... but this
> is playable. If I tried to play in that hires, I'd be toast."
The market is currently in a transitional period. Developers are currently
slapping on minimal SVGA support by just *attaching* "VBE" to their games
in the most slipshod fashion. So in truth, yes you are right, most games
are best played at 320x200. But take a look at "DOOM 95" (from the Judgement
day conference given by Microsoft.) Its at 640x480x256 and its got high
frame rates. If I had hands on that when DOOM first came out I would never
have touched the DOS version. When the market place is assessed from an
average system point of view and the software is done right, the conclusion
is: 320x200/Mode X is dead, 640x480+ is the way to go.
> It [DESCENT/KHALI's SVGA support] was
> a pathetic frame rate. Granted, he's got a DX4/100, but it's PCI with
> a Diamond Stealth 64 so he's not exactly on the *low* end of the
> spectrum. If anything, he's middle to above average, considering the
> common gamers.
That hardware is sufficient. It must be something else ... like possibly
a shoddy port. Take a look at Wing Commander III.
> Remember - the game freaks will upgrade their machines. But they are
> a small percentage of the population, and you aim for mass market
> appeal. That means work with the machines that they ALREADY HAVE.
Yeah. Pentium 60 with a decent PCI graphics card. That's all you need,
and for the current market demographics, that is not an *upgrade*.
> You need to have a game as high up as Doom to get people to upgrade
> just to play your game.
We are all eagerly awaiting Quake which will support SVGA. And to
say that Quake won't do precisely what you are suggesting (in the same
way DOOM forced everyone to get 4MB of RAM in their system) is pure
blasphemy.
>[...] Anyone else is not that important, and if the
> game has insane requirements, it's going to be left on the shelf.
Right. So Thrust Master, VR Headsets, Surround Sound, P6/P5-133 are
out of the question. But as far as percentages go, nearly everyone
has an SVGA PCI Pentium with 4MB of Ram. And you want them to play
320x200 games?
> >I just wish this whole industry would stop being so pathetic, and
> >finally realize that things are moving in the wrong direction [...]
> >all the gamers really want are games with great GAMEPLAY!!!!.
Sure, this is orthogonal to the discussion of graphics modes. But
visual appearance is a not-trivial element of game appreciation. Even
with the best anti-aliasing Mode 13h looks like pixelated confetti.
640x480x256 looks real sharp by just about anyone's standards. You
could almost convince people to use their word processor in that mode.
With anti-aliasing in 640x480, you don't see pixels, you see pictures.
> >Vastly shrinking 486 market?! Oh, come on. How many ordinary game players
> >do you really think are selling their 486dx2/66 they bought just one year
> >ago, in order to get a state-of-the-art pentium, [unless ofcourse they
> >are freaks like us]?!
Selling? To who? Who'd buy them? Enough people are upgrading to make
it a *shrinking* market. Every PC being sold in stores right now is a
Pentium based PC and the market is growing exponentially. A little
arithmetic tells you one thing: The 486 market is shrinking.
> >Have you seen the demo of Into The Shadows?. [...]
No so I can't comment on it. I can best comment on Wing Commander III,
NASCAR, DOOM 95 and Terminal Velocity/Fury. All support SVGA. All are
better in SVGA (possibly excepting Terminal Velocity, but Fury is quite
good under Win 95.)
> The demo scene has a lot of good talent, and it seems half the people
> on here see that, and half of them don't. I just don't like it when
> the ignorant try to classify the demo world as a bunch of immature
> children... far from it.
I'm in the camp that aprreciates their talent (I didn't realize anyone
thought they *weren't*.) Go download some of the latest cutting edge
stuff. *They* too are going SVGA. I just got something called
"CountDown". I cannot do jutification to it with idle comments. Its
on ftp.cdrom.com, go download it for yourselves and come back and tell
me about frame rates etc ...
> I've only got one more thing on this... if people want SVGA so damn
> badly, they'd make the 3D boards like the 3D Blaster into a standard.
My information leads me to believe that far more powerful chipsets are
going to become standard real soon (a year maybe?) ... Go check out
http://www.cs.columbia.edu/~bm/3dcards/3d-cards1.html for more
information and manufacturer links.
Glenn Corpes
> Judgement
> day conference given by Microsoft.) Its at 640x480x256 and its got high
> frame rates. If I had hands on that when DOOM first came out I would
> never have touched the DOS version.
Not on my p120, ok it's a reasonable frame rate but no faster than low
res on a 486-66, and that's with all of the shortcuts that doom's engine
takes (see most of the messages in this group for more info), would you
really chose to play it at this resolution?
> We are all eagerly awaiting Quake which will support SVGA. And to
> say that Quake won't do precisely what you are suggesting (in the same
> way DOOM forced everyone to get 4MB of RAM in their system) is pure
> blasphemy.
I'm sure I read a quote from id on their web page that 640*480*fast frame
rate was accelerators only.
> Sure, this is orthogonal to the discussion of graphics modes. But
> visual appearance is a not-trivial element of game appreciation. Even
> with the best anti-aliasing Mode 13h looks like pixelated confetti.
> 640x480x256 looks real sharp by just about anyone's standards. You
> could almost convince people to use their word processor in that mode.
> With anti-aliasing in 640x480, you don't see pixels, you see pictures.
Yes but you would have to drop graphic complexity from where it is now to
get a decent frame rate at this 640*480, I'd rather support lo-res first,
wait for 3d acceleration for 'hi-res for everyone' and leave software
640*480 in there for people with incredibly expensive machines, people
who don't mind playing a game at 15 frames a second that they could be
playing at 40 and people from the future (2 years should be enough).
_\/ __
\ / \ gco...@ea.com
|\ \/ / Bullfrog
| \/ /___/_Productions
|| /___ \
Daniel Goldstein
>SVGA does one thing, and one thing only. It looks neat. But some
>games, like shooters or light-scale 3D, can handle it... the trend,
>which is immersive 3D, certainly cannot.
Well, I certainly must say that you people are being a bit silly bashing
on SVGA support. Of course it is only for looks sake. And have you
considered how EASY it is to add to a game? I mean come on! How much
time do you think is really spent adding SVGA support?! It's TINY. Not
even worth mentioning in fact. So why bash it? If someone wants to play
in SVGA on their P6-2000 then let them - developers certainly are NOT
spending the time on SVGA support instead of gameplay! Gameplay is
lacking because of their lack of time and/or talent.
Dan Goldstein (StarScream/Ren'95!)
Bryan Larsen
>> background pixel that doesn't need to be redrawn isn't. Sure it adds some
>> overhead and is the wrong way to do it on 486/33 VLB, but it sure screams
on
>> ISA bus cards and on Pentiums at high resolution!
>>
>> Its actually not too complicated -- its a simple scan line system, so it'd
>> work well on ModeX also.
>>
>> What do you mean by the bank switching killing? My system switches banks
>> optimally.... (in high res modes. In modeX it would do an out once per
scan
>> line)
>
>So I take you're using 2D scrolling? I can't think of any other use where you
don't have to
>clear the screen... Anyway, it seems most of the people on this newsgroup
today are doing
>3D texture-mapping--something where fast Mode-x graphics becomes VERY
difficult.
Yep, 2D scrolling in a 3D game -- no points for guessing what type of game,
it's too easy a guess. :)
Yes, Mode-x is difficult if you're doing perspective correction, but as I'm
not, Mode-x would be fairly easy. I'm still not sure if I'll switch to
Mode-x. I've tried to make it easy to switch, but I'm sure there's several
places where a switch to vertical scans from horizontal scans will cause
problems.
Neil Graham
>> It [DESCENT/KHALI's SVGA support] was
>> a pathetic frame rate. Granted, he's got a DX4/100, but it's PCI with
>> a Diamond Stealth 64 so he's not exactly on the *low* end of the
>> spectrum. If anything, he's middle to above average, considering the
>> common gamers.
>
>That hardware is sufficient. It must be something else ... like possibly
>a shoddy port. Take a look at Wing Commander III.
To write to all of a 640x480x256 screen (Rep MovSD)with a PCI DX4/100
running a Diamond stealth VRAM takes about 1.5 video frames (60Hz framerate).
Draw from that what you will.
>640x480x256 looks real sharp by just about anyone's standards. You
>could almost convince people to use their word processor in that mode.
>With anti-aliasing in 640x480, you don't see pixels, you see pictures.
640x480 looks better, it's still slower. I would expect pentium 100s to be
fast enough. Games should be released for 640x480x256 when the machines
are in wide use. They are not that common now, it depends on the
game development time what you should aim for.
>> >Vastly shrinking 486 market?! Oh, come on. How many ordinary game players
>> >do you really think are selling their 486dx2/66 they bought just one year
>> >ago, in order to get a state-of-the-art pentium, [unless ofcourse they
>> >are freaks like us]?!
>
>Selling? To who? Who'd buy them? Enough people are upgrading to make
>it a *shrinking* market. Every PC being sold in stores right now is a
>Pentium based PC and the market is growing exponentially. A little
>arithmetic tells you one thing: The 486 market is shrinking.
I know one person with a pentium. I know a lot of computer enthusiasts.
The bulk of Game players generally have less powerfull computers than
enthusiasts. Most of the PC retailers I know of are selling mostly 486-100s
this christmas. Also PCOwners > PCBuyersIn95.
+---------------------------------------------------------------------------+
| "Glook" Le...@aurora.co.nz "Stop _poking_ me!" |
+---------------------------------------------------------------------------+
Mike Berro
irrelevent.
Check out the game "3-D Table Sports", which is Foosball, Slamhockey
(e.g. Airhockey[tm]) and Powerhoops, in 640x480 256-colors. We get 20
fps on a 486-66 with VLB, even over the net or null-modem. (9600 baud
slows it down somewhat.)
I can't claim credit for the graphics speed; our tools guy, Ken
Jordan, has been working on this stuff since time began. Getting the
net/modem stuff zippy was a chore, since unlike Doom, the machines
must stay in sync frame-by-frame.
---Mike Berro
Games Engineering Manager
Mass Media Inc.
http://www.massmedia.com/
Neil Graham
> I missed the beginning of this discussion, so excuse me if this is
>irrelevent.
> Check out the game "3-D Table Sports", which is Foosball, Slamhockey
>(e.g. Airhockey[tm]) and Powerhoops, in 640x480 256-colors. We get 20
>fps on a 486-66 with VLB, even over the net or null-modem. (9600 baud
>slows it down somewhat.)
Thats about what I would expect. The argument at this point turns into a
subjective definition of high framerate. I wouldn't consider this high, others
would. If you're not doing much a 486-100 should be able to get 30fps.
2d shootemups/platforms with parallax and lots of sprites will need still faster
systems to achieve 30fps, and for some gameplay styles 30fps is not smooth
enough (subjective).
Glenn Corpes
> (e.g. Airhockey[tm]) and Powerhoops, in 640x480 256-colors. We get 20
Is that updating all 300000+ pixels every time?
Andyrew1
15.
Neil Harding
won't name them) and it was designed to run in 320x200. It ran at over
50-60 fps on the Pentium 90's but they wanted SVGA support, so we added
it and the rate dropped down to 25 fps which they claimed wasn't fast
enough! Bear in mind this is fully textured so you get a great deal of
slow down there, with plain polygons you can run acceptably in 640x480
(say 25+ fps) but with textures you lose too much speed. A game at
320x200 with textured polys looks better than one run at 640x480 with
plain polys.
Neil Harding (Digitech Design). PGP key available on request.
Neil Harding
> NSTV is 30fps and we never complained and its actually interlaced 15 and
> 15.
Actually NTSC is 60hz and interlaced 30,30. PAL is 50hz and therefore
25,25.
Romesh Prakashpalan
Well, other than the fact that "3-D Table Sprots" isn't really a 3D Game
(really just sprite blitting :) ). But Virtual Pool runs at 1024x768 in 256
colors just fine on a 486-DX266 we have at work (with a Hercules Graphics
card). And it screams on my Pentium 100 at home (I am getting about 35Hz at
640x480). Partly because we wrote custom drivers for every video card we can
get a hold of (VESA modes are too slow and that's what most guys use). SVGA is
VERY feasible it just requires a lot of hard work with driver fiddling (we
unleash the accelerators on most of the cards to do some of the work for us,
instead of treating it like a dumb frame buffer like almost every other game
out there).
Romesh Prakashpalan
Game Developer, Celeris Inc.
P.S: I did notice that you use the mouse nicely like in Virtual Pool, it's
good to see more games that use it especially for simulations! Cool.
In article <4bccs7$d...@argentina.it.earthlink.net>, mi...@massmedia.comw
says...
>
> I missed the beginning of this discussion, so excuse me if this is
>irrelevent.
>
> Check out the game "3-D Table Sports", which is Foosball, Slamhockey
>(e.g. Airhockey[tm]) and Powerhoops, in 640x480 256-colors. We get 20
>fps on a 486-66 with VLB, even over the net or null-modem. (9600 baud
>slows it down somewhat.)
>
Rainer Deyke
: Well, other than the fact that "3-D Table Sprots" isn't really a 3D Game
: (really just sprite blitting :) ). But Virtual Pool runs at 1024x768 in 256
: colors just fine on a 486-DX266 we have at work (with a Hercules Graphics
: card). And it screams on my Pentium 100 at home (I am getting about 35Hz at
: 640x480). Partly because we wrote custom drivers for every video card we can
: get a hold of (VESA modes are too slow and that's what most guys use). SVGA is
Um, since when was 35Hz considered acceptable? Doesn't everybody need at
least 60 fps?
--
+------------------------------------------------------+
| "Fumbling in frustration, inside soul torn apart |
| Feel the loss of paradise, leave an empty heart |
| Closing eyes will shut out, the warm light of a life |
| Grip is fading slowly, for each day passing by" |
| - Desultory, "A Closing Eye" |
+------------------------------------------------------+
| Rainer Deyke (rai...@mdddhd.fc.hp.com) |
+------------------------------------------------------+
John Olsen
>Um, since when was 35Hz considered acceptable? Doesn't everybody need at
>least 60 fps?
Well, NTSC television runs at 30 fps, and cinema film is at twenty-something.
So the answer is "No, not everybody needs 60 fps." Most things would look
better at 60 (or whatever your screen is refreshing at), but are acceptable
with lower rates. Depending on the content, you may be able to go as low
as 15.
John M. Olsen Allen Communication voice (801) 537-7800
jol...@allencomm.com 5 Triad Center, 5th Floor fax (801) 537-7805
http://www.allencomm.com/ SLC, UT 84180
Paul Speed
: Romesh Prakashpalan (pra...@earthlink.net) wrote:
: : Well, other than the fact that "3-D Table Sprots" isn't really a 3D Game
: : (really just sprite blitting :) ). But Virtual Pool runs at 1024x768 in 256
: : colors just fine on a 486-DX266 we have at work (with a Hercules Graphics
: : card). And it screams on my Pentium 100 at home (I am getting about 35Hz at
: : 640x480). Partly because we wrote custom drivers for every video card we can
: : get a hold of (VESA modes are too slow and that's what most guys use). SVGA is
: Um, since when was 35Hz considered acceptable? Doesn't everybody need at
: least 60 fps?
The human eye sees between 20 and 30 frames/sec depending on your
eye. Typical cinema is 24 frames/sec. FWIW.
-Keys
: --
Trixter / Hornet
>Rainer Deyke (rai...@deyke3.fc.hp.com) wrote:
>: Romesh Prakashpalan (pra...@earthlink.net) wrote:
>
>: : Well, other than the fact that "3-D Table Sprots" isn't really a 3D Game
>: : (really just sprite blitting :) ). But Virtual Pool runs at 1024x768 in 256
>: : colors just fine on a 486-DX266 we have at work (with a Hercules Graphics
>: : card). And it screams on my Pentium 100 at home (I am getting about 35Hz at
>: : 640x480). Partly because we wrote custom drivers for every video card we can
>: : get a hold of (VESA modes are too slow and that's what most guys use). SVGA is
>
>: Um, since when was 35Hz considered acceptable? Doesn't everybody need at
>: least 60 fps?
>
> The human eye sees between 20 and 30 frames/sec depending on your
>eye. Typical cinema is 24 frames/sec. FWIW.
That can't be true, because if it were, we wouldn't be able to
differentiate between 60 fps and 120 fps, which most people easily
can.
Now, *past* 120 fps is debateable. :)
--
Jim Leonard (Trixter / Hornet) Email: tri...@mcs.com
*THE* PC Demo WWW page: http://www.cdrom.com/pub/demos/hornet/html/demos.html
The 8086 Compo is a reality! URL is http://www.cdrom.com/pub/demos/hornet/8086
Make A Computer easy enough for a fool to use, and only fools will use it!
Chris Conway
tri...@MCS.COM (Trixter / Hornet) wrote:
>In article <4ce6t3$p...@news1.mnsinc.com>, Paul Speed <ke...@mnsinc.com> wrote:
>>Rainer Deyke (rai...@deyke3.fc.hp.com) wrote:
>>: Romesh Prakashpalan (pra...@earthlink.net) wrote:
>>
>>: : Well, other than the fact that "3-D Table Sprots" isn't really a 3D
Game
>>: : (really just sprite blitting :) ). But Virtual Pool runs at 1024x768 in
256
>>: : colors just fine on a 486-DX266 we have at work (with a Hercules
Graphics
>>: : card). And it screams on my Pentium 100 at home (I am getting about 35Hz
at
>>: : 640x480). Partly because we wrote custom drivers for every video card we
can
>>: : get a hold of (VESA modes are too slow and that's what most guys use).
SVGA is
>>
>>: Um, since when was 35Hz considered acceptable? Doesn't everybody need at
>>: least 60 fps?
>>
>> The human eye sees between 20 and 30 frames/sec depending on your
>>eye. Typical cinema is 24 frames/sec. FWIW.
>
>That can't be true, because if it were, we wouldn't be able to
>differentiate between 60 fps and 120 fps, which most people easily
>can.
>
>Now, *past* 120 fps is debateable. :)
It _is_ true that movies and TV are filmed at 24-30 fps. It's not true that
the human eye _sees_ at that frequency. Yes, things will get smoother the
faster you go, up to a point, but the real idea here is that as little as 24
fps is adequate to fool the eye into seeing full motion--it's been working in
cinemas for a century!
bye.
chris.
Dan Lyke
>That can't be true, because if it were, we wouldn't be able to
>differentiate between 60 fps and 120 fps, which most people easily
>can.
Besides snide comments about monitor refresh speed, I think you'll find that
with motion blur (as opposed to a higher frame rate), it'll take mechanical
aids to see refresh rates faster than 60 Hz. Not to say that those mechanical
aids are anything more than a wiggled pencil, but anybody who works under
flourescent lights sees the world through a 60 Hz refresh rate.
Dan
Paul Speed
: In article <4ce6t3$p...@news1.mnsinc.com>, Paul Speed <ke...@mnsinc.com> wrote:
: >Rainer Deyke (rai...@deyke3.fc.hp.com) wrote:
: >: Romesh Prakashpalan (pra...@earthlink.net) wrote:
: >
: >: least 60 fps?
: >
: > The human eye sees between 20 and 30 frames/sec depending on your
: >eye. Typical cinema is 24 frames/sec. FWIW.
: That can't be true, because if it were, we wouldn't be able to
: differentiate between 60 fps and 120 fps, which most people easily
: can.
: Now, *past* 120 fps is debateable. :)
Wow, it must be really cool to have a monitor that refreshes at
120Hz. The ideal frame rate would be the refresh rate of the monitor.
Not so much because your eye will actually see more, but because things
can move faster without jitter. Also, you will be less likely to miss
frames that are out of sync.
-Keys
: --
Doug McCreary
>
> rai...@deyke3.fc.hp.com (Rainer Deyke) wrote:
> >Um, since when was 35Hz considered acceptable? Doesn't everybody need at
> >least 60 fps?
>
> So the answer is "No, not everybody needs 60 fps." Most things would look
> better at 60 (or whatever your screen is refreshing at), but are acceptable
> with lower rates. Depending on the content, you may be able to go as low
> as 15.
>
> John M. Olsen Allen Communication voice (801) 537-7800
> jol...@allencomm.com 5 Triad Center, 5th Floor fax (801) 537-7805
> http://www.allencomm.com/ SLC, UT 84180
I've seen games look acceptable at 10 frames per second,
the difference is in gameplay style. If you look at a
pure strategy game (perfect general II, for example
on one end of the scale, you could probably get away
with 3 or 4 fps. On the other end is a pure action
game (something like Descent) where you need a much
higher frame rate (30+) to create a convincing 3d
environment. In between you have things like C&C,
gladiator, Xcom in the 10-25 range depending on
how much 'action' goes on.
of the scale you have real-time action games
Jason Allen Doucette
>: (really just sprite blitting :) ). But Virtual Pool runs at 1024x768 in 256
>: colors just fine on a 486-DX266 we have at work (with a Hercules Graphics
>: card). And it screams on my Pentium 100 at home (I am getting about 35Hz at
>: 640x480). Partly because we wrote custom drivers for every video card we can
>: get a hold of (VESA modes are too slow and that's what most guys use). SVGA is
>
>least 60 fps?
Since Doom? No one ever complained about low frame rates of Doom. It
really depends on what type of game it is. Doom was good because it's
graphics detail took away from it's lower frame rates. Most shoot 'em up
games require a faster frame rate to look good. An exception is Raptor,
since nothing really moves that fast (Well, your bullets do, but your
eyes simple see the blinking effect of the bullets in a stationary place,
they don't actually follow their movement). Am I making sense? Or was
that above comment just a joke about people complaining about low frame
rates?
--
Jason Allen Doucette | "You know you're drunk when you feel it's
Saw Tooth Distortion | necessary to inform others you're not."
---------------------+------------------------------------------
E-mail: Jason.Alle...@pobox.com or 019...@axe.acadiau.ca
Dan Lyke
says...
>>Besides snide comments about monitor refresh speed, I think you'll find that
>>with motion blur (as opposed to a higher frame rate), it'll take mechanical
>>aids to see refresh rates faster than 60 Hz. Not to say that those mechanical
>> aids are anything more than a wiggled pencil, but anybody who works under
>>flourescent lights sees the world through a 60 Hz refresh rate.
>
Whoops. Sorry, I should have pointed out that peripheral vision is often far
more responsive to quick light changes, so some people can see flicker towards
the edges of their vision.
But seriously, are you really immediately conscious of the flicker from
flourescent lights? Can you immediately tell the difference between rooms lit
by daylight corrected incandescent and flourescent bulbs? (Note: I'm not
talking about your eyes tiring after a while working under them, I'm saying the
whole world flashes in the center of your vision while you're under them!).
If so, then you're a medical wonder. If not then I strongly suggest you reread
my paragraph above, especially the part about motion blur, and correct your
statement.
Dan
Patrick Hanevold
>Whoops. Sorry, I should have pointed out that peripheral vision is often far
>more responsive to quick light changes, so some people can see flicker
>towards the edges of their vision.
>But seriously, are you really immediately conscious of the flicker from
>flourescent lights? Can you immediately tell the difference between rooms lit
> by daylight corrected incandescent and flourescent bulbs? (Note: I'm not
>talking about your eyes tiring after a while working under them, I'm saying
>the whole world flashes in the center of your vision while you're under
>them!).
With some concetration i can see the flickering.
In my country we use 50Hz thoug.
>If so, then you're a medical wonder. If not then I strongly suggest you
>reread my paragraph above, especially the part about motion blur, and
>correct your statement.
I guess I'm a medical wonder then.
<sb>Patrick Hanevold - Virtual Reality developer
<sb>patrick....@login.eunet.no
<sb>Amiga and official Be developer
Wayne
wrote:
>John Olsen wrote:
>>
>> rai...@deyke3.fc.hp.com (Rainer Deyke) wrote:
>> >Um, since when was 35Hz considered acceptable? Doesn't everybody need at
>> >least 60 fps?
>>
>> Well, NTSC television runs at 30 fps, and cinema film is at twenty-something.
>> So the answer is "No, not everybody needs 60 fps." Most things would look
>> better at 60 (or whatever your screen is refreshing at), but are acceptable
>> with lower rates. Depending on the content, you may be able to go as low
>> as 15.
>>
>> John M. Olsen Allen Communication voice (801) 537-7800
>> jol...@allencomm.com 5 Triad Center, 5th Floor fax (801) 537-7805
>> http://www.allencomm.com/ SLC, UT 84180
>
>
>I've seen games look acceptable at 10 frames per second,
>the difference is in gameplay style. If you look at a
>pure strategy game (perfect general II, for example
>on one end of the scale, you could probably get away
>with 3 or 4 fps. On the other end is a pure action
>game (something like Descent) where you need a much
>higher frame rate (30+) to create a convincing 3d
>environment. In between you have things like C&C,
>gladiator, Xcom in the 10-25 range depending on
>how much 'action' goes on.
>of the scale you have real-time action games
Why all the fuss about frame rates? The _market_ won't have computers
capable of displaying high (60ish) frame rates for a few years yet.
Worry about gameplay FIRST and eek out those extra frames per second
later.
Hope noone minds me butting in........
Michael Currington
> In article <4ce6t3$p...@news1.mnsinc.com>, Paul Speed <ke...@mnsinc.com> wrote:
> >Rainer Deyke (rai...@deyke3.fc.hp.com) wrote:
> >
> >: Um, since when was 35Hz considered acceptable? Doesn't everybody need at
> >: least 60 fps?
> >
> >eye. Typical cinema is 24 frames/sec. FWIW.
>
> That can't be true, because if it were, we wouldn't be able to
> differentiate between 60 fps and 120 fps, which most people easily
> can.
>
> Now, *past* 120 fps is debateable. :)
You are confusing screen refresh rate (ie number of times electron beam refreshes
the phoshor (sp?) on the screen per second) with the frame rate of the game.
TV has a refresh rate of 50/60Hz (depending on where you are in the world) and
most monitors work at 60-100Hz because you are closer to the screen and can detect
the flickering caused by the fact that the screen phoshors only glow for a short
amount of time. This is not the same as the number of frames you have to play
per second to fool the human eye into thinking the picture on screen is moving
and not just a series of still images.
Films typically run at 20fps (I believe) TV runs at 30/25fps (because one
complete frame is 2 scans of the tv - ie it is interlaced). Most cartoons
run at around 15fps (Disney are a little better I believe). Anything over
20 fps for a game is probably a bit wasted, better to use the extra cpu time
to improve the fraphics or resolution, or to do some nice AI.
Later dudes,
Mike
p.s. Trixter - most demos dont run anywhere near 120Hz, the smooth ones run
at 10-15fps (I looked at a few on a slow motion video system). However
the demos which program the monitor refresh to 50Hz (Complex's XTal)
do flicker noticably (because the phosphors are not being updated
quickly enough)
p.p.s. If I sound a little condesending or anything don't worry, it's just
another stressed day at work that's done it :-) Time to unwind and
write some code, errrm, whatever ...
> --
> Jim Leonard (Trixter / Hornet) Email: tri...@mcs.com
> *THE* PC Demo WWW page: http://www.cdrom.com/pub/demos/hornet/html/demos.html
> The 8086 Compo is a reality! URL is http://www.cdrom.com/pub/demos/hornet/8086
> Make A Computer easy enough for a fool to use, and only fools will use it!
---
____________________________________________________________________________
Mike Currington E-Mail: cur...@ferndown.ate.slb.com
Bournemouth, England
____________________________________________________________________________
"Pray that there's intelligent life somewhere out in space,
'coz there's bugger all down here on earth" - Galaxy Song, Monty Python
Rainer Deyke
: You are confusing screen refresh rate (ie number of times electron beam refreshes
: the phoshor (sp?) on the screen per second) with the frame rate of the game.
: TV has a refresh rate of 50/60Hz (depending on where you are in the world) and
: most monitors work at 60-100Hz because you are closer to the screen and can detect
: the flickering caused by the fact that the screen phoshors only glow for a short
: amount of time. This is not the same as the number of frames you have to play
: per second to fool the human eye into thinking the picture on screen is moving
: and not just a series of still images.
: Films typically run at 20fps (I believe) TV runs at 30/25fps (because one
: complete frame is 2 scans of the tv - ie it is interlaced). Most cartoons
: run at around 15fps (Disney are a little better I believe). Anything over
: 20 fps for a game is probably a bit wasted, better to use the extra cpu time
: to improve the fraphics or resolution, or to do some nice AI.
I'm sorry but that is simply incorrect. In side-scrolling games it makes a
huge difference wether the screen is updated at 30 or 60 fps. In first
point perspective games like Doom 30 fps is good enough. I suggest that you
try watching a program that moves one sprite at 60 fps and another at 30
fps (skipping every other frame and otherwise moving twice as many pixels
per move). You WILL notice a significant difference.
Christer Ericson
>[...]
>You are confusing screen refresh rate (ie number of times electron beam refreshes
>the phoshor (sp?) on the screen per second) with the frame rate of the game.
>TV has a refresh rate of 50/60Hz (depending on where you are in the world) and
>most monitors work at 60-100Hz because you are closer to the screen and can detect
>the flickering caused by the fact that the screen phoshors only glow for a short
>amount of time. This is not the same as the number of frames you have to play
>per second to fool the human eye into thinking the picture on screen is moving
>and not just a series of still images.
>Films typically run at 20fps (I believe) TV runs at 30/25fps (because one
>complete frame is 2 scans of the tv - ie it is interlaced). Most cartoons
>run at around 15fps (Disney are a little better I believe). Anything over
>20 fps for a game is probably a bit wasted, better to use the extra cpu time
>to improve the fraphics or resolution, or to do some nice AI.
And you, in turn, are confusing frame rate with what is known as
the _critical flicker (fusion) frequency_. This is the frequency
at which flicker is just barely perceptible. CFF depends on a
number of things: brightness of the image, viewing angle, etc,
but is something like 45-50 Hz (but much higher for some people).
This is why each cinema frame of the film (running at 24 fps) is
shuttered, being shown twice or usually thrice, per frame.
This is also why television is interleaved so that NTSC/PAL gets an
"effective" updating of 60/50 fps. Interleaving is not perfect, but
it definitely beats a non-interleaved 30/25 fps update freq, which
would flicker horribly.
I see people being confused over this issue time and time again,
incorrectly stating what you stated above. What you say is true,
but it is the answer to a completely different question.
It is very simple to see this effect: just hack up some code that
advances two blobs across the screen. The first blob moving 1 pixel
at every VBL (or some such), the other blob moving 2 pixels at
every other VBL. The first blob will appear to move smoothly
(assuming VBL > CFF) while the second blob will "ghost", ie you
will see a secondary image trailing the second blob.
Christer Ericson <This space for hire!> http://www.cs.umu.se/~christer/
phone: +46-90-16 67 94, fax: +46-90-16 61 26, email: chri...@cs.umu.se
Department of Computing Science, Umea University, S-901 87 UMEA, SWEDEN
Jason Allen Doucette
explain this the best I can.
TV and movies are shown at about 24 fps, but that is irrelevant to games,
since games don't blur each frame into the next (the shutter rate is
infinitely small, not 1/24th of a second, as in movies). Some video
cameras (like the ones used for most sport broadcasts) have a shuttle
rate of about 1/500th of a second, which is bascially infintiely small,
and you can notice the low fps when you see quick movement, such as a
close zoom when a player rushes by (like when there's a body check into
the boards right next to the camera).
As far as any game going over 70 fps, it's stupid to argue about this,
since the screen isn't refreshed at over 70 fps (in most cases, anyways).
If you're using mode 13h, and you don't wait for the retrace, and your
game goes over 70 fps, it actually looks just as bad as a low frame rate,
because of all the shearing. Synching with the retrace results in silky
smooth movement, whether it's 60 or 70 fps (480 or 400 scan lines - most
commonly used Mode X and Mode 13h)
24 fps is enough for animation (a character's movement such as a player
running), but not enough for smooth movment (when the character is
jumping around the screen, or the screen scrolling itself). Let me give
you an example: Let's say Mortal Kombat runs at 24 fps on your machine.
As the characters kick and punch, the animation will appear as smooth as
any movie, but as soon as you jump, your eyes will be following the
character, recieving three refreshes of the same frame (70/3 = 23.33),
and you'll notice three different images....not very smooth. The max
frame rate for Raptor is 24-26 fps, you can see this very easily on any
of the moving objects. People thought it had a high frame rate, because
they were watching the background (scrolling very slowly at 1 pixel every
1/24th of a second), which appears smooth since it's not moving quickly.
But if you play the game, and watch the objects, you'll notice the game
has a really poor frame rate.
I seem to be blabbering too much at this point, so I'll stop. I hope you
understood what I was trying to say.