To give you a better visualization of why I think it is possible.
This is a simple way of loading in a text file.
########################################################################
#include "loadtextfile.h"
std::string LoadTextFromFile(std::string path)
{
std::ifstream sourceFile( path.c_str(), std::ios::in );
if( sourceFile.is_open() )
{
std::string content;
content.assign( ( std::istreambuf_iterator< char >( sourceFile ) ), std::istreambuf_iterator< char >() );
sourceFile.close();
return content;
}
else
{
return "error";
}
}
###############################################################################
It can be used to load any type of text file simply pass it the name.
Stuff like parsing and so on I do in other files.
I load binary files very similarly with a very generic file and then do the work in other files.
I assume Schema is as at least as capable of a programmer as myself and has learned this a long time ago.
It is literally a few lines of code at most for me to switch between loading files the way I suggest vs loading the way he is doing now.
As much as I might rag on people I don't do it generally because I think someone is stupid pretty much you can bet I am trying to get their attention to something they can fix and it will help them.
Windows has a limit to file path names. Don't know if you knew that or now. The length of that path is longer or shorted depending on what version you are on. Windows NT, 2000 it was something like 255 bytes but only 240 was usable.
Windows 10 only allows you to go 80 structures deep with this game.
Relying on windows directories is a bad programming practice to separate file hierarchy for that reason.
That or he could try and comply with the microsoft extend file names to get out to 32,767 or windows 10 unlimited if you comply.
Naming Files, Paths, and Namespaces (Windows)
There isn't a lot of work difference just the windows extend names won't give you added performance.
In truth if he wants max performance loading a compressed file and uncompressing it is faster than loading the larger file because more processor instructions can be done in the time a hard drive needs to seek and or read data and transfer it. There are plenty of articles on load time vs compression. So no need to take my word for it.