Irrlicht Engine

By load you mean passing parameters from CPU to GPU? Should work for float like for other types. I just did a quick test with d3d9.hlsl and example "10.Shaders" in Irrlicht. Added a float in the global variables section.

float dummy;

Used it later in the pixelMain to see something:

Output ...

z-buffer (or w-buffer) is usually no problem until it is. And then you see it. And 90% you can fix it by increasing near-plane a bit or so. Or slightly modifying your 3d scene architecture (don't have flat planes too close together). In some specific scenes it obviously matters, but it's not ...

Yeah, same named textures are cached in Irrlicht. Because usually you only want one. If you want the same texture several times you can for example load it once - then create an image copy for it (like you do above) - and then call addTexture with that image a few times and use a new name for each ...

I can't see the bug from the code posted here.

Please take a look at the example I linked above (I've updated it to still work with Irrlicht 1.8). And just use the SDrawableTexture wrapper in there. You can adapt it then as you want, but it's probably a better start than writing that stuff by hand ...

I just had another idea - maybe they are ordered correctly but because the gui objects have transparency it looks like they are in wrong order? If you have 2 transparent UI objects on top of each other it can be really hard to tell which one is on top. Try what happens if you set transparency very ...

Ah I was wrong - it makes sense. You need to regnerate the mipmap levels if your texture has those (by default all textures do).
So after texture->unlock() add: texture->regenerateMipMapLevels();
I've updated the example I linked above to contain a flying cube to show it.

Did you try putting any other texture on that object? Because I have the feeling it will also be clipped. This shouldn't be related to your drawing.
Sorry, not enough information that I can help yet. Do you have the code for this online maybe? I can take a quick look then.

I made a quick example for this: https://github.com/mzeilfelder/irr-play ... rawing.cpp

(also noticed if you do it that way you don't need the ETCF_ALLOW_MEMORY_COPY flag as you already have your own copy)

Oh no - if you do _that_ each pixel your cpu will shoot itself to get out of the pain! Don't create a new image every call, memory allocations are extremely slow. And you don't have to. Also would create a memory leak - one new image in memory every pixel, you couldn't draw long before our PC runs ...

You can acccess texture memory with ITexture::lock(). Writing to it then depends a bit on the format. Maybe copy the code from CImage::setPixel (in CImage.cpp) which basically does just that. At least if there is no memory padding in the texture. To avoid padding use textures with a width which is a ...

Yeah, I get the confusion, was the main reason I wrote the MaterialViewer example. But it's pretty simple - if you turn of light _none_ of those colors affects the material anymore. They _all_ only work with lighting. The only color which affects polygons without lighting are the vertex colors. And ...

OK, glad you found. I just took another look at the example and I also found a strange thing - the normal seems a bit off (1, 1, 0) - it's not normalized or going along the plane, should probably be (0,0,1) instead. I'll have to take a closer once I'm a little less tired tomorrow.

Hm, that's the second really strange problem you have in a row. Just wondering if you have tried updating the graphic card driver? Might be worth a shot.

Otherwise - did you start with example 27 for this? Check if the vertex coordinates and uvs are really all at -1, 0, 1

It's deliberate at least. Comes from OnAnimate in ISceneNode header which has an IsVisible check (and calls OnAnimate for children only if it succeeds). If you want to enforce the animation you can call OnAnimate for that child node manually (and it only checks it's own IsVisible flag then).

Haha yeah - that was also why chose Irrlicht over some another engines - I was getting it to work so fast :)