[GEM-dev] framebuffer and pix_data

cyrille henry cyrille.henry at la-kitchen.fr
Sun Jun 1 21:38:19 CEST 2008



cyrille henry a écrit :
> 
> Jack a écrit :
>> I try my last patch i sent and (i don't know why) it doesn't work, sorry.
>>
>> But the first works fine (with [pix_buffer]).
> it work also here. 
> that's why i try pix_snap again.
> 
>> With this patch, I put the message [dimen 128 128, format RGB32( under 
>> [loadbang] and nothing worked.
>> But if i only put [dimen 128 128( under loadbang then press [0.5( and 
>> the bang, [pix_data] output 255 0 255.
>> Then i send the message [format RGB32( (after the creation of gemwin) to 
>> [gemframebuffer] then bang, and [pix_data] also output 255 0 255.
>> But before creation of gemwin, nothing happen.
>> Here the two patchs.
> 
> ok. that is good to konw.
> here, both works.
> 
> anyway, i realised that none of the Gem object works with more than 8 bits/color.
> 
> so i have to understand and write some code in order to adapt some object for 32 bits.
> i'm unsuccessful for now, but i'll make more test as this could lead to a lot's of applications.
> 

well, look like it's hopeless:
http://www.opengl.org/sdk/docs/man/xhtml/glReadPixels.xml
glReadPixels does not work with 16 / 32 bits color.

++
c


> cyrille
> 
>>
>> Le 1 juin 08 à 17:13, cyrille henry a écrit :
>>
>>> hello,
>>>
>>> thanks for your answer,
>>> this patch did not work here : pix_data did not output any value.
>>>
>>> could you try this one and tell me what does output pix_info?
>>>
>>>
>>> anyway, i had an other try with pix_snap, and today it is working!
>> Cool !
>>
>>> (i don't really understand why it was not working yesterday).
>>>
>>> value are still in 8 bits as it's hardcoded in pix_snap.
>>> so, i'll try to see if i could make pix_snap to work also with 16 or 
>>> 32 bits buffer.
>> Have you try with [pix_buffer] ? I don't know if it works with 8, 16 or 
>> 32 bits.
>> ++
>>
>> Jack
>>
>>
>>> thanks
>>> cyrille
>>>
>>>
>>> Jack a écrit :
>>>> Oops !
>>>> Send my last mail too fast.
>>>> Here the patch (simple) i wanted to attach.
>>>> ++
>>>> Jack
>>>> Le 31 mai 08 à 23:12, cyrille henry a écrit :
>>>>> hello,
>>>>>
>>>>> i would like to access color data of a framebuffer. just like 
>>>>> pix_data, but working with a framebuffer.
>>>>> i'm specially interested with framebuffer because i need to have 
>>>>> more than 8 bit/color (i'd like to use RGB32 format).
>>>>>
>>>>> pix_write use successfully the frambuffer, but i can't make pix_snap 
>>>>> to work.
>>>>>
>>>>> is there a solution, and if not, what would be the best to do in 
>>>>> order to make this possible?
>>>>>
>>>>> thx
>>>>> cyrille
>>>>>
>>>>> _______________________________________________
>>>>> GEM-dev mailing list
>>>>> GEM-dev at iem.at
>>>>> http://lists.puredata.info/listinfo/gem-dev
>>>> ------------------------------------------------------------------------
>>>> _______________________________________________
>>>> GEM-dev mailing list
>>>> GEM-dev at iem.at
>>>> http://lists.puredata.info/listinfo/gem-dev
>>> #N canvas 192 148 489 651 10;
>>> #X msg 112 86 create \, 1;
>>> #X obj 112 131 gemwin;
>>> #X msg 128 108 lighting 1;
>>> #X obj 161 269 cnv 15 150 150 empty empty scene 20 12 0 14 -233017
>>> -66577 0;
>>> #X obj 82 196 gemhead 20;
>>> #X obj 82 220 gemframebuffer;
>>> #X obj 167 331 rotateXYZ;
>>> #X obj 167 376 teapot;
>>> #X obj 82 266 t a a b;
>>> #X obj 187 293 i;
>>> #X obj 220 292 + 1;
>>> #X obj 250 291 % 360;
>>> #X obj 82 243 translateXYZ 0 0 -4;
>>> #X obj 167 353 color 1 0 1;
>>> #X floatatom 226 313 5 0 0 0 - - -;
>>> #X obj 163 175 loadbang;
>>> #X msg 194 133 0 \, destroy;
>>> #X obj 67 515 pix_data;
>>> #X floatatom 97 495 5 0 0 0 - - -;
>>> #X floatatom 135 496 5 0 0 0 - - -;
>>> #X obj 89 538 unpack f f f;
>>> #X floatatom 89 591 5 0 0 0 - - -;
>>> #X floatatom 123 591 5 0 0 0 - - -;
>>> #X floatatom 158 591 5 0 0 0 - - -;
>>> #X obj 51 491 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
>>> -1;
>>> #X msg 97 472 0.5;
>>> #X text 131 471 <- send this message;
>>> #X obj 89 559 * 256;
>>> #X obj 127 560 * 256;
>>> #X obj 168 561 * 256;
>>> #X obj 82 424 pix_info ---;
>>> #X floatatom 111 447 5 0 0 0 - - -;
>>> #X msg 162 195 dimen 128 128 \, format RGB32;
>>> #X connect 0 0 1 0;
>>> #X connect 2 0 1 0;
>>> #X connect 4 0 5 0;
>>> #X connect 5 0 12 0;
>>> #X connect 6 0 13 0;
>>> #X connect 8 0 30 0;
>>> #X connect 8 1 6 0;
>>> #X connect 8 2 9 0;
>>> #X connect 9 0 10 0;
>>> #X connect 9 0 6 1;
>>> #X connect 9 0 6 2;
>>> #X connect 10 0 11 0;
>>> #X connect 11 0 9 1;
>>> #X connect 12 0 8 0;
>>> #X connect 13 0 7 0;
>>> #X connect 14 0 6 3;
>>> #X connect 15 0 32 0;
>>> #X connect 16 0 1 0;
>>> #X connect 17 1 20 0;
>>> #X connect 18 0 17 2;
>>> #X connect 19 0 17 3;
>>> #X connect 20 0 27 0;
>>> #X connect 20 1 28 0;
>>> #X connect 20 2 29 0;
>>> #X connect 24 0 17 0;
>>> #X connect 25 0 18 0;
>>> #X connect 25 0 19 0;
>>> #X connect 27 0 21 0;
>>> #X connect 28 0 22 0;
>>> #X connect 29 0 23 0;
>>> #X connect 30 0 17 1;
>>> #X connect 30 3 31 0;
>>> #X connect 32 0 5 0;
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
> 
> 




More information about the GEM-dev mailing list