#169941 - DiscoStew - Mon Aug 17, 2009 4:41 am
Rather than using the BGs for drawing tiled layers, I wanted to try using 3D under glOrtho and using quads. I got it working, but I've run into a graphic glitch. I don't see it on emulators, but on hardware, when a quad is lined up against an edge of the screen, that area on the edge will either not draw that part of the quad (a single column or row), or it draws another section of the quad along that edge. The glitch goes away if the quads sinks into the edge or away from it.
Anyone else get this?
_________________
DS - It's all about DiscoStew
#169942 - TwentySeven - Mon Aug 17, 2009 6:06 am
Yep.
Theres some quirks on the DS hardware when trying to map quads/glortho pixels 1:1 with the screen.
Specifically what Ive encountered is that the hardware triangle clipper lacks precision and you get some UV "swimming" as quads slide off the screen.
The fix was to clip my quads manually, don't ever draw quads in such a way as they'll get clipped by hardware.
#169944 - sverx - Mon Aug 17, 2009 10:00 am
I also had a similar problem once... I was trying to map a single quad having a 256x256 texture on it with glortho so that I could map 1 texel to 1 pixel on the whole 256x192 screen... well, I coulnd't make it perfectly so I gave up using glortho... so I finally ended up leaving it with 'approximate' 1:1 mapping.
Now I think it'll remain as it is... :|
#169947 - DiscoStew - Mon Aug 17, 2009 7:00 pm
I've never dealt with manual clipping, so I'm not sure how to work that, especially now that I know that it's a texturing problem (I disabled texturing, made each layer it's own color, and saw that the problems were not showing up anymore).
I did have an idea though, and that is to use windowing to just cover those areas up, but I only want to use that if I have no other alternative.
EDIT:
Just to make sure that the option is available, I implemented the windowing idea, along with taking care of the windowing glitch of setting WIN0_Y0 to a value between 0 and 6. It works, but in the process, I lost touchscreen input. This is the code I used...
| Code: |
void irqFixWindowY_HBlank()
{
if( REG_VCOUNT == 0 )
{
WIN0_Y0 = 1;
WIN_IN = 1;
}
}
void irqFixWindowY_VBlank()
{
WIN_IN = 0;
}
int main( void) {
irqInit();
irqSet( IRQ_HBLANK, irqFixWindowY_HBlank );
irqSet( IRQ_VBLANK, irqFixWindowY_VBlank );
irqEnable( IRQ_HBLANK | IRQ_VBLANK );
.
.
.
return 1;
} |
...but to state again, I lost touchscreen support for my application. Is there a better way of doing this, and not create extra problems?
_________________
DS - It's all about DiscoStew
#169951 - TwentySeven - Tue Aug 18, 2009 4:43 am
Well clipping is pretty easy.
First thing to do is make sure that glortho is set up so that you can supply your vertex positions directly with glvertex16 calls without having to scale anything.
Then, because you're using screen aligned quads, its just a matter of bounds checking each edge of the quad.
something akin to:
if (leftedge< 0)
{
delta = 0-leftedge;
leftedge+=delta;
leftedgeUvs+=UvsPerPixel * delta;
}
if (rightedge > 255)
{
delta = 255-rightedge;
rightedge-=delta;
rightedgeUvs-=UvsPerPixel * delta;
}
(omitting all the fixed point math conversions)
#169954 - DiscoStew - Tue Aug 18, 2009 5:43 am
I feel like such a fool. The problem isn't with quads that are visible, even a little by being clipped by the hardware. It's the quads that are meant to not be visible, but are right on the edge of the clipping area, just outside of it. They are "leaking" in.
Ex: a quad that is 16x16 pixels, which is drawn (in relation to the screen) at a vertical position of -16, but the bottom of the quad would be at a vertical position of 0, technically inside the clip matrix, even though the quad (from a visual standpoint involving pixels) does not extend that far out.
I meant to change my code at some point in the future, as it currently just draws all quads for tiles, inside or outside of the clipping matrix. Now I have a reason to incorporate a position check. Thx for nudging me in the right direction.
_________________
DS - It's all about DiscoStew
#169955 - sverx - Tue Aug 18, 2009 8:10 am
wasn't that
pre-1.3.1 btw? 8|