Pretty. It's being developed by the same guys being COP on DS. And I think we all know how that turned out...

http://www.iron-fall.com

 

A nice little tech demo with some features I might not have expected.... might almost be enough to promote the 3DS from worthless to bad investment.

That said the aliasing... what did my poor eyes do to deserve that?

 

That's...kind of embarrassing if that's the best the 3DS is capable of.

 

[qupt

Actually... a human can optimize better than a compiler. How are you supposed to use SIMD instructions, or other low level ops that cannot be used in a high level programming language? Intrinsics are just "prettier" assembly.

And I disagree that by going "full on" assembly, you disregard established coding standards. For example, a piece of optimized software I'm comfortable using, LuaJIT, has an interpreter that is written entirely in assembly on supported platforms (ARM, x86, MIPS, others...), but does its author disregard established coding standards? No. The author of LuaJIT is capable of optimizing at a level a compiler can never reach, because he knows the platform (and these are generic platforms!) in-and-out. A compiler is generic. It can't know that you're targeting this one architecture where X feature is faster than Y feature under Z circumstances. In such a case, through profiling and human ingenuity, a good programmer can drop down and write the correct code--sometimes using assembly, when the need arises--and write code that would otherwise be too slow.

Now, I'm not necessarily defending this game. I'm just arguing your points about using assembly being the signs of a bad SDK or whatever.

 

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.

 

I don't need to be explained what printf does. In any case, even the best compiler doesn't know all the outside circumstances that arise during execution of the code. It can guess, but it can guess wrong. This happens more often than you'd think. A compiler can't optimize a matrix multiplication beyond basic collection of intrinsics, but it can't do much more than that. It takes hand-written assembly to ensure that a matrix multiplication is as fast as can be. I doubt Nintendo's SDK even provides matrix multiplication methods, either, to further this example. Game engines tend to roll their own, regardless.

And regardless of Nintendo's optimization abilities of their compiler, it's not going to know that a cache miss here as a result of an extra instruction is going to slow down this tight loop by over half. This is where a profiler and a good eye comes in. And what happens when the compiler generates suboptimal code? You have to write it yourself.

In any case, I do agree with your last statement.

 

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".

 

The gameplay reminds me of Gears of War.

 

Looks pretty cool would be cool to see games like that with a lot of enemies on the screen at once.

 

Graphical fidelity is the last thing I expect and look for on 3DS. I have my PC for shiny graphics. 3DS just needs to do its job and provide excellent gameplay when I don't have access to my PC.