Irrlicht Engine

It is not wrong. The define and irr code affect the fixed pipeline as well, where that limit is relevant.

Just downloaded. Thanks for sharing this, jimy!

what license are these under? (if unspecified that legally means all rights reserved - so I figure I should request clarification).

Yes you're, I thought it was implicit, I would not have shared a code if I did'nt want to keep it for my personnal usage
This code is free ! It's a pattern !
I added it in the page header's.

right, free doesn't really mean much but I'll read the new headers to see what license you've picked (I personally like the wtfpl, zlib, and MIT licenses)

I updated the shaders to work (i think) on all graphic cards. On some systems, it didn't work because GLSL version was not defined.
I added so the preprocessor
#version 120 // to tell the GLSL compiler to use version 1.20 of GLSL or hight (openGL version >= 2.1)

Hi, jimy-byerley! Thanks!

Have you tried the shaders on Intel hardware? It's the most stick for the syntax.

I never for the simple reason I haven't any intel chipset, just nvidia and radeon chipset.
I will try to find one.

Ok. I have that here. I'll try to check it out in the weekend and correct the shaders if there is any issues. Your stuff should be in the Irrlicht examples (I would completely replace the shader example with yours!!)

I could try it on my old laptop, it has an intel chipset.

I'll return with results.

Hi, Tested on Linux with a intel integrated card. (Had to rebuild Irrlicht as shared lib since you did not provided it and I use a static lib)
The PC I'm using is running on Linux Mint with a Mesa DRI Ironlake Desktop driver (open source version).
GL support is for 1.2 and GLSL is 1.2 from the Irrlicht screen report. So it's really barebone... But I don't see any error in rendering here, and no shader crash. Good work!

Good new and Thanks ! Usally the proprietary version of the driver is less hard to please than the open source version.
... Yes I installed Irrlicht libraries from the debian repositories because I had problem at compilation time, However the simple makefile can recompile examples.

I have a question regarding your bloom code. Whenever I try to increase the size of either rtt0Size & rtt1Size in your bloom-ex.cpp or bloom_size in your bloom.cpp above 256 (it becomes noticeable around 500), in order to prevent flickering, I start to get a cross-hair effect in the middle of the screen:



It appears that below a certain number, this effect is not present because there is enough blur to make everything blend. Do you have any idea on what might be causing this?

bloom.cpp is the good file, bloom-ex.cpp is just a dirty darft.

I have been fighting this bug a long time. the lines that cuts the screen depend on the graphical card you have (maybe it's due to the parallelization algorithms of the card).
for you, "cross-hair" lines may appear above a size of 256 because the graphical card have to divide the screen computation in 256-sized frames.
I found no solution yet.

Good New !
I finally fixed the bug introduced by the sample size for bloom !
This was in fact a parallel storage access issue. Just look at bloom.cpp near line 170, I was using the same texture for both input and output of shaders, the result was that multiple threads of the GPU wasn't able to communicate on zones frontieres: computation on thread borders was wrong.

Now I use 2 different textures, used each time one for input and one for output. No more aberations !
In replacement of bloom_texture (that was the 'temporary' texture) there is bloom_texture_h and bloom_texture_v (for horizontal and vertical blur computation).

@infect: Thank you for reminded me this bug