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

[emigre]

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

 

[GamerzHell9137]

Love those devs that use 100% of the hardware for their games.

EDIT: 60 FPS video here http://www.vd-dev.com/News/IronFall_Tech_Preview_HighBitrate.zip

 

[FAST6191]

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?

 

[pasc]

GBA: Driv3r
DS: Cop
3DS: ???

They only always focus on the graphics, they tend to not care how a game will play.

 

[Hells Malice]

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

 

[Foxi4]

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.

 

[Veiva]

[qupt

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.

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.

 

[WoJjTeK]

Hmm it appeals to me, regardless of what method they used to achieve this. This level of graphics is sufficient for me to fully enjoy a 3d game. I don't know whether this is the peak of 3ds' capatibilities or not, but I'd like games to look like this ( or better ofc ^^ ).
Off topic : Tecmo, now gimme my Ninja Gaiden 3D! I know 3ds can pull this one off!

 

[Foxi4]

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.

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

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.

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

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.

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.

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.

 

[PityOnU]

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

That's... a little jaded, don't you think?

That kind of graphical fidelity running on a ~$150 portable system? I'd say it's more "impressive" than "embarrassing".

What would it take for you to be impressed? (serious question, not argument trolling)

 

[Veiva]

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

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.

 

[FAST6191]

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

Best might be the wrong term. I am sure if you dropped a bunch of the physics stuff and instead spent the resources tarting up the graphics. Probably also worth noting that it is a programmer's demo rather than an artists one and you also have either the uncanny valley or you find yourself in the unfortunate position of comparing to the PC and similar things -- for all the bashing Nintendo gets they do see to get the "let the graphics age gracefully" routine.

 

[Foxi4]

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

 

[Deleted_171835]

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

Dual-screen rendering at 60FPS in 3D (top-screen) while pushing some fancy effects.

It's pretty impressive, all it needs is some actual art-direction.

 

[zRussian]

The gameplay reminds me of Gears of War.

 

[Foxi4]

Dual-screen rendering at 60FPS in 3D while pushing some fancy effects.

It's pretty impressive, all it needs is some actual art-direction.

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.

 

[Wombo Combo]

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

 

[Foxi4]

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

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.

 

[Rinth]

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.

 

[TheCasketMan]

I am more excited for Jett Rocket 2. The game looks awesome and it looks fun too from some videos I saw.