Irrlicht Engine

On Windows 10 loadiing TTF files from Windows\Fonts requires special permissions, I´ve had a search but can't see how this is done with Irrlicht? I can copy the TTF files to another directory but that would be a bodge.

@masm32 Yes I agree, I think the stencil buffers can be optional if only needed for shadows, that method is really too slow for any real use IMO. Hardware meshes are supported previously, is that not running in DX11? Skinned h/W meshes... are partial updates to mesh buffers in GPU memory supported u...

I could do the shader work... both HLSL and GLSL.
Just need CuteAlien to say he wants to manage us

Thanks for the tip! I just saw that irrAllocator is to handle memory allocation "across all dll boundaries", so that would be what was needed! Good for future ref! Anyway, I added new functions to IVideoDriver and the rest, such as newMaterial(), deleteMaterial(), CopyStringtoMaterial()-wh...

Sorry, I got that backwards, I'm using Irrlicht as a standard dll, with a statically linked MFC application. My problem started when I added two variables to SMaterial, to hold the texture filename and bump filename, set during mesh loading. To reduce memory, I added to simple array pointers: c8* pT...

Hi, thanks for the reply. Everything linked perfectly in my MFC app until I added SMaterial.cpp to Irrlich, and moved some of the functions defined in SMaterial.h to it's new .cpp. Absolutely everything compiles correctly, but I get unresolved externals at link time of my MFC app. There isn´t a link...

Its been a long time since I had a problem I couldn't seem to fix, so thought I'd ask for help! I use Irrlicht as a normal DLL, driving it from a staticallt linked MFC application, however recently I added functions to SMaterial.h that use new and delete[]. The problem is that calls within Irrlicht ...

I think the next step should be to integrate bGFX, at least that way Irrlicht driver support could be offloaded to another team.

Good to know CuteAlien

Masm32: is irrlcht_extendexvdx11 good? And what about vGFX, did you try it?

I did, ran memcpy across multiple cores and the speed improvement was dramatic on large memory transfers. I read that modern cores have independent memory channels, so transfer rates boost well.

Of course, just an idea, as would be an easy boost to employ

In the copy in iarray, can't parallel_for be used if the array is larger than a few hundred elements, get those other core working?

Fine if your meshes are small.

Why create another triangle buffer at all, the indices could index directly into the smesh buffers, just add a word in the indices array to indicate sub buffer.

Also reallocate copies all the old and redundant data very inefficiently, whereas clear and set are much faster. Look at reallocate: //! Reallocates the array, make it bigger or smaller. /** \param new_size New size of array. */ 00063 void reallocate(u32 new_size) { T* old_data = data; data = alloca...

But the array becomes massive consuming more memory than needed, and for large meshes even exhausting all available memory.