On Fri, 18 Jul 2008 09:25:07 +1000, Dre wrote:

> yes, it doesn't crash for me, in fact I haven't had it crash for me in
> *years*.

I can say that as well, but that's probably more due to the fact that I 
use OpenOffice rather than MS Office. :-)

But I do know lots of people who use Word frequently (and use advanced 
features) and don't have it crash.  Last time I worked on a book, I was 
required to use Word with templates and it never crashed on me - and I 
think that was even Word 97.

Jim

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> For a games console it's probably enough.  What do you hold in RAM during a 
> game?  All the 3D meshes and textures are on the GPU video memory only*. 

  That's actually not true.

  In big games typical scenes may consist of hundreds of thousands, if not
even millions of polygons. You *can't* render them all even with the most
modern graphics cards.

  Game engines implement an ample variety of techniques to reduce the amount
of polygons sent to the graphics card. The optimal situation is that only
those polygons which are visible in the current frame are sent to the
graphics card to be rendered.

  Many of these techniques are things which are not supported by graphics
cards but must be calculated by the CPU. These include things like BSP
trees, dividing the scene into sectors, portals, occlusion volumes,
billboard sprites, etc.

  Also in most modern games the scene to be rendered is seldom static,
but changes all the time. For example dynamic shadows, at least if
implemented using shadow volumes, require new shadow polygons to be
created at each frame and sent to the graphics card. Of course in order
to create the shadow polygons in the first place you need the scene
itself (and all of its optimizations) in RAM.

  Games also need to do a whole lot more than that as well. For example
most current games have some kind of physics engine, which requires its
memory. The list is endless.

-- 
                                                          - Warp

Post a reply to this message

>  Game engines implement an ample variety of techniques to reduce the 
> amount
> of polygons sent to the graphics card.

True, but you very rarely need to keep a copy of the actual meshes used to 
render.  Usually for the sort of algorithms you mean, you never go down to 
the polygon level because it's just faster to let the GPU handle that. 
You'll usually be working with bounding boxes of meshes, not the actual mesh 
data.

And as for the textures, I don't think you need them at all in CPU RAM 
during the game.

> The optimal situation is that only
> those polygons which are visible in the current frame are sent to the
> graphics card to be rendered.

Maybe that was optimal 15 years ago, but today the GPU is way faster than 
the CPU at culling polygons.  Especially when you consider the overhead of 
having to transfer all the mesh data per-frame to the GPU - that is slow and 
nobody does it.  The optimal approach nowadays is to have as much mesh and 
texture data loaded in the GPU as possible, and per-frame the CPU can just 
tell the GPU which meshes to render, based on some algorithm.

>  Also in most modern games the scene to be rendered is seldom static,
> but changes all the time. For example dynamic shadows, at least if
> implemented using shadow volumes, require new shadow polygons to be
> created at each frame and sent to the graphics card.

No they don't, you can do it that way but it's slow.  You usually make a 
simplified version of your mesh, replace each edge with a quad compressed 
down to that edge and then load it to the GPU.  THen, per-frame, a vertex 
shader running on the GPU decides if the edge is a silhouette edge, and 
expands out the polygon as necessary in the direction away from the light. 
Character animation and other dynamic effects (eg trees moving in the wind) 
are usually done in the vertex shader too.

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote in message
news:487f8231$1@news.povray.org...
>
> The Word MVP website has an entire *section* dedicated to this
> particular issue:
>
> http://word.mvps.org/FAQs/Numbering/WordsNumberingExplained.htm
>

Ok, so the numbering's strange. At leat it's understandable once the
explaination is given (like so many things).
I assume you foung that link a while back and didn't go searching for it
just for me.
Since you now understand why the lists sometimes go strange, you can explain
it to the users. You'll probably end up their hero for saving them so much
time in fixing the lists.

Post a reply to this message

scott wrote:
> you, you *always* get that little icon that gives you the chance to 
> "don't ever do what you just did again" or "ok undo what you just did, 
> but do it again later if you want".  Very handy.

I like how this works in OpenOffice, where it pops up the little 
lightbulb that says "Hey, I just changed stuff. If you want to learn how 
to change it back, here's what the subject to search for in the help 
file is..." ;-)

Not that it'll put it back, or let you turn it off right there, or 
anything like that.

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:4880c065@news.povray.org...

> Not that it'll put it back, or let you turn it off right there, or
> anything like that.
>

That would be too easy and it would deprive you of an opportunity to see the
outstanding quality of the help file. </tongue in cheek>

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > The optimal situation is that only
> > those polygons which are visible in the current frame are sent to the
> > graphics card to be rendered.

> Maybe that was optimal 15 years ago, but today the GPU is way faster than 
> the CPU at culling polygons.  Especially when you consider the overhead of 
> having to transfer all the mesh data per-frame to the GPU - that is slow and 
> nobody does it.  The optimal approach nowadays is to have as much mesh and 
> texture data loaded in the GPU as possible, and per-frame the CPU can just 
> tell the GPU which meshes to render, based on some algorithm.

  Many games seem to disagree with you.

  For example HL2 and sequels actually drop meshes and use lower-resolution
meshes for scenery which can only be seen from far away, but if you go
to that scenery, it will load objects and higher-resolution versions of
other objects.
  For example in HL2:Lost Coast you can use objects to climb over barriers
which would normally stop you from getting back to previous parts of the
level. If you do that, those parts are very ascetic compared to what they
were previously (when you played through them normally).

  Other games, such as for example Oblivion, generate terrain details
dynamically based on distance: Closer terrain will be more detailed than
terrain farther away. Other games, such as Call of Juarez, also do this
(and this one does it even better than Oblivion), which allows huge visible
landscapes to be rendered.

  The amount of polygons to render matters even today. That's because
today polygons are much heavier to render compared to 15 years ago.
15 years ago you had bilinearly-filtered perspective-correct texture
mapping, light mapping, and little else. Today you have all kinds of
pixel shaders, bump mapping and whatnot.

  Also some polygons need to be rendered from farther to closer, most
prominently polygons with transparencies, or else the Z buffer won't
work properly. I don't know if any graphics card supports sorting of
polygons (especially since there's no generic algorithm for sorting
polygons, not even triangles, without polygon splitting).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
<snip about graphics>

And that's not even the game, just the stuff needed to show it on screen!

SimCity 4 came out what, 7 years ago?  It's still one of the most CPU 
demanding games I have (once you get a large city, that is :) ).

The Sims is also notoriously slow on high end computers.  When you get a 
house with decent decorations, that game can slow to a crawl (of course, 
we've got more than 8 GB of downloaded stuff for it).

The point is, there are *lots* of things you need CPU and RAM for other 
than graphics.

...Chambers

Post a reply to this message

Orchid XP v8 wrote:
> I'm also 98% sure none
> of the Word power users know about styles.

<CoderForLife> 83% of all statistics are made up on-the-fly 76% of the time
<CoderForLife> 4 out of 5 dentists agree
<efc> Thats 62% bull($#@, CFL

Post a reply to this message

scott wrote:
> Googling "VBA in Word" gives 5460000 results, seems like a lot of people
> have something to say about it.

Googling "Excel database" gives lots of results of people showing you how to
create excel databases too. Took me long to find the link I was looking
for: a blog post about "I can't believe people use excel as a database"

Post a reply to this message