This project is read-only.

Data directory with shaders and textures cannot be changed

Oct 26, 2011 at 7:39 PM
Edited Oct 26, 2011 at 7:41 PM


The Hieroglyph3 framework assume shaders and textures are located in the "..\Data\Shaders" and in the "..\Data\Textures" directories. This is IMO bad design work in many if not all application because it is in a directory at the same level as the executable file while it should be a level below.

Also, hardcoding paths like that is annoying. I would expect to have a configurable parameter set by calling RenderApplication::SetDataDirectoryPath(). This would be called from App::ConfigureEngineComponents.


-- Francois Piette

Oct 26, 2011 at 10:15 PM

Hello Francois,

That is a good point, and I don't see any reason not to make the path configurable.  I will add this into the next revision with the default directories specified as they are currently, but with the option to replace them in a similar way that you have shown.

Thanks for the suggestion, and it should be updated shortly.

- Jason

Oct 27, 2011 at 5:38 AM

Thanks for your good work.


Oct 30, 2011 at 8:57 PM

The most recent commit should contain the directory flexibility that you are looking for.  Take a look and let me know if it serves your needs!

- Jason

Oct 31, 2011 at 7:36 AM

Thanks Jason. I will look and try.

There are a number of warnings regenerating the solution. I had not noticed that before. The warnings are mostly related to LUA about unsafe operation with old C functions like strncat and similar.

Also, there is this warning:

3> GlyphString.cpp
3>c:\program files (x86)\microsoft visual studio 10.0\vc\include\xutility(2156): warning C4244: '=' : conversion de 'wchar_t' en 'char', perte possible de données
3> c:\program files (x86)\microsoft visual studio 10.0\vc\include\xutility(2177) : voir la référence à l'instanciation de la fonction modèle '_OutIt std::_Copy_impl<_InIt,_OutIt>(_InIt,_InIt,_OutIt,std::_Nonscalar_ptr_iterator_tag)' en cours de compilation

-- Francois Piette

Oct 31, 2011 at 8:38 AM

Hi Jason,

The directory flexibility works. I have two suggestions to make it work better:

1) In the FileSystem setters, when a folder is set, automatically check and add if missing a trailing path delimiter.

2) Instead of creating a new instance each time we need to access the FileSystem parameters (slow !), use an existing instance, probably in RenderApplication class. And provide a mechanism so that the user can use his own derived class. I'm not a C++ guru, but using Delphi (I'm a Delphi guru :-) I would use a metaclass for that purpose. If a metaclass is difficult, maybe a singleton patern would make it as well provided the user has a chance to change the single instance by a new one of a derived class.

-- Francois Piette

Oct 31, 2011 at 9:43 PM

Hi Francois,

That's a good idea about adding the path delimiter.  I'll have to brush up on my string comparisons, but it sounds like it should be fairly easy to get working.

Regarding point 2 - the way the class is implemented, it has only static data members.  That means if we create an instance on the stack that there is actually no work done, and no additional memory consumed.  This is the Monostate pattern, and essentially allows lots of instances to refer to the same data.  If we expected parallel writing to the class, then we could synchronize the writing routine, but that shouldn't happen...

The warnings on the glyph string functions will be further investigated.  I found some additional data on properly converting between std::string and std::wstring, so I should be able to correct the warnings (although I can't read your warnings - I only speak English and German ;)

The Lua warnings are probably going to be difficult to remove without modifying the actual Lua source code - which I most likely won't do.  I'll do some reading on the topic and find out if there is a way around the warnings that other developers have found.

Thanks again for the commentary and suggestions - keep them coming!

- Jason