Guise have you seen Iron fall? [60fps, graphic whore edition?)

Wow. That was hilariously bad.

Glaring spelling mistakes and the Microsoft Sam spokesman aside, congratulations on pushing 7 million polygons and making them look like ass. As we all know, graphical fidelity = polygon count, right?

I love it how people go nuts whenever they read "Assembly", as if using Assembly was equal to pushing the machine to its limits and getting the best performance, as if the concept of coding something in Assembly poorly was a completely alien one. Moreover, you can use coding prowess to great lengths, but if you have no artistic talent whatsoever, you'll end up with something that's technically advanced and yet horrible.

SDK's and function sets were created so that coders wouldn't have to deal with low-level functionality, Assembly is something you reach for when the SDK is insufficient and does not provide a necessary effect. Coding something in Assembly from the ground-up, including pre-existing effects already offered by the SDK isn't clever - it's smashing your head against a wall instead of using a door.

By going full-on Assembly, you completely disregard established coding standards in favor of a vague premonition of "better performance" which you may or may not reach.

 

This is all very true, however... I develop my point further later.

...and the 3DS's SDK is aimed at one platform. None of the issues you outline above apply to it in any way because the SDK's function set was created with one device in mind, it's already pretty damned optimized and it exists for the sole purpose of cutting down coding time. Let me give you an example:

Code:

printf("Hello World!");

This will make "Hello World!" print on-screen (or it will throw it into the console, either way, you get my point). This is convenient and it always results in the same, predictible output. The function was coded to do one particular thing. I could instead choose to write the exact same functionality in Assembly from the ground up, but by doing so I expose myself to a great number of threats:

• I could end up with a function that factually works worse than the SDK function
• I could make a mistake and create a loophole in the application that was not in any way predicted by the designers of the hardware
• I could waste a whole lot of my precious time
• I could make the function more wasteful than it needs to be by being forgetful and ommiting dedicated hardware embedded in the system and covered by the SDK, instead opting for the use of standardized Assembly functionality.

Needless to say, doing that is completely silly. The benefit of using Assembly in this particular case is close to none, it introduces nothing but convolution of the overall project.

My point is not "using Assembly is a sign of bad development", my point is "using Assembly where it doesn't need to be used" is.

 

And I agree wholeheartedy with what you're saying as well - there's only so much optimization the SDK can go through to squeeze out performance and going beyond that threshold does require speaking directly to the hardware using a low-level language, the lower the better.

What I'm also saying is that in a lot of cases doing so is completely unnecessary and by not abiding by the SDK standard, the developers can end up cutting themselves away from standardized 3DS services which weren't created with completely custom applications in mind.

As you said yourself, Assembly is a very powerful tool which you pull out when the standard compiler creates sub-par, sub-optimal code... but to use it as your main tool of coding? I find that to be convoluted - it doesn't serve any practical purpose, it's merely showing off your coding muscle. There's a term for coders like this "busy idiots".

 

But... rendering 3D on both screens is something the standard SDK does... It's not something "weird", it's not like with the DS which only had one 3D engine (Main Engine was capable of 3D, Sub Engine was not) where you had to copy frame buffers to get 3D on both screens, this device does it natively. Then again, it is at 60 FPS and with a lot of detail, so that part of it is impressive.

EDIT: Let me elaborate on my stance a little so that I don't sound 100% negative. The fact that I think using 100% Assembly is foolhardy and completely unnecessary, the tech demo does feature a couple interesting things in completely technical terms, like the high polycount or the use of lighting on the scenes which are genuinely rich.

My problems with it lay in more down to earth issues. The presentation is simply poor, the voice synthesizer voiceover is cheap, there's an odd typo from what I've noticed, the textures are blocky and the overall aesthetics look like something straight out of an App Store despite the technical superiority, and this is supposed to be a demo of a product which will eventually end up on the eShop, not just a tech demo of a game engine.

 

If you're referring to the skinning stress test, notice how all those "enemies" are moving at the exact same time, meaning their movement is likely controlled by one and the same script. They don't have independent A.I, they're not actual NPC's, they're animated models. I wouldn't equate that to a large number of enemies on-screen since enemies require you to run A.I for them independently.