Irrlicht Engine

The mysteries of compilers! :) I still can't see how dynamic_cast<CGUITTFont*>(CGUIFont*)p would work. If p has a ptr to the base class of a CGUITTFont, then the compiler must search all base class ptrs to find the derived class. The strange thing is that even when a base class (in this case CGUIFon...

Irrlicht has no structure for CPU or GPU parallel processing. To a large extent it can be used as and API, leaving users to handle multi-tasking, but without DX12 or Vulkan, there is no GPU multitasking, but how useful is that anyway considering most people have one GPU, and that's usually where the...

Looks like you've been making some interesting progress. The way I see it though, adding another driver may not be the best way when bGFX project has an Irrlicht version, and that includes DX12, and Vulkan is underway. EZ Vulkan would also make the process easier, if one was to be added, but Vulkan ...

This:- core::irrAllocator allocator; CGUITTFont *p = allocator.allocate(1); Doesn't return a good pointer, using it causes a bad memory exception. Maybe it won't work outside the Irrlicht environ, in MFC it sure don't work! I tried looking for use of it in Irrlicht code but couldn't find any use... ...

I´m struggling with C++ semantics, so don't laugh please!

Its not working like that, memory violation, do I need to construct the class?

Also as its an array allocation, maybe:-

core::irrAllocator allocator;
CGUITTFont *p[] = allocator.allocate(500);

Okay, so

core::irrAllocator allocator;
CGUITTFont *p = allocator.allocate(500);

allocates an array of 500 TT font classes: p[0-499]->

CGUITTFont *p = allocator.allocate(1);

one TT font class p->

I couldn't find a usage example so thought it was more exotic than that!

Not sure what you mean, you want to avoid some of the updates in the main trunk, but stay close to the trunk?

We should maybe also look at the bGFX Irrlicht branch, as that will support all the drivers that the bGFX project supports, which might soon include Vulkan.

So should the correct use be:-

core::irrAllocator allocator;
CGUITTFont *p = allocator.allocate(sizeof(CGUITTFont ));

or is it static?

CGUITTFont *p = core::irrAllocator::allocate(sizeof(CGUITTFont ));

On this line within my MFC app, with Irrlicht compiling and working fine:

CGUITTFont p* = core::irrAllocator<CGUITTFont >;

The error is "

class irr::core::irrAllocator<irr::gui::CGUITTFont>
! Vert simple allocator imple....

type name is not allowed

I just download the Open 3D Model viewer which uses the latest version of Assimp, and it crashed when trying to load a smallish FBX file animation. Went to the website, but there is no support email.
Has anyone recently testedf Assimp with FBX animations?

Okay, thanks for the link will compare the code. I read in your posts, and Nalin's, that the GUI environment grabs the fonts for the skin, so that may be a problem for me, because I drop the TTF's face and font between scene reloading, which if I don't, is leaving some 133 grabs after I destroy the ...

Looks the the Vulkan EZ wrapper would make the job a lot easier to do.

https://www.gamingonlinux.com/articles/ ... pper.12414

I downloaded from Nalin's thread "TrueType font Support by FreeType Library"

The CGUITTFont files are stampled November 2016

http://nalin.suckerfree.org/public/code ... _Nalin.zip

I downloaded the files for this from the website, but as there is no create function, I allocate the font and face classes, and call load and then attach for the face, which works perfectly for several create/destroy cycles, then crashes as the face gets corrupted. There is no ustring conversions in...

I have it working now, the latest version directly loads .ttf files, and I just had to use "/" instead of "\\" in the path to have it open Windows/Fonts directly. Nice job by Nalin!