-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
3DS Uses DMP's PICA200 GPU
- Thread starter charlequin
- Start date
- Status
crisdecuba
Member
This is an encouraging article - sounds like Nintendo's madeall the right decisions with the 3DS so far:camineet said:
* Improved GPU that strikes the right balance between graphical capabilities and low power performance
* Analog slider that improves upon the PSP nub
* Larger capacity game cards (up to 2GB)
* Backwards compatibility with the DS
* Higher resolution screens that strike the right balance between pixel density and cost (i.e. it's not a "retina display" but it's certainly much better than the DS)
* Improved wireless capabilities
* Hard-coding the "download stuff while in standby mode" so that it's not game-dependent
* 3D without glasses (this is the "system seller")
* Including a 3D slider to adjust the impact of the 3D effect
No wonder that third-party developers are signing on so quickly. Unlike the Wii and the DS, where the viability of the platforms were in somewhat in question, the 3DS is a clear winner from the outset.
This only makes me wonder how they will approach positioning the Wii successor to third parties. If they can replicate the "clear winner" perception, they'll have it made.
Shogmaster
Member
How is that interesting? You would be crazy not to consider IMG TECH for your 3D capable portable in the last 4-5 years.camineet said:
So here's a question for those knowledgable enough: do you think the 3DS could pull off effects like Object Based Motion Blur? I know Sony was able to fake (?) it on Shadow of the Collosus and Headstrong was able to do it in House of the Dead Overkill, but it was largely an effect seen on the "next gen" consoles. I personally love the effect and would estatic if the 3DS could do things like that with some proficiency. A port of Mirrors Edge would be...*sigh*
I was going to say not, due to the lack of programmable pixel shaders (which are needed to write motion vectors and perform the directional blur per pixel), but thinking again it is entirely possible to do it in the same way Shadow of The Collossus did by using vertex shaders.Veal said:
Camera motion blur is much simpler (even the Wii and PS2 can do it).
cyberheater
PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 PS4 Xbone PS4 PS4
Veal said:
You can use the accumulation buffer in OpenGL for blur effects. Not sure if thats what you would call 'Object Based Motion Blur'.
That's not object-MB though, it works on the whole screen based on velocities written on every pixel.Veal said:
Vertex shader per-object MB(ala SOTC) generally looks a lot better, but it scales poorly - expensive with a lot of objects(or big objects), and it's complicated to do with animated entities like characters.
Eteric Rice
Member
Log4Girlz said:
Are they still alive? Maybe they can?
http://nexus404.com/Blog/2010/06/23...fellow-japanese-company-dmp-for-graphics-gpu/
So if the 3DS is using the 200 MHz version from 2006, we'll get that 15m pps. around Gamecube level, slightly less actually.
http://www.siliconera.com/2010/06/22/3ds-development-costs-may-approach-wii-levels/
Eteric Rice
Member
I hope it's using the latest one. But it wouldn't bother me to much if it isn't, the games we've seen look nice.
Panajev2001a
GAF's Pleasant Genius
brain_stew said:You're scaring me Faf, I don't want another system plagued by texture aliasing!
Don't worry... you will be fine when they release 3DS-II and just like me when you started playing modern games on current generation systems, thankful that major texture aliasing were a problem of the past, and ...
you enter the sweet world of specular/shader aliasing...
Edge aliasing is becoming less of a problem (see MLAA in recent titles and maybe mixing MLAA and selective MSAA for subpixel sampling issues), but aliasing induced by the shiny pixels delivered by normal+reflection+whatever mapping is getting more and more of a problem.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
the only refreshing thing above is the author's oblivion of recent industrial history. that, and..another blog post sleuthed by camineet said:
don't you need to quote a source if you throw in something like that, mr. Schram?
you love SSAA. you know it.Panajev2001a said:
Panajev2001a
GAF's Pleasant Genius
blu said:
Well, that's a bit brute-force
.Bending_Unit_22
Member
So out of curiosity, would this be a chip Nintendo might use on their next home console? I can see the advantages it brings concerning handheld gaming, but is it something that with more pipelines and a higher clock rate would make a good/great console GPU?
Sorry if I got terms mixed (or made) up. I'm not too technically minded, though I love reading about it. Was the PS2 able to do that motion blur due to its insane amount of pixel fillrate? Also, is it completely impossible for one to write custom shaders for the 3DS? Or is it a case of a developer not wanting to go through the trouble, so Nintendo made it somewhat easier?Fafalada said:
charlequin
Banned
Bending_Unit_22 said:
There's literally no reason for them to use a chip like this in a home console. Even if they continue a Wii-style low-power strategy (which I'm sure they will) they'll have room to go with a real console-oriented GPU with full pixel shader support and other modern features.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
IMO the major conclusion we can draw from the known 3DS specs is that nintendo are not adverse to giving devs easy-to-develop-for platforms.Instro said:
the wii was a bit of a good-intentions-turned-bad there - on one hand nintendo'd have assumed it should've been easy to develop for (second generation of the same architecture, old engines running on it out-of-the-box, yadda-yadda) but in practive the gamedev world had departed in both architecture understanding and assets creation skills. so we all know the end result.
Just realized one MAJOR drawback of the 3DS.
There's going to be significantly less sprite-based games.
If you're making a game based on 3D polygonal models, you only need to program one environment. All you need is a second in-game camera.
But with sprite based? You'd basically have to do extensive parallaxing and then create two simultaneous graphics environments at once. So you have to work twice as hard to make a sprite-based game as you usually would.
Edit: It's like making games for the Virtual Boy.
There's going to be significantly less sprite-based games.
If you're making a game based on 3D polygonal models, you only need to program one environment. All you need is a second in-game camera.
But with sprite based? You'd basically have to do extensive parallaxing and then create two simultaneous graphics environments at once. So you have to work twice as hard to make a sprite-based game as you usually would.
Edit: It's like making games for the Virtual Boy.
yankee666
Member
ZealousD said:
Well, on E3 they showed some sprite based games from Nes and Snes on 3D. So We can hope for a 3DSware or 3D Virtual console re-release of those classics in 3D
http://www.nintendoworldreport.com/newsArt.cfm?artid=23421
yankee666 said:Well, on E3 they showed some sprite based games from Nes and Snes on 3D. So We can hope for a 3DSware or 3D Virtual console re-release of those classics in 3D
http://www.nintendoworldreport.com/newsArt.cfm?artid=23421
Are these really in 3D?
Twilight Princess
Member
PICA? PICA!
Ignis Fatuus
Banned
It's going to be harder for the Wii successor no matter what they do, I think. The Wii has competition whereas the 3DS does not seem to.crisdecuba said:
AceBandage
Banned
Twilight Princess said:
PICACHUUUUUU!
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
hope you don't mind if i return to an older subject from this thread. i just cought up on the whole talk of SSAA through camera jitter, and i don't think the trick would be plausible. let me explain why.
jittering AA is based on miniscule pannings of the geometery in *screen* space. that requires one essential thing - fixed precision of the jittering offset as per screen space. jittering the camera does not do that - it operates in world space, prior to applying perspective division. so what that means is that the jttering effect would vanish with increasing distance from the front clipping plane - things on the front will receive jitter, while things in the back - won't. that could be countered through 'inversing' the perspective effect for the jitter offset in the vertex shader, per vertex. not accounting for the performance implications of that (essentially, it won't be free), that takes us to the second issue with this approach: *fixed* precision.
floats are not good at fixed precision. namely, their precision drops with increasing the magnitude of the number. that's why all jittering SSAA solutions i'm aware of apply the effect in fixed-point precision, in (or near to) the final stages of the vertex pipeline - screen-space mapping. what that means for the camera-jitter approach is that the effective jitter, even if applied per vertex in the vertex shaders, will not be constant across the depth range of the camera frustum. or simply put, your jitter will, erm, jitter with varying distance from the camera.
what does it all mean? that (1) the approach won't be fee when used with perspective-projection cameras (could be free with ortographic, though), and (2) regardless of the projection type, the effect would exhibit artifacts, depending on the depth span of the view frustum, so the frustum will have to be tweaked and tuned to minimise that. IOW, the approch would be free neither computationally, nor in terms of implications on the graphics pipeline design.
last but not least, StarFox demo was confirmed to be running in 3D, which makes the camera jittering even more complicated (or flat impossible, depending how you look at it).
jittering AA is based on miniscule pannings of the geometery in *screen* space. that requires one essential thing - fixed precision of the jittering offset as per screen space. jittering the camera does not do that - it operates in world space, prior to applying perspective division. so what that means is that the jttering effect would vanish with increasing distance from the front clipping plane - things on the front will receive jitter, while things in the back - won't. that could be countered through 'inversing' the perspective effect for the jitter offset in the vertex shader, per vertex. not accounting for the performance implications of that (essentially, it won't be free), that takes us to the second issue with this approach: *fixed* precision.
floats are not good at fixed precision. namely, their precision drops with increasing the magnitude of the number. that's why all jittering SSAA solutions i'm aware of apply the effect in fixed-point precision, in (or near to) the final stages of the vertex pipeline - screen-space mapping. what that means for the camera-jitter approach is that the effective jitter, even if applied per vertex in the vertex shaders, will not be constant across the depth range of the camera frustum. or simply put, your jitter will, erm, jitter with varying distance from the camera.
what does it all mean? that (1) the approach won't be fee when used with perspective-projection cameras (could be free with ortographic, though), and (2) regardless of the projection type, the effect would exhibit artifacts, depending on the depth span of the view frustum, so the frustum will have to be tweaked and tuned to minimise that. IOW, the approch would be free neither computationally, nor in terms of implications on the graphics pipeline design.
last but not least, StarFox demo was confirmed to be running in 3D, which makes the camera jittering even more complicated (or flat impossible, depending how you look at it).
lostinblue
Banned
You wet blanket.camineet said:
Those are good observations.blu said:
I will just go ahead and state that the solution is to jitter the near plane and not the location of the camera, i.e. to shear the view frustum such that the eye remains fixed while the near plane is displaced by (s,t), where (s,t) corresponds to the sampling offset multiplied by the dimensions of a pixel on the near plane.
Correct on camera jitter. But for this kind of AA you jitter the viewport(as volmer already pointed out), which is just one matrix down the line from Camera, and therefore doesn't change the cost either.blu said:
That said, I'm gonna go pedantic on this one - this is Accumulation AA, not SS - notable advantage being that samples are not on an ordered grid, but can use any of the more optimal distributions we want.
Admittedly, it won't make a huge difference with only 2 samples (it does with 4 or more) but still.
brain_stew
Member
Fafalada said:
Well if the result is as as good as the AA in GT PSP then I think that's still a pretty significant increase in image quality. If the PICA2000 does indeed have issues with mip mapping as suspected and without any MSAA support either, anything that helps alleviate aliasing is going to be worthwile imo.
Just going off the screenshots released, Starfox (which is believed to be demonstrating the accumulation AA) looks much cleaner than Kid Icarus for instance (a game which has some pretty severe issues with aliasing).
brain_stew
Member
Durante said:
Oh, my bad.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
i interpreted volmer's argument slightly differently - one could jitter the lateral clipping extents of the view frustum (thus affecting the clipping stage's inequality of -W < { X, Y } < W), and that indeed would be both free and produce perspective-correct jitter of the geometry in screen space, but it could suffer from the same unstable precision when going deep into large view frustums.Fafalada said:
jittering the viewport would be the ideal solution (as you noted it's the right stage of the pipeline to apply jittet at), if the viewport could be defined in sub-pixel coorinates. traditionally viewports in openGL are defined in integer coordinates, which would produce a rather rough jitter. of course, nobody says nintendo should stick to the letter of OGL in their SDK.
Possibly I misread it as well - anyway, viewport offsets is the proper way (and how we've always been doing itblu said:
- accumulation AA is actually fairly common practice for print-screenshots, combined with tiling).Even OpenGL allows you to set your own projection matrix, and if this thing really works with any sort of programmable pipeline you will have to do that anyway.
But yea, it'd be a surprise to see OGL compliant console as well. ES has been trying for 7 years and hasn't made it into a single dedicated game-platform.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
you're referring to the ps2, i assume?Fafalada said:Possibly I misread it as well - anyway, viewport offsets is the proper way (and how we've always been doing it
that takes us back to volmer's suggestion (i.e. jittering the frustum's x/y-extents in the projection transform), as the projection matrix and viewport/window mapping transform are separate parts in the GL pipeline (either programmable or fixed-function). there projection produces clipping space with a 'hard-coded' clipping inequality of (-w <= { x, y, z } <= w), then homogeneous division yields NDC space ( [-1, 1] in all directions), which after the viewport transform yelds screen space (a simple linear ax + b transform). basically the viewport's rect has the final say of screen mapping. what you suggest could be done if (a) the viewport rectangle accepted fractional coords (and then used sub-pixel correction to account for the snapping-to-integer), or (b) one had control over the frustum clipping condition, so that one could incorporate the screen-space mapping directly into the projection transform. in GL you have neither of those though, and from what i remeber in d3d neither (though it was a real long time since i last delt with it).
it made it pretty darn close with the idevices though, and something tells me it will continue getting closer to dedicated game platforms in the future. i think it's time you made peace with it : )
AceBandage
Banned
Jeels said:
Is good stuff, mang.
Blu,
Since the GPU supports vertex shaders, it's just a matter of adding a small X/Y offset to the vertex position *after* the transformation to screen coordinates. Bam! Jittered.
Also, this can be done in 3D: just let the LCD ghosting do the "blending" for you. I remember a DS homebrew demo that simply jittered the texture coordinates. Due to the LCD lag, the texture looked slightly filtered. Of course it only works for 60fps games.
Since the GPU supports vertex shaders, it's just a matter of adding a small X/Y offset to the vertex position *after* the transformation to screen coordinates. Bam! Jittered.
Also, this can be done in 3D: just let the LCD ghosting do the "blending" for you. I remember a DS homebrew demo that simply jittered the texture coordinates. Due to the LCD lag, the texture looked slightly filtered. Of course it only works for 60fps games.
- Status