[GEM-dev] Re: [GEM-cvs] Gem/src/Pixes pix_texture.cpp,1.29,1.30

[james tittle]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: screwup.png
Type: image/png
Size: 131555 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050428/03273b95/attachment.png>