Darren New wrote:
> Warp wrote:
>> and the focus gradually shifted to the objects, leaving the people
>> blurred. Really cool-looking.
> 
> Very cinemagraphic!
> 
> Next up: Making the splashing of water based on the actual movement of
> water in the simulation. :-)

I'm interested in that, but I don't care about realtimeness :)

Post a reply to this message

On 8-6-2009 20:26, Nicolas Alvarez wrote:
> andrel wrote:
>> On 6-6-2009 23:32, Warp wrote:
>>> andrel <a_l### [at] hotmailcom> wrote:
>>>> Regardless of the degree of veracity of anything that has been written
>>>> in this thread, I'm not sure that such a thread is very relevant here.
>>>> only joking of course. I sorta agree with you in the case where this
>>>> citations comes from. There is just this problem of this group being
>>>> p.o-t, so anything posted here is not very relevant here.
>>>   I don't understand what you mean.
>> That is not entirely true.
>>
>>> Approximately 100% of people who
>>> read this group are computer users.
>> So? A fair amount have views on religion too, close to but not entirely
>> 100% I would guess. Possibly about the same percentage as those playing
>> games.
> 
> Way to derail the thread, thanks.

I do my best ;)
Actually I though of it as binding two threads together.

Post a reply to this message

Warp wrote:

I know this is tangential to the thrust of your post, and please forgive 
my ignorance, but in VERY GENERAL terms, how does a game run faster on 
two cores?  What is done to exploit the added processor?

-Jim

Post a reply to this message

Jim Charter wrote:
> I know this is tangential to the thrust of your post, and please forgive 
> my ignorance, but in VERY GENERAL terms, how does a game run faster on 
> two cores?  What is done to exploit the added processor?

You have to have two separate compute-heavy tasks that utilize different 
sets of data.

In general, with current architectures its very difficult to get more 
than two or three parallel tasks.  Generally, physics and graphics, 
possibly AI or game logic (scripts and such).

Physics can be multithreaded fairly effectively, but in current 
implementations it tends to use the same hardware the graphics system 
uses.  So to boost one, you have to sacrifice the other.  Although I 
believe NVidia offers the ability to dedicate a single card to physics, 
and use the remaining card(s) for graphics (giving them an excuse to 
sell tri-sli systems, with one card for physics and two for graphics).

-- 
Chambers

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> I know this is tangential to the thrust of your post, and please forgive 
> my ignorance, but in VERY GENERAL terms, how does a game run faster on 
> two cores?  What is done to exploit the added processor?

  That's a problem with which game engine developers have been struggling
since it became clear that the future is in multiple cores rather than
increased GHz (ie. when a rather surprising wall was hit many years ago at
the about 4 GHz boundary, after which both Intel and AMD decided that it's
way too difficult to push clockrates any further than that, and instead
future development will be in the x86-64 architecture and especially
multiple cores).

  A relatively easy and cheap way of using multiple cores is to distribute
independent per-frame tasks to different threads. For example the physics
engine, the CPU part of the rendering engine (which handles things like
deciding which parts of the scenery are visible and which aren't, and thus
which parts are sent to the GPU to render), the AI (which eg. controls NPC
and enemy movement), and other such things a game calculates with the CPU
relatively independently can be distributed to multiple threads.

  The problem with that technique is, of course, that those tasks are
wildly different in complexity, and some of the tasks are really fast to
calculate while others require a lot more processing power. Also they
often are not 100% independent, but some tasks must at least partially
be calculated before or after some other tasks.

  If from the to-be-done-per-frame work a very heavy task takes, for
example, 80% of the available time and the other tasks take the remaining
20%, putting that heavy task to one thread and the others to another thread
will not be utilising the available processing capacity fully (because the
second core will be idle over half of the time). This is, in fact, a very
relevant problem in actual game engines. While it helps a bit, of course,
the time saved is only 20% in this example, rather than the optimal 50%
with two cores. Also an even bigger problem is that adding more cores will
not help at all (because one core will still be doing 80% of the work).

  The optimal solution is to make the tasks themselves multithreaded.
However, this is a VERY HARD problem, and it's what game developers have
been struggling for almost a decade. Not only is modifying algorithms to
be multithreaded a very difficult task, but doing it efficiently is an
even more difficult one. Multiple threads will not speed up anything if
most threads have to wait in mutexes for other threads to free the
resources. Mutex-free, wait-free algorithms are the panacea of game
development, and very difficult to come up with.

  I don't know, but I assume that a lot of work has been put into making
one of the heaviest tasks in a game multithreaded, namely physics engines.
That's probably one thing which most benefits from multiple cores nowadays.
Of course other heavy tasks could also theoretically be done in parallel,
such as hidden scenery removal.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   A relatively easy and cheap way of using multiple cores is to distribute
> independent per-frame tasks to different threads.


>   The problem with that technique is, of course, that those tasks are
> wildly different in complexity,


>   I don't know, but I assume that a lot of work has been put into making
> one of the heaviest tasks in a game multithreaded, namely physics engines.

One more quick note: Many of the "other" tasks, like game logic, AI and 
script execution, are so "light" compared to the physics and graphics 
routines that developers don't even bother spawning separate threads for 
them.

-- 
Chambers

Post a reply to this message

Thanks for your reply, (and Chambers' also), I have a duo-core laptop 
for my wife to use and I did notice that it is not really too much 
faster than this aging single processor machine, except when there is a 
need to run two heavy applications simultaneously.  So I wondered about 
games.

-Jim

Post a reply to this message

Warp escreveu:
> Warp <war### [at] tagpovrayorg> wrote:
>>   For example, I recently bought the game "The Last Remnant"
> [...]
>> I have even maxed up all graphical settings and I'm getting pretty good
>> framerates (something like 20 FPS and up). Of course this is mostly thanks
>> to my GPU, but at least the CPU isn't getting badly in the way.
> 
>   Speaking of which, it's rather impressive what kind of graphics modern
> 3D cards can produce. For example this game uses quite effectively a
> combination of focal blur, luminous blooms and (I assume) HDRI for
> rendering really impressive images... in real-time.
> 
>   The focal blur is not used only for shows, but actually for composition
> purposes. For example there's a cut-scene (rendered in real-time with the
> game engine) which has some objects on the foreground and some people in
> the background. The focus was on the people while the objects were blurred.
> Then the people started talking about the objects and turned to look at
> them, and the focus gradually shifted to the objects, leaving the people
> blurred. Really cool-looking.

heh, focal blur was available even for PS2.  Resident Evil 4 has a 
sniper and binoculars both featuring focal blur.  Metal Gear Solid 2 and 
3 used it a bit in the in-game engine cinematics as well as many other 
games to impressive effects.  The system screen itself is loaded with 
focal blur effects.

Heck, even some of the last and great PSOne games, like Vagrant Story, 
faked some focal blur of sorts by rendering a few extra polygons for 
foreground objects in a rapid flickering fashion...

Have you played Mirror's Edge yet?  Now that is more impressive, with 
it's fake but vivid real time global illumination with color bleeding...

and, well, some people would find it completely unnaceptable by today's 
standards to play a FPS in 20 FPS (pun intended).  The spoiled brats say 
it's impossible to hit enemies with a stuttering frame rate.  Me?  I've 
blasted my way both on the original SNES Star Fox in its glorious 15 FPS 
as well as in Goldeneye on N64 at 20 FPS, I'm ok with that...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> heh, focal blur was available even for PS2.  Resident Evil 4 has a 
> sniper and binoculars both featuring focal blur.  Metal Gear Solid 2 and 
> 3 used it a bit in the in-game engine cinematics as well as many other 
> games to impressive effects.  The system screen itself is loaded with 
> focal blur effects.

  Was it a true focal blur, or was it only a cheap trick, like for example
rendering part of the scene to a stencil buffer (or such), blur it, then
render the sharp part on top of it. With this kind of method you only get
two planes of blur (or a few, if you do it for more than one "plane"), but
it's impossible to get eg. a floor getting increasingly blurry the farther
it's from the camera.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> nemesis <nam### [at] gmailcom> wrote:
>> heh, focal blur was available even for PS2.  Resident Evil 4 has a 
>> sniper and binoculars both featuring focal blur.  Metal Gear Solid 2 and 
>> 3 used it a bit in the in-game engine cinematics as well as many other 
>> games to impressive effects.  The system screen itself is loaded with 
>> focal blur effects.
> 
>   Was it a true focal blur, or was it only a cheap trick, like for example
> rendering part of the scene to a stencil buffer (or such), blur it, then
> render the sharp part on top of it. With this kind of method you only get
> two planes of blur (or a few, if you do it for more than one "plane"), but
> it's impossible to get eg. a floor getting increasingly blurry the farther
> it's from the camera.

I believe it was like that in the case of the PSone, not 2, but I can't 
be sure.  The blur in the case of the sniper rifle at least felt 
continuous enough...

Post a reply to this message