Baron Doggystyle von Woof
Member
We need more screens of the possible graphics! (Yes I have seen the tech demo of the chip)
shaft said:We need more screens of the possible graphics! (Yes I have seen the tech demo of the chip)
AceBandage said:
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).M3d10n said: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.
anatema!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.
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.blu said: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).
AceBandage said:Below GC, above DC, but with modern shaders.
blu said: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!
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 : )M3d10n said: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.
yes - for 2D rendering (orthographic projections - yay!) try to do the same with 3D now ; )pcostabel said: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 said: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;
perspective division?pcostabel said:Code:Out.position = mul(viewprojection, In.position); Out.position.x += jitter; Out.position.y += jitter;
blu said:perspective division?
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.pcostabel said:Ok, I see what you mean.
Code:Out.position = mul(viewprojection, In.position); Out.position.x += jitter*Out.position.w; Out.position.y += jitter*Out.position.w;
They should be possible, flash uses that and it runs on inferior platforms, so...EVH said:What about vectorized graphics, like LocoRoco? Does this include something about that?
blu said:no, i meant division. as in that thing that can blow up your rationals if you don't clip *before* it.
By the way, has everyone seen the trailer to this screen shot? I looks truly incredible for a hand held.shaft said:We need more screens of the possible graphics! (Yes I have seen the tech demo of the chip)
brain_stew 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.
Gahiggidy said:I looks truly incredible for a hand held.
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.pcostabel said: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?
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 said: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).
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).blu said: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.
Gahiggidy said:By the way, has everyone seen the trailer to this screen shot? I looks truly incredible for a hand held.
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:EVH said:What about vectorized graphics, like LocoRoco? Does this include something about that?
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
Graphics Horse said: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.
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.wsippel said: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:
JimboJones said: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.JimboJones said: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?
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.BMF said: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 said: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 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.Graphics Horse said: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.
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.lostinblue said:what do you mean by library substitution?
Sipowicz said:brain_stew do you know how good the graphics are yet or do you need more information?
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.BMF said: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.
Or maybe some games just won't work.lostinblue said: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.
Perhaps so.BMF said:Or maybe some games just don't work.
BMF said:There you go. DS graphics on the 3DS without hardware emulation.
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).Graphics Horse said: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.
lostinblue said: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.
oh.Graphics Horse said:Sorry I meant to say 2D PSone games, I know what the 3D ones look like
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.BMF said:Or they could just include a DS GPU and make the whole process easier.
lostinblue said: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".
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 said: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.
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.Nuclear Muffin said: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?
That's the only instance we've seen improvements really, and only because rendering N64 games at 320x240 would be dumb.Nuclear Muffin said: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.
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)Nuclear Muffin said: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).
If nintendo emulated DS well though, they'd essentially would have everything to emulate GBA as well, and pretty much 100% too.Nuclear Muffin said: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)
true.Nuclear Muffin said: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)
I'd wager it's Nintendo, they like to own rights to their stuff. They're pretty future proof thinking.BMF said: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.
Nuclear Muffin said:and having boarders is not an option ...
Jason's Ultimatum said:Is this your first time posting in this thread?
Nuclear Muffin said:Hell isn't the Wii version of FFCC Echoes of Time just the DS version running in an emulator?