Gles Driver Bug

[crow_riot]

today i got my pandora (yeh!) and i immediately started to continue working on audiorace...

while doing so, i noticed, that the longer the track goes, the uglier the track gets texture mapped. i've done some testings, and i came to the conclusion, that this somehow must be a bug in the current gles driver (i've got hotfix 5 installed iirc).

to be more detailed, i'm increasing the v-coordinate with increasing time/length of the track to get my track continuously textured. my v-coordinate on one track with about ~5 minutes goes up to 1030. this approach works on my windows machine and even on the wiz, and there's nothing i can think about what i could change to fix this on my side.

here are 2 screens directly created on the pandora with glReadPixels:

this one is just at the beginning, v-coordinate is very low

this one is just at the beginning, v-coordinate is higher (just guessing - something around 200)

how do i check if i've got the newest driver installed? should i file a bugreport? will the be an update if this is regarded as a bug?

 

[Stuckie]

Interestingly, I've seen that also happen on Android when doing exactly the same kind of thing - the textures start to become utterly warped and pixelated.
I had thought it was just another GLES quirk, but if you're saying it works fine on the Wiz, then perhaps not.
Not the answer you were looking for, but it's not confined to Pandora at any rate!

 

[paeryn]

I noticed that happening too on Briquolo where the water texture just scrolls down indefinately. It starts of fairly mild and gets progressively worse.
Have you tried wrapping the v coord yourself if you can? That was the only thing I could think to do (but never traced where in the code it gets altered).

 

[Geca]

Congratulations! In one week i finally can put my hands on mine

It's easy to do the port from your GPH game to pandora ?

 

[skeezix]

Try an older firmware (we had other gles drivers) and see there?

Jeffphone

 

[Pickle]

Try an older firmware (we had other gles drivers) and see there?

Jeffphone

I wouldnt this issue has been around awhile, I thought it improved with the latest though. prboom was the worst i think that had it

 

[mcobit]

I tried you initial build on my pandora and with HF4 it was the same. I thought it was because of the higher resolution, but didn't think it was a bug...

 

[crow_riot]

thanks for your replies. at least it's not an issue only i encounter. will there ever be a fix on this? at the moment i doubt it

paeryn, i can't wrap the texture by myself. there will always be the case, where texcoords go from a higher to a lower value (0.9 to 0.1) where almost the whole texture will get drawn on one poly and inverted, too. there's only one way i can fix this now, restarting v coordinate after some 'magic value'. this will at least only give one ugly texture mapped poly from time to time and not the whole track garbled.

geca, i started porting without having a pandora, so i couldn't test a thing. that's where most of the problems arouse from. with the actual hardware, it's pretty easy, especially with the built-in capabilities of the pandora - wifi, dropbear are JUST there!

it's "good" to know, that it's also on earlier firmware versions, saves me some time with reflashing.

 

[crow_riot]

i've just found that someone posted a related problem in one of the TI forums: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/34897.aspx
bummer

 

[mcobit]

Did you try to use higher res textures to minimize the scaling the sgx has to do?

 

[notaz]

There is a newer driver than the one in HF5 released by TI about a month ago, I'll try building that.

 

[mcobit]

Great news! Maybe it will get in the new release or as an additional updateoption.

 

[crow_riot]

thanks notaz. i'm looking forward to try it out. PM me or so if you have something to test.

 

[notaz]

There is a newer driver than the one in HF5 released by TI about a month ago, I'll try building that.

No luck here, the driver builds but every GLES app hangs somewhere in driver code. They were probably too busy adding support for things like ti81xx and omap4 and broke omap3

 

[crow_riot]

well no good news, but thanks anyway for your time!

 

[notaz]

ED and I got it to run but it's still very unstable, hangs after random amount of time, and then needs a reboot.

 

[fusion_power]

i've just found that someone posted a related problem in one of the TI forums: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/34897.aspx
bummer

I hope the TI Driver Developers also read this, can't be that they release Drivers with htat bad errors in it. I can't imagine NVidia would do this with their Drivers onto the PC without breaking loose an apocalyptic storm of raged Users. h34r:
I really hope, TI didn't gave up Driver-Development for OMAP3 because at the Moment it seems they never finished this jop propperly.

Is someone here around that can make a better Driver? ^^""

 

[darkblu]

thanks for your replies. at least it's not an issue only i encounter. will there ever be a fix on this? at the moment i doubt it

paeryn, i can't wrap the texture by myself. there will always be the case, where texcoords go from a higher to a lower value (0.9 to 0.1) where almost the whole texture will get drawn on one poly and inverted, too. there's only one way i can fix this now, restarting v coordinate after some 'magic value'. this will at least only give one ugly texture mapped poly from time to time and not the whole track garbled.

What precision types do you use for your texcoords (in case you are under ES2)?

A standard practice in cases like the one you're experiencing issues with is, once you've figured out the 'magic value' past which the mapping degrades, to introduce discontinuities in your tack - pick an edge to a slab where you want the 'resetting' of the texcoord to occur and split the mesh there into overlapping, but topologically disjoint vertices; make one set of those use the old value 'before reset', and the other set - the new one 'after reset'.

 

[silver]

Not sure if you've seen, the TI forum post was replied to, pointing to limitations of the scaling hardware. The Original poster updated:

I've been looking to see what makes the errors significant, and the source seems to be precision in the texture coordinates. Smaller coordinates in the same texture (closer to 0) and smaller textures (128x128) seem to help in the test application. Usually you want large textures rather than many small textures, but smaller textures may be the only option

 

[crow_riot]

What precision types do you use for your texcoords (in case you are under ES2)?

A standard practice in cases like the one you're experiencing issues with is, once you've figured out the 'magic value' past which the mapping degrades, to introduce discontinuities in your tack - pick an edge to a slab where you want the 'resetting' of the texcoord to occur and split the mesh there into overlapping, but topologically disjoint vertices; make one set of those use the old value 'before reset', and the other set - the new one 'after reset'.

i'm under ES1, so the precision types do not apply, right?

i've already fixed the track meshs uv's the way u suggest. i was just bugged by my own code to make it work immediately, but then it turned out to work. i didnt search for a magic value but just picked to reset texcoords after a v value of 10 and now it looks fine.