Then you'd be looking at optimising code so that it ran from each processor's local cache as much as possible.

Yes, if by local cache we mean its own 'private' memory (probably in the megabytes, at least.)

Another possibility I've heard about is that there isn't a shared cache as such. Processors claim parts of the address range. When another processor wants to access a part of the address range it doesn't own it has to be updated from the processor that does.

Yeeess..
The problem then is quite how the chips communicate large amounts of data efficiently.
Thinking about this sort of thing, I wonder whether it would be possible to have a sort of priority system on access to main memory. The processor could alter its priority dependent on how desperate it was. If they had small write caches (maybe 16 words or something) then writes could generally be low priority until the buffer was filling up.
Of course that doesn't solve how one gets processor A to tell processor B to do a certain job. or processors C & D to claim a different job each, rather than both claiming the same job at once. or whatever. This needs some sort of arbritration.

<on processor architecture>

I remember doing a whole course on this at uni. Unfortunately I don't remember too much. There are many architectures in use, from straight buses that are snooped by the processors, which are fairly cheap but have limited scalability, upto complete cross buses where processors have direct links to every other processor. This is mega expensive. Another topology is a hypercube because it's easy to route messages between processors.

I've heard reference to hypercubes in this context before and never understood what they meant. But I think I've had an epiphany. Does this mean that a processor has an address of a certain length in binary specifying a 'corner' - and each sucessive digit refers to which half of the hypercube it is in? left/right side, top/bottom, front/back, ana/kata and so on?

The problem isn't that far removed from event based architectures in software, either in a single process or across multiple processors (perhaps connected by networks). It just costs more in hardware.

Certainly on split screen games you could be looking at dedicating a processor to a single screen "split" although I'm not sure if this is your point.

...

Part of the problem is that games cost millions of pounds to produce. No one is going to write a risky, innovative, new game concept if they can get their money from "improving the realism" of their last driving game.

I also remember, a couple of years ago or so, talking about the 'look' of Jet Set Radio with a housemate. He said that he thought it looked just awful. So it seems for some people 'graphical realism' is everything.

...and playability means nothing, which is sad but also very true in many cases.

What I found particularly disturbing about this was that it had very good graphics (for the time - and still today I think). It was the progenitor of what is now called 'cel shading'. Basically like anime shadowing effects. I think it is sad that people judge quality by similarity to reality. So however good your graphics are, if they don't conform to reality (as perceived by them) they don't appreciate them at all.

http://www.faqs.org/rfcs/rfc1882.html

This has nothing whatsoever to do with this thread:

'The page cannot be displayed'

Maybe its been 'Arcaded'

Haha! Looks that way.

"Parallelism is increasing faster on the graphics card than on the CPU, they declare. Before issuing a rallying cry for freedom: give graphics cards a full instruction set!"

Chuckle. Heheh. Somewhat off topic aren't we. Given the quiet nature of these boards, shouldn't we really start new topics for every little thing?