Horde3D

Currently Horde is case sensitive for resources. This is generally a good idea for an Engine that runs on Unix based systems, but it leads to some non-obvious results from user error. Since shaders, materials and textures are specified in the xml’s then it is relatively easy to spell them with different cases. Under windows this won’t cause an error, but will instead duplicate the resource.

So for instance if I write “parrallax.shader.xml” in one material and “Parrallax.shader.xml” in another, two shader resources are created and two shaders are uploaded. Doing this has a negative effect on load times and performance. Although it is caused by user error, it’s a non-obvious result and can easily go undetected. Similar problems can exist with texture resources, where texture data will be duplicated I believe.

Should Horde3D be case insensitive on case insensitive platforms?

As a general rule, cross-platform software should work exactly the same on all platforms (though this isn't always possible). Introducing Windows-specific behaviour that will break when ported to mac or Linux is a bad idea™.

_________________
Tristam MacDonald - [swiftcoding]

Yeah that's something I'm also not sure about. At first resource names were case-insensitive but to make everything consistent and add better support for the non-Windows platforms I made also the resource names (which are not necessarily file names, you make the mapping yourself) case sensitive. But I see the problem you describe. Maybe we could add an engine option that makes the resource manager convert all names to lower case, so you can choose on a per-project basis what you want.

I see your point, but the way it is at the moment, the engine is using Mac/Linux-specific behaviour that will break when ported to Windows. So we're damned either way!

Not really. The existing behaviour works fine on all platforms - unless you have multiple assets only differentiated by case, which would be plain stupid. The samples all find their assets on Windows or Linux, with equal ease.

The only thing that case-insensitivity will do is cover programmer errors (requesting the same file multiple times, in a different case each time). These are errors in C++ (in pretty much all other languages, and intentionally so), and I don't see much reason to make the engine more lenient than its host language in this respect.

There is also the issue of implementation - the engine is already case-insensitive with respect to files (as all Windows programs are automatically), but to make resources case-insensitive is a major hassle. It requires providing custom comparison functions to the std::containers in use (mainly std::map), and introduces significant overhead - this is the reason that case-insensitivity was scrapped during the design of python, as nobody wanted the performance hit.

Lastly, this isn't only an issue that affects Windows. Both Mac and Linux can (and often do) use case-insensitive disk formats, which means that we have to behave predictably on those as well.

_________________
Tristam MacDonald - [swiftcoding]

you know the platform at compile time. so platform compatibility and implementation are no problem. (you can use different functions for win and nix, so overhead will be little).

But it is unnecessary IMHO.(it would be fun though: figuring out that nix is case sensitive, after porting your windows app. and hours of debugging ... priceless )

Or you just convert all path-strings to lower-case as they are entered into the system.Which means it should be safe to force all file-names into lower-case ;P

I think a fair solution would be to do this (convert all paths to a standard case-ness) when compiling for any platform which is case-insensitive (i.e. Windows). This fixes blue's issue of loading the same resource twice and shouldn't impact any other platforms.

wouldnt md5 sum and size of the file be better than name of the file, for uniqueness test.

so you can load bleh.jpg and blah.jpg
but only bleh.jpg is loaded because blah.jpg has the same size and md5 sum

looking this way, it is resource management related
not just case sensitivity

Except that you are forcing the user into a certain naming convention. I happen to like naming my files in CamelCase, but on case-sensitive hard drives, I would be forced to use all_lower_case.

How do we define a platform that is case-insensetive? Macs are case insensitive if you format the hard drive with that option checked. Linux is case insensitive if you are using an NTFS or FAT32 partition (both of which can happen on Windows-like distros).

_________________
Tristam MacDonald - [swiftcoding]

That's an interesting way to look at it - using a md5/hash just makes the file-name problem disappear
However, md5 sums are not cheap - loading times would be much longer if you had to sum the files as you load them (unless you pre-calculate all the MD5's and save them alongside the files, in which case it would be hard to keep them up-to-date)

Yeah, same. Hence the ";P"

Darn... Lets say there's 3 categories: (A)=always case-insensitive, (B)=always case-sensitive, (C)=can be either.

Forcing lower-case paths on-input would make (A) error-free... but obviously breaks (B), and often breaks (C).

Allowing any-case paths is not a problem on (B)... but can cause the obscure resource-duplication bug on (A) and potentially on (C).

It doesn't look like there is a solution.
But as you said - "The existing behaviour works fine on all platforms - unless you have multiple assets only differentiated by case, which would be plain stupid." - so maybe we should just note this "bug" down as "undefined behaviour", and have the engine be able to issue you with a warning if you ever load two resource files that only differ by upper/lower case.

can be something cheaper, like crc32 but it is not as safe as md5.
but still pointless. one could just remove the duplicates at release