3DS got two ARM11s

So with 3D mode disabled is the game merely rendered at 800x240 in 2D with added effects right?

Nobody actually knows if 800x240 is available or if it's stuck at 400x240. Everything in this thread is speculation.

We do know some features are only available with 3D off, but naturally those will be optional.
 
I'd be surprised if changing the viewport and a couple of pointers in the display pipeline would require "arbitrary-complex GPU and VRAM re-initialisation".
That'd be a best case scenario. We have no idea what facilities PICA features for optimised stereoscopy, and what it takes to reconfigure them into 'classic' 2D mode, and back again. It could be anything from negligible on the HW level, as you point out, but still requiring as a minimum a new set of shader assets better suitable for the new mode (thus subject to app's asset paths), to some sort of reset cycle on the HW, equivalent to a GL context reinit. For all we know, such a switch can be arbitrary complex.

Nintendo's images show that the slider is pretty clearly labelled "OFF" at the bottom. I'd expect it to actually be a switch in that position, i.e. it won't just slide to the off position, you'll have to push a bit harder and it will lock in place.
Could be. Somebody who's actually touched the thing could enlighten us here.
 
So do we guys really know the final spec of the 3DS? All we have are the claims from IGN and Engadget's analysy of those claims.
 
That'd be a best case scenario. We have no idea what facilities PICA features for optimised stereoscopy, and what it takes to reconfigure them into 'classic' 2D mode, and back again. It could be anything from negligible on the HW level, as you point out, but still requiring as a minimum a new set of shader assets better suitable for the new mode (thus subject to app's asset paths), to some sort of reset cycle on the HW, equivalent to a GL context reinit. For all we know, such a switch can be arbitrary complex.
Sure, software could decide to use different assets which could take some time, but surely this isn't more complex for the hardware than any other ordinary viewport or rendertarget change.

Code:
Brightness Approximated Continuous Play
1st level     15-19 hours
2nd level     10-15 hours
3rd level     7-11 hours
4th level     5-8 hours
An interesting thing to note here is that the parallax barrier display effectively cuts the screen brightness in half - after all it's designed to block half the pixels as seen from each eye.
 
I saw an article where someone believes Nintendo to be more likely to be using PICA200 Lite instead of PICA200. Here's the product page:

http://www.dmprof.com/english/e_products/e_pica200_lite/

It looks like it only has one TMU/ROP instead of the 4 the normal PICA200 appear to have. My question is, with this level of performance at 133MHz (with no mentioned bandwidth saving or overdraw eliminating technology) do the screenshots we've seen thus far seem feasible?

EDIT: Eh, nevermind, the feature set is clearly deficient.
 
I saw an article where someone believes Nintendo to be more likely to be using PICA200 Lite instead of PICA200. Here's the product page:

http://www.dmprof.com/english/e_products/e_pica200_lite/

It looks like it only has one TMU/ROP instead of the 4 the normal PICA200 appear to have. My question is, with this level of performance at 133MHz (with no mentioned bandwidth saving or overdraw eliminating technology) do the screenshots we've seen thus far seem feasible?

EDIT: Eh, nevermind, the feature set is clearly deficient.

A few things:

The DMP press release specifically mentioned the PICA200 not the PICA200 Lite.

The PICA200 doesn't seem to support any of the proprietary Maestro extensions and I don't think so many games could be making such liberal use of normal maps and per pixel lighting etc. without those.

We've seen a lot of comments from developers that are pleasantly surprised with the horsepower of the GPU, (and the results from the likes of Capcom, Team Ninja and Konami speak for themselves) I can't imagine too many jumping for joy if it was using the PICA200 Lite.

Whatever GPU Nintendo is using its probably customised from the stock version in some none trivial way, if only to help aid BC.
 
When I post an "EDIT" to say I posted impulsively and was clearly wrong no one reads them, I should just edit out my whole posts ;D

I personally doubt they customized the PICA200 to aid backwards compatibility because that's really fitting a round peg in a square hole. They probably just did what they always do and included the old hardware verbatim. This will make GBA emulation a lot easier for them too. Customized for something else is within the realm of possibility.

We haven't seen any comparable 3D on the second screen (or have we??), maybe Nintendo is only allowing a DS compatibility graphics chip to access it.
 
When I post an "EDIT" to say I posted impulsively and was clearly wrong no one reads them, I should just edit out my whole posts ;D

I personally doubt they customized the PICA200 to aid backwards compatibility because that's really fitting a round peg in a square hole. They probably just did what they always do and included the old hardware verbatim. This will make GBA emulation a lot easier for them too. Customized for something else is within the realm of possibility.

We haven't seen any comparable 3D on the second screen (or have we??), maybe Nintendo is only allowing a DS compatibility graphics chip to access it.

Oh but we have, the Sims 3 is one title that certainly does this. That's a full 320x240 3D framebuffer running on the bottom screen with texture filtering and 3D that is more complex than anything we saw in any NDS title, so yes, the PICA200 can render to that screen just fine.

As for modifying the hardware for BC, I'd say its clear they'd done something. Surely they plan to re-use that 4MB framebuffer for NDS mode (which eerily enough is the same size as the entire NDS memory pool, surely not a total coincidence) and is GBA emulation really a problem worth tackling with hardware? The system doesn't actually support GBA BC at all (neither did the DSi), there's only the possability of them being sold over the virtual handheld service but only GB and GBC titles have actually been conformed for that service so far, not GBA games. Software emulation will more than suffice for a few DD releases.

I didn't ignore your edit, I was just expanding on it, that's all. No harm in further backing up a point someone else has made.
 
Can you link me to Sims 3 screenshots demonstrating this?

GBA has been confirmed to be supported on the Virtual Console service. GBA emulation can probably be done w/o hardware, but they need the hardware for DS support anyway (DS 2D hardware is close to compatible with GBA, the differences are probably nothing that will break anything). Getting GBA emulation in full software on 266MHz ARM11 without skipping frames is at least difficult.

I'm sure RAM will be reused somewhere, but I'm talking about logic.
 
Can you link me to Sims 3 screenshots demonstrating this?

GBA has been confirmed to be supported on the Virtual Console service. GBA emulation can probably be done w/o hardware, but they need the hardware for DS support anyway (DS 2D hardware is close to compatible with GBA, the differences are probably nothing that will break anything). Getting GBA emulation in full software on 266MHz ARM11 without skipping frames is at least difficult.

I'm sure RAM will be reused somewhere, but I'm talking about logic.

I've neever seen any direct confirmation of that, just that it is likely to come down the road. Support seems to be limited to GC/GBC at launch.

GBA emulation on a 266mhz ARM11 may not be "easy" but when you've got every last ounce of hardware documentation, only need to support a tiny fraction of the system's library, can tailor the emulator to each and every software release and have some of the best emulation engineers in the industry working on the task, I don't think its anything close to insurmountable. Certainly not something that should influence hardware design.

Some Sims 3 shots here:

http://uk.media.ds.ign.com/media/077/077768/imgs_1.html

Its hardly demonstrating the most complex 3D graphics of course, but the textures are filtered and the game is rendered at 320x240. It seems to give a top down view of the same scenes displayed on the primary display, with no loss in quality. Clearly not running on NDS hardware, imo.
 
But they got 2 cpu's right? I assume they won't waste a whole cpu on security tasks. Besides that, even on the DS you got snes emu's that run games like donkey kong pretty well so I guess with the 3DS being a fair bit faster and nintendo having all the docs and manpower nintendo has like you said I suppose they could, if they wanted, emulate most gba/snes games pretty good if they wanted.
 
GBA emulation on a 266mhz ARM11 may not be "easy" but when you've got every last ounce of hardware documentation, only need to support a tiny fraction of the system's library, can tailor the emulator to each and every software release and have some of the best emulation engineers in the industry working on the task, I don't think its anything close to insurmountable. Certainly not something that should influence hardware design.

We have every ounce of hardware documentation too, essentially ;p At least everything that matters for sufficient emulation. Being able to tailor definitely helps, you can do all sorts of hacks to make things work better/faster. But that also means much work on their end.

I definitely don't think that they would do hardware for GBA emulation, I'm just reiterating that if they include the DS 2D/3D hardware they won't have to.

Some Sims 3 shots here:

http://uk.media.ds.ign.com/media/077/077768/imgs_1.html

Its hardly demonstrating the most complex 3D graphics of course, but the textures are filtered and the game is rendered at 320x240. It seems to give a top down view of the same scenes displayed on the primary display, with no loss in quality. Clearly not running on NDS hardware, imo.

Thanks. I'm not really convinced. In the top-down shots everything is at a far distance where I can't confirm filtering at all, and nothing about it looks beyond what DS can handle. Sometimes textures appear filtered when in reality they're just higher resolution than they look (and were filtered beforehand). Maybe some others can give their opinion.
 
The SOC is a Qualcomm MSM7227 with a 600mhz ARM11 and the GPU isn't completely awful like a lot of earlier Android phones. The huge 512MB of RAM should make a big differnce for general speed/responsiveness. Battery is 1250mah and I've heard no complaints about poor battery life so far.

[OT] After seeing your posts I popped into the local Orange shop at the weekend and bought one of these. Got 20 quid off it as well as my girlfriend works as a teacher and they offer 'perks' to public sector workers.

An unbelievable amount of phone for the money - great screen, good performance. Now just need to find someone to buy my old TouchHD. :D

[/OT and apologies]
 
Well the DS could show proper 3d on both screens at the same time so I don't see why the 3DS wouldn't be able to do the same. I just think that we won't be seeing it much as the whole 3D vision is one of the important parts of the handheld so I think most devs will only use the top screen to try and get the best gfx possible and just use the bottom screen for a map or inventory.
 
Well the DS could show proper 3d on both screens at the same time so I don't see why the 3DS wouldn't be able to do the same. I just think that we won't be seeing it much as the whole 3D vision is one of the important parts of the handheld so I think most devs will only use the top screen to try and get the best gfx possible and just use the bottom screen for a map or inventory.

Doing 3D on both screens at the same time was sort of a hack on DS, it didn't really support it natively and you had to give up a lot of VRAM to do it. Even then it wasn't actually rendering to both in the same frame, it alternated them, so you only got 30 FPS (which seems to be the target some devs are striving for on 3DS anyway)

Of course I'm not saying it isn't this way on the 3DS, it's just that they'd have to add another port on the VRAM in order to get two framebuffers to get 60 FPS on both, or accesses would have to be interleaved or something.

Even then it may still be the case that you can attach a DS-like rendering engine to the bottom screen, that's there for the purposes of BC but also available to 3DS games so they don't have to spend some of the PICA200's fillrate on filling that screen. This would follow pretty similarly to how two 2D engines were available on DS, and most games dedicated one of them to the second screen.
 
Epic says 3DS not powerful enough for the unreal engine.

"You couldn't do a game that looks like [Epic Citadel] on it, for example."
"....but I think if they considered that our engine would be good on it, they would have probably talked to us about it," Rein said."

To come out this early so negative, he's either very sure even though they havn't seen a device yet, or suggests epic has been somehow snubbed.

http://www.escapistmagazine.com/for...dos-3DS-Specs-Too-Low-for-Epics-Unreal-Engine
 
Epic is always bitching on Nintendo hardware so nothing new there. Probably this time they are just sad they spend all their time doing EC for the failphone while they could have made a fortune if they released such a engine for the 3DS I think.
 
Back
Top