torpor said:
Nation.A.List said:
darkblu said:
it is.Pickle said:
intel don't use imgtec drivers. AAMOF, intel hardly use any GL drivers under linux:
darkblu said:
the closed-source issue (which is a result of licensing imgtec's IP) and the level of support are orthogonal matters (TI's sgx ES driver is just as closed source, but it works). intel used some of imgtec's code, but gma500's GL linux stack was largely 'in-house', i.e. tungsten's making. i guess the latter were underpaid, or were otherwise generally uninterested in the job, as it's a largely unusable stack (in contrast to the windows d3d stack). but that (releasing half-cooked linux drivers for their gpu hw) is not something new for intel, despite their current position at the helm of the DRM community. anyway, i would not look in intel's general direction for any help on that matter.Pickle said:
lulzfish said:
#ifdef GLES
glVertexPointer(3, GL_FIXED, 0, gl_es_vertex_data);
glDrawArrays(...);
#else
const float model_matrix_int_to_fixed[16] = { // make this global
1/65536.0f, 0, 0, 0,
0, 1/65536.0f, 0, 0,
0, 0, 1/65536.0f, 0,
0, 0, 0, 1,
};
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glMultMatrixf( model_matrix_int_to_fixed )
glVertexPointer(3, GL_INT, 0, gl_es_vertex_data);
glDrawArrays(...);
glPopMatrix();
#endiftypedef int GLfixed;
void glLoadMatrixx( const GLfixed *m)
{
static const float matmul[16] = {
0x1.0p-16, 0x1.0p-16, 0x1.0p-16, 1,
0x1.0p-16, 0x1.0p-16, 0x1.0p-16, 1,
0x1.0p-16, 0x1.0p-16, 0x1.0p-16, 1,
0x1.0p-16, 0x1.0p-16, 0x1.0p-16, 1,
};
GLfloat mf[16];
for(int i=0; i < 16; i++)
mf[i] = m[i] * matmul[i];
glLoadMatrixf(mf);
}
more like 'i'll just have to upgrade my GL drivers.'lulzfish said:
there's no such thing. the specs specify minimal precision and range properties for the different precision formats available in the language, but that's all (anything more than that is just recommendations). they could be internally all represented as 128-bit fx numbers and you'd neither know, nor should really care.
they won't.
fp is not automatically slow on pandora, it depens what you do with it. if you just want to compose a bunch of matrices and pass them down to ES for the heavy lifting - i don't see why not use fp. but if you're really doing a heavy job on some vertex attributes, then sure - stick with fx. GL 4.1 gives you the oppotunity to reuse your desktop code there.
why not reuse an existing implementation? it's not like this stuff was invented yeasterday.
some video on youtube was wrong (or was wrongly interpreted) - you need your matrix math code because there is no such functionality in the ES2 API (the math, not the formats), but why should that be an issue? if you really want the API to cater such basic functionality to you, then stick with ES 1.x (it will also spare you the need to write shaders ; )
i don't understand your gloomy position. ES is a beautiful API, ES2 in particular, very clean and very to the point.
