Support NeoGAF

[Baron Doggystyle von Woof]

We need more screens of the possible graphics! (Yes I have seen the tech demo of the chip)

 

[AceBandage]

We need more screens of the possible graphics! (Yes I have seen the tech demo of the chip)

 

[Baron Doggystyle von Woof]

 

[blu]

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.

and therein lies the problem - you forget that the transformation to screen coords does not happen in the vertex shader. disregarding the viewport transform, the homogeneous division occuring after the vertex shading stage would make the small constant offset vanish with depth (you may have missed this earlier post).

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.

anatema!

 

[M3d10n]

and therein lies the problem - you forget that the transformation to screen coords does not happen in the vertex shader. disregarding the viewport transform, the homogeneous division occuring after the vertex shading stage would make the small constant offset vanish with depth (you may have missed this earlier post).

Hmm... then I'm sure it can be done by manipulating the view matrix. Because that's how you pan and crop the view for stuff like tiled rendering.

 

[Digital-Hero]

Below GC, above DC, but with modern shaders.

Lies! Is it really better than PowerVR 2 in the amount of geometry it can display?

 

[pcostabel]

and therein lies the problem - you forget that the transformation to screen coords does not happen in the vertex shader. disregarding the viewport transform, the homogeneous division occuring after the vertex shading stage would make the small constant offset vanish with depth (you may have missed this earlier post).


anatema!

Hmmm, the projection matrix multiplication does happen in the vertex shader.
You can pass screen coordinates as input stream to a vertex shader and output them unchanged for 2D rendering.

 

[blu]

Hmm... then I'm sure it can be done by manipulating the view matrix. Because that's how you pan and crop the view for stuff like tiled rendering.

that's what volmer said, to which i generally agree, if it was not for the float's effect of losing precision with magnitude. IOW, you have to make sure view frustum does not kill your jitter with going into depth; the fp computation (x + j) / z would make j (our jitter amount) disappear for large-enough z. that's why, as Faf rightfully noted, the best place to do the jitter is in the viewport mapping. which has its own implications that i was discussing in that post you commented on : )

 

[blu]

Hmmm, the projection matrix multiplication does happen in the vertex shader.
You can pass screen coordinates as input stream to a vertex shader and output them unchanged for 2D rendering.

yes - for 2D rendering (orthographic projections - yay!) try to do the same with 3D now ; )

 

[pcostabel]

yes - for 2D rendering (orthographic projections - yay!) try to do the same with 3D now ; )

Out.position = mul(viewprojection, In.position);
Out.position.x += jitter;
Out.position.y += jitter;

 

[blu]

Out.position = mul(viewprojection, In.position);
Out.position.x += jitter;
Out.position.y += jitter;

perspective division?

 

[EVH]

What about vectorized graphics, like LocoRoco? Does this include something about that?

 

[pcostabel]

perspective division?

Ok, I see what you mean.

Out.position = mul(viewprojection, In.position);
Out.position.x += jitter*Out.position.w;
Out.position.y += jitter*Out.position.w;

 

[blu]

Ok, I see what you mean.

Out.position = mul(viewprojection, In.position);
Out.position.x += jitter*Out.position.w;
Out.position.y += jitter*Out.position.w;

no, i meant division. as in that thing that can blow up your rationals if you don't clip *before* it.

 

[lostinblue]

What about vectorized graphics, like LocoRoco? Does this include something about that?

They should be possible, flash uses that and it runs on inferior platforms, so...

Question would be if vector graphics are supported by hardware or have to be done through software/specific code. Either way though, should be pretty doable.

 

[pcostabel]

no, i meant division. as in that thing that can blow up your rationals if you don't clip *before* it.

Hm, not sure I follow. The output position is transformed into clip space by dividing by the homogeneous coordinate, so the above should yield an offset of jitter in clip space...
What am I missing?

 

[Gahiggidy]

We need more screens of the possible graphics! (Yes I have seen the tech demo of the chip)

By the way, has everyone seen the trailer to this screen shot? I looks truly incredible for a hand held.

 

[Graphics Horse]

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.

Yeah, and should be better than that as it tended to go away once your car started moving!
Not read the whole conversation but I think the AA only being shown on Starfox suggests it being only efficient when you can afford to draw the whole scene twice.

I looks truly incredible for a hand held.

Yeah, Literally. 800x480 and impercievable aliasing. But there is an interesting dithering pattern used, for some alpha effects I think. not sure what that's all about.

 

[blu]

Hm, not sure I follow. The output position is transformed into clip space by dividing by the homogeneous coordinate, so the above should yield an offset of jitter in clip space...
What am I missing?

my bad, i thought you were trying to simulate a 3D pipeline in 2D, whereas you were actually addressing what i said earler - namely that the perspective division has to be countered. yes, that would work. but my point was it would not be free as the original assumption said (it's an extra vector multiplication per vertex). generally, the discussion has been about if such a 'free' solution could be found.

 

[volmer]

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's not strictly necessary to fiddle with the details of the projection matrix itself in order to shear the view frustum. Because the view frustum is defined with respect to view space, it should be clear that we can also shear the view frustum by applying the inverse shear matrix to points in view space. If the shear matrix is given by S, then the resulting composite transform is given by P S^-1 V, where P is the projection matrix and V is the view matrix. Therefore, even if you absolutely cannot touch the projection matrix, you can always incorporate S^-1 in the construction of your view matrix. Again, because the near plane is essentially the viewport in view space, the shear factor should take into account the size of a pixel on the near plane.

 

[blu]

volmer, i'm not arguing against tweaking the projection matrix - that is a free op, and thus, if it could deliver the result it would be a fine candidate for the trick. what i'm saying is that anything involving tweaks in or around the projection transform will potentially suffer from losing the fine effect after perspective division. unless one can have certain rigid guarantees about the view frustum parameters, relying on homogeneous division to preserve sub-pixel-precise quanta is unsafe.

viewport mapping is a much safer place to perform numerically-robust, free ax+b effects - it's past frustum clipping, thus has fixed ranges and no divisions. it's there you'd normally plug a jitter, and in this regard Fafalada is correct. it's just that you need lower-level access to the transform-clip-map pipeline to achieve that, compared to what OGL provides. basically, you need custom clipping+projection logic *or* sub-pixel-precise viewports, whereas OGL gives you 'merely' custom projection matrix and integer-precision viewports.

does anybody here remember 3dfx's jitter-accumulation FSAA in the VSA100 chips? it essentially constituted sub-pixel jittering to the viewport mapping, and it worked well.

 

[volmer]

volmer, i'm not arguing against tweaking the projection matrix - that is a free op, and thus, if it could deliver the result it would be a fine candidate for the trick. what i'm saying is that anything involving tweaks in or around the projection transform will potentially suffer from losing the fine effect after perspective division. unless one can have certain rigid guarantees about the view frustum parameters, relying on homogeneous division to preserve sub-pixel-precise quanta is unsafe.

AFAIK this is basically a non-issue in practice. The reason is that one can observe exactly the same numerical instability when the camera moves or rotates, when a vertex moves in the distance, or when the resolution of the render target is increased (since this causes smaller sampling intervals in the rasterizer).

 

[redbarchetta]

By the way, has everyone seen the trailer to this screen shot? I looks truly incredible for a hand held.

I saw it; looked great in motion. Too great. I don't buy for a moment that the final game will look anywhere near that good.

 

[wsippel]

What about vectorized graphics, like LocoRoco? Does this include something about that?

You can render 2D vector graphics using 3D GPUs just fine. But DMP also offers an OpenVG compliant 2D accelerator called PICA-VG. This thing offers everything from hardware accelerated Flash to font rendering (using Monotype iType for example). PICA-VG is an optional module for PICA-FBM, a 2D image post-processor that's part of PICA200. Maybe Nintendo licensed that module as well. To quote DMP's 2006 press release:

PICA-FBM (image post-processing module) quickly generates high-quality images for the final output to screens, through full-scene anti-aliasing, multi-layer compositing (maximumof eight layers), a resizing function, a color and spacing conversion function, a scrollingfunction, etc. Furthermore, PICA-VG (vector graphics module) will enable the developmentof high image quality, operability, excellent 2D maps, and skin UIs, etc

 

[brain_stew]

Yeah, and should be better than that as it tended to go away once your car started moving!
Not read the whole conversation but I think the AA only being shown on Starfox suggests it being only efficient when you can afford to draw the whole scene twice.




Yeah, Literally. 800x480 and impercievable aliasing. But there is an interesting dithering pattern used, for some alpha effects I think. not sure what that's all about.

Yeah, I noticed that as well, it looked like a ghosted double image or something? Dunno what was up with that, any theories?

 

[lostinblue]

You can render 2D vector graphics using 3D GPUs just fine. But DMP also offers an OpenVG compliant 2D accelerator called PICA-VG. This thing offers everything from hardware accelerated Flash to font rendering (using Monotype iType for example). PICA-VG is an optional module for PICA-FBM, a 2D image post-processor that's part of PICA200. Maybe Nintendo licensed that module as well. To quote DMP's 2006 press release:

Heh, doing menu's/GUI on vector formats would be a really future proof way of doing stuff, kinda surprising it took so long to be talked about let alone implemented.

Last gen definetly could have used it, I suspect middlewares just ignored it.


I wonder if, if used cleverly it could also contribute to some kind of cel shaded anti-aliased look "for free"; I mean, this could definitely be used to make outlines on a 3D cenario, it would be done on top of the rendered edges therefore be essentially 2D applied over 3D but it has an edge filter as standard... right?

 

[JimboJones]

Sorry if this is a stoopid question but what does this mean for backward compatibility, emulation? Or will there still be old DS bits inside it to make it 100% compatible?

 

[ILikeFeet]

Sorry if this is a stoopid question but what does this mean for backward compatibility, emulation? Or will there still be old DS bits inside it to make it 100% compatible?

at this point, I don't think anyone knows. we need to wait until Nintendo reveals the innards or someone does a tear-down

 

[Grampa Simpson]

Sorry if this is a stoopid question but what does this mean for backward compatibility, emulation? Or will there still be old DS bits inside it to make it 100% compatible?

Assuming that it's an ARM CPU, then it's just a matter of High Level Emulation for rendering the old graphics on the new GPU. They may even be able to do something cool like library substitution.

 

[lostinblue]

Assuming that it's an ARM CPU, then it's just a matter of High Level Emulation for rendering the old graphics on the new GPU. They may even be able to do something cool like library substitution.

The GPU on the DS was very custom and hard to emulate on high level emulation (just look at the specs DS emulators ask for). I also believe the ARM's were custom, but seeing how the business model for arm is, implementing those onto a new cpu shouldn't be a problem.

I wonder if different/more evolved cpu architectures like Cortex A8 wouldn't create a few speed glitches when it comes to running DS ARM code though, seeing how DSi had the same chips clocked higher and it ran DS games by underclocking the very same cpu's, a cortex can certainly do more instructions per second at the same clockspeed, making it effectively faster even when downclocked, so... I wonder how they'll do it.

what do you mean by library substitution?


I hope DS games being rendered on it have an option to use the extra resolution of the screens providing the ratio is kept... and add 2xAA on all games (yeah some had it... some didn't), but I doubt it, nintendo usually doesn't enhance their games playback via backwards compability "stuff".

 

[Graphics Horse]

The GPU on the DS was very custom and hard to emulate on high level emulation (just look at the specs DS emulators ask for).

I'd expect them to go with a lower level emu than that, telling the gpu what to render line by line rather than poly by poly, if that's what homebrew emus do. However, I'm guessing they've included an upgraded DS core also capable of high quality 2D (supersampled, see pilotwings shots) for maps etc. on the bottom screen to take the heat off the main GPU.

 

[Sipowicz]

brain_stew do you know how good the graphics are yet or do you need more information?

 

[lostinblue]

I'd expect them to go with a lower level emu than that, telling the gpu what to render line by line rather than poly by poly, if that's what homebrew emus do. However, I'm guessing they've included an upgraded DS core also capable of high quality 2D (supersampled, see pilotwings shots) for maps etc. on the bottom screen to take the heat off the main GPU.

I dunno. keeping the ds hardware around might come in handy, certainly, like the GBA kept the GBC z80 around until it was stripped on the GB micro, and I believe some games like V-rally actually used it for sound, such cpu's if used for other tasks would be quite powerful for what they are, stuff like running the OS in background, music, bottom screen stuff... who knows really.

But perhaps they didn't for all we know nintendo never went over $200 on a handheld, and they're really stepping on it now, costs should be a issue if they're trying to price it under $200, and I bet they are.

 

[Grampa Simpson]

what do you mean by library substitution?

The way I understand it is that Nintendo didn't give developers direct access to the GPU They gave developers a library (think DLL) and headers which they compiled against. The developers then included the libraries they compiled against in the rom - which contains a filesystem anyway. Nintendo has the source to these libraries and would have ported them to the GPU for the 3DS. These libraries will have some differences on the 3DS to deal with the new GPU and the higher resolution, but they will be accessed in exactly the same manner. When the DS loader for the 3DS starts, it reads the filesystem on the DS cartridge. It finds out what versions of the libraries are included on the DS cartridge, and then substitutes the equivalent libraries that are stored in the 3DS firmware.

There you go. DS graphics on the 3DS without hardware emulation.

Brain Stew can tell me if I've made any horrible mis-assumptions.

 

[Jason's Ultimatum]

brain_stew do you know how good the graphics are yet or do you need more information?

Is this your first time posting in this thread?

 

[lostinblue]

The way I understand it is that Nintendo didn't give developers direct access to the GPU They gave developers a library (think DLL) and headers which they compiled against. The developers then included the libraries they compiled against in the rom - which contains a filesystem anyway. Nintendo has the source to these libraries and would have ported them to the GPU for the 3DS. These libraries will have some differences on the 3DS to deal with the new GPU and the higher resolution, but they will be accessed in exactly the same manner. When the DS loader for the 3DS starts, it reads the filesystem on the DS cartridge. It finds out what versions of the libraries are included on the DS cartridge, and then substitutes the equivalent libraries that are stored in the 3DS firmware.

There you go. DS graphics on the 3DS without hardware emulation.

Brain Stew can tell me if I've made any horrible mis-assumptions.

I suspect it doesn't work that way, you have full access to the hardware on the DS, and stuff like that can be circumvented anyway and will on a market leading platform such as the DS, in the quest for "pulling out something better than <insert existing product/franchise>, kinda like how on N64 you could run your own custom graphics microcode (not so on the DS but still) I reckon Shin'en was saying something like "we actually pulled out stuff that works like shaders/full particle system" on the DS for example, and I doubt that was supported via those preset Nintendo tools and libraries... or that they had to give them their libraries.

You'll have to emulate the hardware itself, I suspect, if you want the compatibility to be 99/100% that is..

 

[Grampa Simpson]

I suspect it doesn't work that way, you have full access to the hardware on the DS, and stuff like that can be circumvented, kinda like how on N64 you could run your own custom graphics microcode (not so on the DS but still) I reckon Shin'en was saying something like "we actually pulled out stuff that works like shaders/full particle system" on the DS for example, and I doubt that was supported via those.

You'll have to emulate the hardware itself, I suspect.

Or maybe some games just won't work.

 

[lostinblue]

Or maybe some games just don't work.

Perhaps so.

Judging from the virtual console was injecting scene Nintendo emulators are certainly not flawless. But they also don't read cartridges which this will... and we gotta see that, unlike nintendo's virtual console this part will be crucial on an early transition period; Dragon Quest IX for instance (and golden sun) are coming really close to 3DS's own launch, those will have to run on it, at least.

 

[Graphics Horse]

There you go. DS graphics on the 3DS without hardware emulation.

I was thinking it was more about how the DS GPU hardware is emulated, which is probably closer to a GBA style sprite rasteriser with perspective correction than your standard 3D GPU. I don't expect them to up the resolution of DS games as it will mess up anything designed for 2D pixel art. Can't remember what PSone games look like emulated though, maybe it's not that bad.

 

[lostinblue]

I was thinking it was more about how the DS GPU hardware is emulated, which is probably closer to a sprite rasteriser with perspective correction than your standard 3D GPU. I don't expect them to up the resolution of DS games as it will mess up anything designed for 2D pixel art. Can't remember what PSone games look like emulated though, maybe it's not that bad.

they look kinda horrible when rendered on a substancially higher resolution, seeing there's no perspective correction and their 3D lacks absolute spacial coordinates, instead being a sort of "polygon snap to point" to a 320x240 grid (most of the times lower).

utter horrid when you're trying to run stuff at, say, 1280x960. (4 times the resolution)

 

[Graphics Horse]

they look kinda horrible when upscaled, seeing there's no perspective correction and their 3D mode lacks absolute spacial coordinates, instead being a sort of "polygon snap to point" to a 320x240 (most of the times lower) grid.

Sorry I meant to say 2D PSone games, I know what the 3D ones look like

 

[lostinblue]

Sorry I meant to say 2D PSone games, I know what the 3D ones look like

oh.

I've never used filtering modes aking to SNES emulators (hq2x, 2xsal, etc) via their plugins so I wonder if those options are there, scaling to resolutions that are not exact multiples without filtering will most likely screw up the way pixels look (hint: totally not square) and it'll be most visible on lower resolution screens, the way PSP does it on psone games, by rendering it on native resolution and then upscaling and blurring it a bit would be optimal, probably (gets rid of dithering too, although that's not a DS issue).

 

[Grampa Simpson]

Render then scale as blitting to the screen would probably be the best looking. That's how I usually emulate PS1 games when on an HDTV. I think their best bet for most 3D rendering for DS games is via ported libraries though. They may also have to do per game option sets which will improve over time.

Or they could just include a DS GPU and make the whole process easier.

 

[lostinblue]

Or they could just include a DS GPU and make the whole process easier.

Or, since this deal is like winning a jackpot to the owners of this chip... perhaps they can ask them to add all specific instructions and calls into this gpu.

 

[Nuclear Muffin]

The GPU on the DS was very custom and hard to emulate on high level emulation (just look at the specs DS emulators ask for). I also believe the ARM's were custom, but seeing how the business model for arm is, implementing those onto a new cpu shouldn't be a problem.

I wonder if different/more evolved cpu architectures like Cortex A8 wouldn't create a few speed glitches when it comes to running DS ARM code though, seeing how DSi had the same chips clocked higher and it ran DS games by underclocking the very same cpu's, a cortex can certainly do more instructions per second at the same clockspeed, making it effectively faster even when downclocked, so... I wonder how they'll do it.

what do you mean by library substitution?


I hope DS games being rendered on it have an option to use the extra resolution of the screens providing the ratio is kept... and add 2xAA on all games (yeah some had it... some didn't), but I doubt it, nintendo usually doesn't enhance their games playback via backwards compability "stuff".

I'm sure that Nintendo would be capable of writing a better DS HLE emulator than those on the PC. Hell isn't the Wii version of FFCC Echoes of Time just the DS version running in an emulator?

Oh and Nintendo do tend to enhance their old games on new hardware (Look at the VC and how much better the games look, especially N64 games). Given what we can gather about the 3DS' performance, I'd say that it should be capable of emulating the DS with few problems.

The interesting point is that Nintendo have never gone with a system-wide emulation system before (Choosing to write custom emulators for each VC game instead of a one-size-fits-all emulator like MS and Sony), that is the one thing that casts a bit of doubt in my mind since Nintendo have always had perfect BC compatibility with all of their consoles that have supported BC in one way or another (and per game emulation ALA VC is impossible).

Having the old hardware inside the machine also would allow them to use it as a sub processor to take some of the load off the main CPU, particularily for wireless operations like on the original DS which used a beefed up GBA ARM 7 processor (Would also fit well with the idea of a permanent system wide "bark mode" connection being used. That way it wouldn't impact system performance when it is turned on)


Both methods have distinct advantages. Emulation would make 3D DS games look better and would lower the cost of the machine but using a system-wide emulator would no doubt bring about some compatibility issues (that could be worked on over time with updates though I guess)

While including the old DSi processors would allow instant 100% compatibility at a cost (that would decrease over time), would provide extra computational power (that would particularly be useful for the new system-wide "bark mode") and provide instant 100% GBA compatibility as well (Should Nintendo choose to re-release GBA games on a Virtual Handheld service)

Either way, upscaling/upresing the screen will be an issue as the bottom screen an odd resolution to increase the DS size to (and having boarders is not an option as it would make touch screen games mostly unplayable)

 

[Grampa Simpson]

Or, since this deal is like winning a jackpot to the owners of this chip... perhaps they can ask them to add all specific instructions and calls into this gpu.

Who owns the IP to the DS's GPU? There's the question. If it's Nintendo, it's just a matter of integrating it and it can just be part of the silicon. There's no doubt that this is a custom version of the PICA GPU anyway.

 

[lostinblue]

I'm sure that Nintendo would be capable of writing a better DS HLE emulator than those on the PC. Hell isn't the Wii version of FFCC Echoes of Time just the DS version running in an emulator?

It was actually ported over, they detailed it somewhere; they built a automated code converter thing and said they could do it with a lot of games, but it's not emulation per see.

Oh and Nintendo do tend to enhance their old games on new hardware (Look at the VC and how much better the games look, especially N64 games). Given what we can gather about the 3DS' performance, I'd say that it should be capable of emulating the DS with few problems.

That's the only instance we've seen improvements really, and only because rendering N64 games at 320x240 would be dumb.

That said they didn't make them look all that much better, 3D looks better sure, but 2D looks horrid, I mean, look at ocarina of time's logo screen.

They could have added scaling for those or even better textures, they could have included filtering in some SNES games and we could go on. It's fine and it usually does what it's supposed to (unlike say, X360's backward compatibility) but they don't really add anything. Still on the N64 topic too, adding a 16:9 mode to some of those games would be easy from a emulation standpoint (albeit keeping the game HUD centered, but they see no point since they're selling old games anyway, people don't exactly demand/expect them. But they could do it.

The interesting point is that Nintendo have never gone with a system-wide emulation system before (Choosing to write custom emulators for each VC game instead of a one-size-fits-all emulator like MS and Sony), that is the one thing that casts a bit of doubt in my mind since Nintendo have always had perfect BC compatibility with all of their consoles that have supported BC in one way or another (and per game emulation ALA VC is impossible).

I don't think that's the case, tbh. They don't write a custom coded emulator for each game, or build one for each game for that matter, it's more like their emulator gets tweaked upon need, and seeing their regular snes game emulator couldn't cope with starfox or donkey kong country extra chips, or super mario rpg, it took a little more time to come out and when it did it was "upgraded" to that spec, but since other released games already ran fine they didn't change them. Same wit Majora Mask taking a little more time to come out due to it's extra RAM/heavy cpu usage. (we know how it ran on the GC with OoT's emulator a few years back)

It's not intended that way, but yes, they opted to include a emulator in each release. (along with custom manuals per game and stuff)

While including the old DSi processors would allow instant 100% compatibility at a cost (that would decrease over time), would provide extra computational power (that would particularly be useful for the new system-wide "bark mode") and provide instant 100% GBA compatibility as well (Should Nintendo choose to re-release GBA games on a Virtual Handheld service)

If nintendo emulated DS well though, they'd essentially would have everything to emulate GBA as well, and pretty much 100% too.

Either way, upscaling/upresing the screen will be an issue as the bottom screen an odd resolution to increase the DS size to (and having boarders is not an option as it would make touch screen games mostly unplayable)

true.

Who owns the IP to the DS's GPU? There's the question. If it's Nintendo, it's just a matter of integrating it and it can just be part of the silicon. There's no doubt that this is a custom version of the PICA GPU anyway.

I'd wager it's Nintendo, they like to own rights to their stuff. They're pretty future proof thinking.

 

[Graphics Horse]

and having boarders is not an option ...

Yes it is, and I expect it to be an option chosen by the user.

 

[Sipowicz]

Is this your first time posting in this thread?

yeah sorry. i'll have a look through the rest of the thread for the answer

 

[zigg]

Hell isn't the Wii version of FFCC Echoes of Time just the DS version running in an emulator?

Pretty sure they recompiled the game against the Wii's own graphics libraries. It wouldn't have made much sense to emulate it when they were actively building it at the time; the full source code was there and being actively worked on...