Warp wrote:

>   The developers also did things right technically. This game goes to show
> that you *can* still make a game using completely state-of-art graphics
> while not requiring a 64-bit dual-core monster computer with the latest
> graphics hardware. Even an older single-core computer with a relatively
> recent but cheap graphics card (in my case a 3.4GHz P4 with a Radeon HD
> 3850) was enough to get pretty decent framerates with most graphical
> settings set to maximum (the game's own benchmark clocked an average of
> about 40 frames per second on my computer, which to my standards is more
> than enough).
 
Hmm I've often wondered how much control the game developer has over that,
even on the PC. (On consoles I'm guessing you're even more "locked in" to a
set of tools...)

I. e. he is sitting atop a dense set of layers that consists, as far as I
know of

- A game engine graphics API inside
- Whatever game engine he's using to code the game inside
- Windows inside of which is
- the Nvidia / ATI 3D driver which has got
- its own internal function core and layers which
- eventually gets to hardware for rendering which eventually goes to
- some kind of framebuffer which
- gets displayed.

What I'm getting at is how much of a game's graphical performance CAN be
optimized by somebody who's already behind several dozen libraries? There's
probably only -so- many ways to do something, and only such and such a new
optimized version of those libraries.

Is this type of good performance down to a good core developer, or just the
toolkit / library set he happened to pick for the project?

Since most games these days seem to run with at least two threads on two
cores (erm... one for keeping the graphics pipeline fed with data, one for
logic?) can it maybe be that the logic thread is the bottleneck, and this
is where a good developer can improve performance?
-- 
Stefan Viljoen

Post a reply to this message