This thread is meant to discuss the addition of relative path support to the engine, specifically regarding resource loading (and to keep the EASTL thread from getting off topic). The proposed change allows the grouping of resources more easily by map section or character, so that within, for example, “Map/World1/Level1/node.xml” resources can be identified as “./tree1.mdl”, “./tree1leaves.png” without having to write out the full path for every resource. It also makes some situations of getting resources from the code simpler (I want the clothes.png file from the same directory as this character specification file, for example). Present behavior would be preserved for the most part (technically it would change, as relative path directories
./ are just stripped from the requested paths, but that I hope is not a feature anyone is relying on or using) – requesting ‘Models/Box.mdl’ would still give exactly the same result, but now we could use ‘./normal.png’ from a material rather than having to specify a different directory (which I feel is a much better resource layout for an actual game where textures will largely not be re-used between characters and such, though not so much the samples where the resources are rather heavily re-used so dividing by the type of resource is makes more reasonable).
Existing resource loading will be changed (all of the GetResource type functions), requiring an additional parameter (a base path) or switching the String resourceName (i.e. path) parameters to a separate Path class so that the relative paths can be resolved. The extra parameter will be inserted before the bool argument as it should be grouped with the actual resource path requested rather than whether an event is sent on failure. It will have a default empty string parameter, so only the case of specifically requesting an event not be sent on failure will existing user code need to be changed (and possibly also custom resources will need to be modified).
In terms of a cost-benefit, we gain support for relative paths at the cost of a slight increase in complexity in searching for a resource, which is likely not a bottleneck in anyone’s programs, so this should be fine.
I submitted a Pull Request for this addition two and a half years ago that is still open, so with this thread we can hopefully update and merge that shortly (since then I have let it grow out of date with master, but since there seems to be some interest I’ll go ahead and bring it up to date over the next couple of
There are a few implementation details to discuss, you can see a couple mentioned in the PR comments. One major one that might not have been mentioned is how we should add the base path parameter. I went with just adding a second string, as you may have noticed, but I also favor the addition of an actual Path class in place of just using strings. This Path would either store both the relative and base path itself, or it would just store the final resolved path (not truly an absolute one since we’re still using it to search the resource directories) when constructed from a relative and base path strings. If it were implicitly constructable from a String, I believe it should not require any changes to the code to switch to such a class.
If we went with that, we might want to opt for including this in Urho’s 2.0 release, and we could also go and move a lot of path-related features into the class (see the resource loading code for some of what I mean).
That said, a separate path class seems rather unnecessary to me since strings work perfectly fine for it, and then you have to decide implementation details like do we store the path as a String with the full path or as a StringVector of every component.