On Apr 27, 2005, at 5:24 AM, IOhannes m zmölnig wrote:
Update of /cvsroot/pd-gem/Gem/src/Pixes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7701
Modified Files: pix_texture.cpp Log Message: set "state->texture" to "2", when using rectangle textures don't overwrite "m_repeat" with "GL_CLAMP" when doing rectangle-textures, as they will ignore that flag anyhow
...hmm: just tried this, and it screws up osx texturing (makes a whole bunch of kinda sub-images: maybe not such a bad effect?)...and now looking at it, I'm not sure how these state->texture flags are supposed to work? In any event, it also underscores how complex this file has become :-\
jamie
james tittle wrote:
On Apr 27, 2005, at 5:24 AM, IOhannes m zmölnig wrote:
Update of /cvsroot/pd-gem/Gem/src/Pixes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7701
Modified Files: pix_texture.cpp Log Message: set "state->texture" to "2", when using rectangle textures don't overwrite "m_repeat" with "GL_CLAMP" when doing rectangle-textures, as they will ignore that flag anyhow
...hmm: just tried this, and it screws up osx texturing (makes a whole bunch of kinda sub-images: maybe not such a bad effect?)...and now
well, that is how Gem used to be until the rectangle-textures dropped in ;-) seriously, could you describe the effect a bit more detailed ? (how do the "kinda sub-images" look like ??) does it happen all the time or just with [pix_coordinate] ?
looking at it, I'm not sure how these state->texture flags are supposed
actually it was just a boolean flag that indicates for downstream objects whether there is a texture present or not. my recent changes are just to make the bistate into a tristate to differentiate between normalized textures and rectangle textures (which behave different when it comes to texture-coordinates)
to work? In any event, it also underscores how complex this file has become :-\
yes, it was ugly. probably we really should kick out at least all the code that is for openGL<1.1; i cannot imagine any platform that is still in that era. (it might make porting to z80 harder though).
and the window handling would need a re-write too (i mean all those constant context vs. used context thing is just there to make it work with those voodoo2-cards 3dfx used to build in the mid-90ies; would it be arrogant to tell those people that their cards will not be supported by future versions of Gem ??)
mfg.ad.sr IOhannes
On Apr 28, 2005, at 3:18 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
On Apr 27, 2005, at 5:24 AM, IOhannes m zmölnig wrote:
Update of /cvsroot/pd-gem/Gem/src/Pixes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7701
Modified Files: pix_texture.cpp Log Message: set "state->texture" to "2", when using rectangle textures don't overwrite "m_repeat" with "GL_CLAMP" when doing rectangle-textures, as they will ignore that flag anyhow
...hmm: just tried this, and it screws up osx texturing (makes a whole bunch of kinda sub-images: maybe not such a bad effect?)...and now
well, that is how Gem used to be until the rectangle-textures dropped in ;-) seriously, could you describe the effect a bit more detailed ? (how do the "kinda sub-images" look like ??) does it happen all the time or just with [pix_coordinate] ?
...this is happening without [pix_coordinate]...and I just tried a coupla other older movies, and some of them have similar problems, but some don't! Weird...after a cursory survey, it seems that this effect is occuring with "x by y" movies, but not "x by x"...so it could be a driver problem, or a certain compression, or...? More investigation to come...
yes, it was ugly. probably we really should kick out at least all the code that is for openGL<1.1; i cannot imagine any platform that is still in that era. (it might make porting to z80 harder though).
...if anyone really decides to port this to a z80, they deserve for it to be more difficult! ;-)
and the window handling would need a re-write too (i mean all those constant context vs. used context thing is just there to make it work with those voodoo2-cards 3dfx used to build in the mid-90ies; would it be arrogant to tell those people that their cards will not be supported by future versions of Gem ??)
...this does need a big cleanup, which'll probably come when the multiple_window implementation becomes complete...which is, something else to pick up on: lessee, we were talking about timing issues, as I recall...I'll save that for a later email :-)
jamie
james tittle wrote:
On Apr 28, 2005, at 3:18 AM, IOhannes m zmoelnig wrote:
...hmm: just tried this, and it screws up osx texturing (makes a whole bunch of kinda sub-images: maybe not such a bad effect?)...and now
well, that is how Gem used to be until the rectangle-textures dropped in ;-) seriously, could you describe the effect a bit more detailed ? (how do the "kinda sub-images" look like ??) does it happen all the time or just with [pix_coordinate] ?
...this is happening without [pix_coordinate]...and I just tried a coupla other older movies, and some of them have similar problems, but some don't! Weird...after a cursory survey, it seems that this effect is occuring with "x by y" movies, but not "x by x"...so it could be a driver problem, or a certain compression, or...? More investigation to come...
well, your image definitely proofes that something is going wrong. since on osX rectangle-textures are used almost exclusively, we might set the m_repeat to GL_CLAMP on __APPLE__ until the driver-problem is fixed (if indeed it is one)
mfg.as.dr IOhannes