Irrlicht i18n (Unicode, FreeType, etc.)

[robmar]

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 ));

[CuteAlien]

Uhm, why are you asking ... just take a look at the header or simply try it out (it's not static).
Also the sizeof stuff you do there looks very wrong - it allocates an array of <type> - the number in allocate is about the number of elements, so don't use sizeof there (it will do a sizeof internally).

[robmar]

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!

[CuteAlien]

Yeah, just like that :-)

[robmar]

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);

[CuteAlien]

I have to admit I never used it directly (outside core classes). Look inside the core-classes on how to use this. I don't know where you get the memory violation exactly. The *p[] is wrong.

[robmar]

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...

In regards to Unicode, I tested Irrlicht with Arabic and there is no text support, it needs to process combined character codes which then change the glyphs displayed, sort of complicated.
I saw that in 1.8.4 there was SetRightToLeft(bool) for gui text, but... its not implemented!
In the process I checked 64-bit Irrlicht DX9 compared to 32-bit Irrlicht DX9, and boy the speed is 60% slower in 64-bit mode! Is the the nVidia 64-bit driver that bad? Curious!

[CuteAlien]

No, must like in my code: core::irrAllocator<CGUITTFont> allocator;
With the template argument. Not quite sure why it compiled in your case...

[robmar]

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 CGUIFont *p) has not derived class, it still returns a valid ptr to a derived class (which didn't even exist), containing the base, but the rest of the derived class isn't initialised, at least in the MS compiler.
Does it allocate a derived class and patch in the base? Is it safe to use that memory? I can't find any documentation on that anywhere.

[CuteAlien]

Note that Irrlicht itself isn't compiled with RTTI support - so dynamic_cast is not supported for objects created inside Irrlicht. Thought if you use it from your code (as you likely do here) it can work (as long as you have rtti enabled).
But not quite sure what you mean otherwise - maybe add some code-example to explain.

[robmar]

Would you just show me the correct syntax? I can't see now the allocator allocate a new CGUITTFont class at all, as the constructor wants a reference to an already existing CGUITTFont class.
So please, just show me!
core::irrAllocator<CGUITTFont> allocator;
CGUITTFont *p = allocator.construct(....????

[CuteAlien]

Right, you also need a constructor call in this situation. And irrAllocator only seems to support copy-constructors. And on top of that CGUITTFont has the constructor hidden in private (which is really just a hack to make it easier to use for usual case - in other situations I did give it a factory class instead). Ehm, not sure right now anymore if irrAllocator can be used for that case (but me trying to figure out c++ memory management around 3am in the morning is a bad idea anyway ... maybe I got some idea another time).

[CuteAlien]

Maybe find another way around. I'm actually not sure why you would run into the problem of allocation/release not happening in the same app/dll in your case. You can put CGUITTFont classes into your code - then it should be new/delete both in your app? Or If you have to move it in some other dll for some reason - add a function in there to drop() some object, that should also work.
I have to admit I never really understood why irrAllocator works anyway (or maybe I did understand once and forgot again over the years...). Which is also why I'm not sure if there is any way to change it which would make this easier.

[robmar]

The CGUITTFont allocation is working okay used in MFC, the problem initially was using new and delete on string pointers in the SMaterial class, which I'd added to pass up the filenames loaded for each sub-mesh. In MFC new created memory with block type 4, but Irrlicht used block type 1, or was it the other way, anyway, the block types were different because MFC allocates memory with block type 4 I think.
I got around that but adding procs to Irrlicht to handle memory allocation and delete for SMaterial.
Its a lot of work for much to do about nothing! ... but anyway, now its fixed :/ PS I don't think I'd recommend programming to any kids ever!

[CuteAlien]

For SMaterial 4 byte blocks should be used in Irrlicht (the places it uses 1 byte it includes irrpack.h).
And yeah, 99% of all coding work is not about doing your task but figuring out some strange thing which prevents you from doing that task :-)
Bad glad this works now. On to the next problem ...