Re: Higher resolution rendering
Posted: Tue Apr 14, 2015 11:14 pm
For huckleberrypie.
My reaction to it, mostly:Exophase wrote:For huckleberrypie.
Not that I am yet aware of. Technically the viewport controls can be used to flip the screen on the X or Y axis, which isn't being emulated. If I run across anything using it like that I'll have to change the way I emulate it.huckleberrypie wrote:Seriously though, are there any other games which make (sloppy) use of the viewport feature besides Kit's?
Is it a sort of render to texture feature, e.g. deferred rendering or the same stuff used for the 3DS?Exophase wrote:Not that I am yet aware of. Technically the viewport controls can be used to flip the screen on the X or Y axis, which isn't being emulated. If I run across anything using it like that I'll have to change the way I emulate it.huckleberrypie wrote:Seriously though, are there any other games which make (sloppy) use of the viewport feature besides Kit's?
No, it's nothing so involved. All games use the viewport, it just specifies the window on the screen that the 3D part gets rendered to. So the 3D scene is scaled and offset to fit that window. The viewport box is specified by providing the lower left and upper right coordinates of the box. Usually games use (0, 0), (255, 191) so it fills the screen. This game uses (0, 255), (255, 191) for that scene which is almost certainly a mistake, but somehow on a DS that's interpreted something like (0, 0), (255, 192). But if you give it (0, 254), (255, 191) instead (or an actual (0, 0), (255, 192)) it totally breaks. So for right now I'm just treating it like (0, 0), (255, 191), which is almost certainly what they meant to do but screwed it up and happened to get away with it somehow.huckleberrypie wrote:Is it a sort of render to texture feature, e.g. deferred rendering or the same stuff used for the 3DS?
You intercepted that instruction and made it so that it would load up like it would on a real DS?Exophase wrote:No, it's nothing so involved. All games use the viewport, it just specifies the window on the screen that the 3D part gets rendered to. So the 3D scene is scaled and offset to fit that window. The viewport box is specified by providing the lower left and upper right coordinates of the box. Usually games use (0, 0), (255, 191) so it fills the screen. This game uses (0, 255), (255, 191) for that scene which is almost certainly a mistake, but somehow on a DS that's interpreted something like (0, 0), (255, 192). But if you give it (0, 254), (255, 191) instead (or an actual (0, 0), (255, 192)) it totally breaks. So for right now I'm just treating it like (0, 0), (255, 191), which is almost certainly what they meant to do but screwed it up and happened to get away with it somehow.huckleberrypie wrote:Is it a sort of render to texture feature, e.g. deferred rendering or the same stuff used for the 3DS?
Sort of. It's may not be exactly right anyway, on a real DS the geometry might be one stretched one pixel longer. And I wouldn't say anything is intercepted, it's just in the code that handles the viewport command.huckleberrypie wrote:You intercepted that instruction and made it so that it would load up like it would on a real DS?
Well, it's a workaround for now anyway, unless if some dude complains about their game being horribly broken just due to this.Exophase wrote:Sort of. It's may not be exactly right anyway, on a real DS the geometry might be one stretched one pixel longer. And I wouldn't say anything is intercepted, it's just in the code that handles the viewport command.huckleberrypie wrote:You intercepted that instruction and made it so that it would load up like it would on a real DS?
It works pretty much like it does in OpenGL. https://www.khronos.org/opengles/sdk/do ... ewport.xmlhuckleberrypie wrote:Also, is the viewport rendered as a flat plane similar to how the PS2 behaves?