You are not logged in.
GRRLIB_texImg *tex=NULL,*tex2=NULL; tex2=GRRLIB_CreateEmptyTexture(640,480); tex=GRRLIB_CreateEmptyTexture(640,480); GRRLIB_Screen2Texture(tex2); GRRLIB_BMFX_Blur(tex2, tex,2); GRRLIB_FreeTexture(tex2); GRRLIB_FlushTex(tex);
tell me what im doing wrong
cause it works occasionally!
Last edited by elisherer (2009-09-04 14:26:50)
Offline
The code looks OK, it's similar to lesson2: http://code.google.com/p/grrlib/source/ … rce/main.c
Could the problem be with GRRLIB_Screen2Texture??? Is there something on the screen before calling the function? Did you tried with a texture from an image (PNG or JPEG) instead of the screen?
Offline
I bet this is in a loop ... Is malloc() failing?
Offline
no i do this before the loop
but now that im thinking about it.
the frame buffer is the one that changes and i do see a black screen when it doesnt work
so it might not be fast enough!
Offline
The lookatpixel() and setpixel() functions are VERY VERY slow ...I think because textures are stored in GPU RAM ...but that is just a wild guess
But - if it was "too slow" then your frame rate will just drop - you will not get "nothing"
Offline
i guess it's the malloc after all
because im trying to allocate 640x480x4bytes twice!!
i'll try to play with it and keep you posted.
Offline
1.2MB og memory is a big buffer ...times 2 ...and if you add pal support you get an extra 92 scan lines for your money - making the memory overhead 1.4MB per buffer ...plus some 1.5 *MILLION* memory reads just to look at each pixel ...another 1.5MILLION memory writes to write out the new data ...it's all pretty heavy duty stuff ...I notice that the plot() and getpix() functions could be optimised to HALF the number of reads they require quite easily. Which would make a BIG difference to your problem.
PS. ...and those reads and writes are all to high-latency video ram, not super-fast program+variables ram
Last edited by BlueChip (2009-09-05 01:21:56)
Offline