Topic: XBox 360 developer guidelines

[KDR_11k]

here

Sounds like the X360 will suffer some serious memory bottlenecks and many games won't properly make use of the multithreading (no way those three functions listed are equal in CPU usage).

Also, the guides pretty much tell you to make your game impossible to port to Mac/Linux because you're supposed to use the Windows API. Wasn't that an undocumented mess that MS won't give the specs for because they're afraid it'll uncover huge security holes?

[OptimusPrime]

See the RAM as a really fast hard drive, use the L2 as much as possible... i don't know but that easily translates to "there's something wrong with our RAM memory...seriously". i'm geussing their RAM memory is some cheap-ass stuff but it isn't known to the public.

And that multithreading thing is a bit confusing...i thaught the key was to program for multi-core and then multi-threading and that would yield more power. And how could it be impossible to port X360 games to the Mac, they use the same CPU architecturebasis which was the main reason why Mac get so few PC-ports. Or did i get lied too again? I hate that...

[KDR_11k]

"RAM memory, copyright 1981-2005 Department of Redundancy Department"

RAM= Random Access Memory

And that multithreading thing is a bit confusing...i thaught the key was to program for multi-core and then multi-threading and that would yield more power.

You got your terminology confused. Multi-core is the physical layout, Hyper Threading is a CPU feature and multithreading is a software problem.

And how could it be impossible to port X360 games to the Mac, they use the same CPU architecturebasis which was the main reason why Mac get so few PC-ports. Or did i get lied too again? I hate that...

Adopting it to PPC is using a different compiler and changing casting and disk read/write behaviour to big-endian, the big problem is that most Windows games were written for DirectX and the Windows API. OSX offers the BSD API and OpenGL, with no unified solution for the rest of DirectX. SDL would be the best choice for cross-platform but at least in the beginning it won't be available for the X360. Since MS tells devs to use (Windows-specific) API features instead of (common C) language features, porting will be harder.

[Djunknown]

I'm not one to jump into spec discussions(Since I'm out of my league..) but I got some questions and comments (Most likely the questions will be WDTM? What does this mean?)

Here we go:
•Multithread your game engine. Single-threaded games use only a third of the potential processing power of the system.
WDTM? Is multi-threading a common thing now?

•For best performance, prefer native Windows functions to C runtime functions. For instance, prefer ReadFile over fread.

Does MS have a grudge against C/C++? I thought those were more universal...

•Support a 16:9 widescreen aspect ratio. Support a minimum frame buffer size of 1280 × 720.

Does this mean have 720p as minimum, just like they said before?

Interesting nonetheless. I didn't understand it all, but its nice to get an inside view on what devs 'should' do.

[KDR_11k]

Is multi-threading a common thing now?

No, most games use singlethreading or split some secondary things into another thread (graphics, sound, network, etc). True multithreading is hard as hell to write for selftaught coders like those you find in the games industry.

Does MS have a grudge against C/C++? I thought those were more universal...

I think they won't allow much direct hardware access and will force you to go through the firmware for saving and stuff. Sure, they could adjust the base stuff in their XDK compiler but why would they want to if they could force you to write code that's harder to port to Linux or OSX?

Does this mean have 720p as minimum, just like they said before?

Yep, every game must support at least that resolution. I hope they'll allow for 4:3 output, I'd hate to waste those pixels with stupid black bars that are just a relic of the construction troubles with cinema screens.