This patch replace all 16bit calls and change them to 32bit.
U can download this patch at my homepage
http://www.sdi-syndrom.de/dev-delight/irrlicht32.patch
![Very Happy :D](./images/smilies/icon_biggrin.gif)
have fun
pls let it flow into the new version of irrlicht
Code: Select all
scene::IAnimatedMesh* mesh =
smgr->addHillPlaneMesh("terrain",
core::dimension2d<f32>(1.f, 1.f),
core::dimension2d<s32>(255, 255),
0, .25f,
core::dimension2d<f32>(5.f, 5.f));
ISceneNode* node = smgr->addMeshSceneNode(mesh->getMesh(0));
node->setMaterialFlag(video::EMF_WIREFRAME, true);
node->setMaterialFlag(video::EMF_LIGHTING, false);
xyzchyx, you are referring to the CPU, this is true for the CPU - actually in some cases 32-bit is faster than 16-bit codes. However, its a different case for graphics because as the previous post explains copying 16-bit data is only half the size of 32-bit data....xyzchyx wrote:Actually, the speed of manipulating 32-bit numbers is no slower than 16-bit unless the non-native integer size is actually narrower than 32-bits. In fact, on some systems, it may even be slower to use a non-native integer size. The only advantage using 16-bit integers gives one is compactness of storage in arrays. There is no practical benefit to using 16-bit integers on 32-bit computers for variables, either local or global, unless there are many of them to store and space is at a premium.
I'm confused.... first you say that the issue isn't necessarily space, but then you go on to even cite an example where the only reason that it's going to be slower is _BECAUSE_ of the amount of extra space that a large array of 32-bit integers would take up.vitek wrote:The issue is not _necessarily_ space. Of course 32-bit integers are twice the size of 16-bit integers, so for a mesh with less than 65536 vertices, you use two times the memory for representing the same mesh when you switch to 32-bit indices. This is an issue, but it is not the only issue. The other issue is that you are sending the index buffer to the graphics card every frame. This will be a significant bottleneck.
Lets say you have a mesh with 65535 vertices [just for arguments sake]. To maintain 100fps while rendering that mesh with 32-bit indices, you have to send 25MB of data through the CPU to the GPU every second. It is only 12.5MB for 16-bit indices. With the CPU busy sending vertices to the GPU, you don't get a lot of time for other stuff.