thanks Iohannes for the quick fix.
c

Le 01/06/2011 18:06, SourceForge.net a écrit :
Bugs item #3309231, was opened at 2011-05-30 11:07
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: RGB32 frambuffer can't be initialised with a loadbang

Initial Comment:
When sending "format RGB32" to gemframebuffer, a valid context have to be 
present. Otherwise, default RGB format is used.

This was not the case prior to revision 3807.

here is the relevant part of the diff (gemframbuffer.cpp)

398c398,400
<      tmp_format =  GL_RGB_FLOAT32_ATI;
---
     if(GLEW_ATI_texture_float) {
       tmp_format =  GL_RGB_FLOAT32_ATI;
     }


Since a loadbang is usually used to set the framebuffer format, this behaviors 
break all my patch that need 32bit framebuffer (including the GPGPU example)

test patch in attachment.

----------------------------------------------------------------------

Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-06-01 18:06

Message:
thanks.

this should be fixed with rev.3957

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_id=64325

_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev


_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev

Reply via email to