Next gen video console speculation suggests we aim low

The next generation of video game consoles should start in 2011. (Give or take a year). It takes about three years to develop a video game console, so work should be ramping up at all three video game manufacturers.

Nintendo's best course-of-action is pretty clear: Do a slightly souped-up Wii. Perhaps with lots of SD-RAM for downloadable games. Probably with low-end HD resolution graphics. Definately with an improved controller (for example with the recent gyroscope slice built in.)

Sony and Microsoft have to decide whether to aim high or copy Nintendo.

Today a strong rumor has it that Sony is polling developers to see what they think of a PlayStation 4 that is similar to a cost-reduced PlayStation 3 (same Cell, cheaper RAM, cheap launch price.)

http://forum.beyond3d.com/showthread.php?t=50037

That makes sense as Sony has had problems this generation due to the high launch cost of the PS3. The drawback of this scheme is that it does nothing to make the PS4 easy to program.

In the last few weeks we've seen other rumors that Microsoft's being courted by Intel to put the Larrabee GPU in the next gen Xbox. I think that if Sony aims low, it's likely that Microsoft will be foreced to aim low too, which would make a Larrabee GPU unlikely. That makes me sad -- in my dreams, I'd love to see an Xbox 4 that used a quad-core x86 CPU and a 16-core Larrabee GPU.

Well, the great thing is that we'll know for sure, in about 3 years. :-)

Comments

Johann Deneux said…
"The drawback of this scheme is that it does nothing to make the PS4 easy to program."
Will the PS4 still be hard to program in 3 years? If the free lunch really is over, game programmers will have to learn to write concurrent programs anyway.
October 1, 2008 at 10:38 AM
Jack Palevich said…
Hah, yes it will. Compare the PS3's programming constraints to an Intel Core Duo, or Xbox 360 or Larrabee, all of which support concurrency, and you'll see that the PS3 is much harder to program.
October 20, 2008 at 1:05 AM
Post a Comment

Popular posts from this blog

GLES Quake - a port of Quake to the Android platform

I've just published the source code to a port of Quake to the Android platform . This is something I did a while ago as a internal test application. It's not very useful as a game, because there hasn't been any attempt to optimize the controls for the mobile phone. It's also awkward to install because the end user has to supply the Quake data files on their own. Still, I thought people might enjoy seeing a full-sized example of how to write a native code video game for the Android platform. So there it is, in all its retro glory. (Porting Quake II or Quake III is left as an exercise for the reader. :-) What's different about this particular port of Quake? Converted the original application into a DLL Android applications are written in Java, but they are allowed to call native languge DLLs, and the native language DLLs are allowed to call a limited selection of OS APIs, which include OpenGL ES and Linux File I/O. I was able to make the game work by using Java for: T
Read more

A Taipei-Torrent postmortem: Writing a BitTorrent client in Go

This is a BitTorrent client. There are many like it, but this one is mine. -- the BitTorrent Implementer's Creed For fun I've started writing a command-line BitTorrent client in Google's go programming language. The program, Taipei-Torrent , is about 70% done. It can successfully download a torrent, but there are still lots of edge cases to implement. Go routines and channels are a good base for writing multithreaded network code. My design uses goroutines as follows: a single main goroutine contains most of the BitTorrent client logic. each BitTorrent peer is serviced by two goroutines: one to read data from the peer, the other to write data to the peer. a goroutine is used to communicate with the tracker some "time.Tick" goroutines are used to wake the main goroutine up periodically to perform housekeeping duties. All the complicated data structures are owned by the main goroutine. The other goroutines just perform potentially blocking network I/O using channel
Read more

A Multi-threaded Go Raytracer

Image
Above is the output of the raytracer. Below is a diagnostic mode showing which goroutines raytraced which section of the screen. Each goroutine has its own color to outline the pixels it traces: I wrote a simple multi-threaded ray tracer in Google's new "go" language. It's an adaptation of Flying Frog Consultancy's Raytracer . It runs single-threaded about 1/2 the speed of a comparable C++ version. I guess the C++ version benefits from a more optimizing compiler and the ability to inline small functions. Compared to ordinary C/C++, the Go version was easier to multithread. On my dual-core Macbook Pro I get an 1.80x speedup when running with GOMAXPROCS > 1: $ GOMAXPROCS=1 time ./gotrace 1.52 real 1.50 user 0.01 sys $ GOMAXPROCS=2 time ./gotrace 0.82 real 1.50 user 0.01 sys $ GOMAXPROCS=3 time ./gotrace 0 .81 real 1.50 user 0.01 sys On an eight-core, 16 Hyperthread HP Z600 running Ubuntu 9
Read more