The easiest and the most complex video game console to develop for?

Out of curiosity what is the easiest video game console to develop for? Also what is the hardest to program for? I heard ARM and (I think) PPC is simplistic.

 

Easiest for WHO to develop for? I'd imagine the PS4 and Xbox One would be really easy for a PC developer to make a game on. Someone who is good at bare hardware access wouldn't want to make a game on the same systems because they don't get direct hardware access.

 

A developer obv. I think the og xbox should be on that list cause that was similar to a PC as well. You could also count a Sega Chihiro as well.

 

Easiest: Xbox, Xbox One, PS4, Nintendo DS, Sony PSP
Hardest: Atari Jaguar, Sega Saturn, Nintendo 64

 

Hmm... interesting. Of course the x86 trio are there due to familiarity and the DS. Didn't really expect the PSP to be there due to it being MIPS. Whats the good the bad and the ugly about the Wii/GC? I heard they're easy.

 

I wouldn't expect MIPS to be a feature that particularly makes a platform harder or easier.

I had a longer list, but I think it distills down to:
1) The more new stuff I have to learn for a new platform, the harder.
2) The harder it is to get the expected performance, the harder.

So, perhaps the easiest platform would be the PS TV, and the hardest would be the Saturn or the Wii (considering the expectations being set by the PS3/360).

As to the PSP, programming MIPS on it probably isn't any harder than learning ARM or PPC (and if you don't already know X86 assembly, easier than X86 as well), and besides a lot of the CPU differences are hidden behind a C compiler. Meanwhile, the fixed function graphics pipeline probably made that side of development simpler than the PS2 or modern shader development.

Also, development tools makes a big difference, so what is simplest for the professional with vendor supported development tools is likely difference from what is easiest for homebrew.

 

Programming for Wii is harder than PS3/360 then? Sure it had only 64MB of GDDR3 memory that is a tad slower than the 360's and has 24MB of 1T-SRAM integrated in the Vegas die of the ATI Hollywood but it really is harder? Its just a Gamecube on steroids.

 

The Wii has one of the most infuriating development environments, devkits and APIs I've worked with. That thing has caused me many headaches throughout my career.

If you want something easy to develop for, that's realistically within your grasp if you're not a development house, then my vote goes to the original Xbox. Its APIs will be familiar to you if you do Windows and DirectX coding, debug kits pop up on eBay from time to time (I got mine for £7!), and you won't be short of help from the community if you get stuck.

 

It's a pain in the ass basically? Ok cause i might develop something for the wii. Not sure what yet...

 

I'd have thought the N64 wasn't difficult to program for, but the limitations on ROM storage space meant the difficult part was fitting your game into an affordable ROM chip.

 

The main problem w/ the N64 was the RCP. You had to use special code called microcode. the stock SGI code sucked and making your own was a bitch. That didn't stop people like Rare from making amazing games though

 

I have all SDK doc about xbox, but nothing for Chihiro, if you have could you share it please. help neede for Chihiro game for Xbox.

 

Oh. I don't appear to have some docs I just know a Chihiro is an Xbox but with a different mcpx and with 128 mb of DDR RAM instead of 64 mb.

 

I wouldn't say the default ucode sucked - it was arguably more accurate (and hence lower performance) than it needed to be, though.

The biggest problem was the RAM - the N64 had a single block of 4MB that was used for everything, and because the old first-generation Rambus memory it was using could only have a single page open at once interleaving reads from different memory areas incurred a very large performance penalty (because the memory controller had to close the existing page, send the new block address, wait out the precharge time, open the new page and finally get the required data). Because of the shared memory architecture, it had a lot of work to do:

1) The display controller had to constantly read the front buffer to generate the display image
2) The RCP reads the display list to get the geometry for the next frame
3) The RCP writes out the data for the next frame to the back buffer
4) The RSP is reading sound data (this is fairly low rate, though)
5) The Main CPU is reading instructions and data and writing data (and it hits the memory a lot, since the L1 caches are small and there is no L2 cache).

All of these are going through the same memory subsystem and hence frequently incur the first-word timing penalty I mentioned above. The net result of all this is that despite the (for the time) huge theoretical bandwidth of the Rambus memory, in practice the system ended up spending a lot of time waiting for it.

 

Yea. Even though unified memory was efficient and was an SGI tradition, it kinda sucked because EVERYTHING had to be in it. The Expansion pack sorta helped but not by much.