I tested on Windows and it's clear that the models and hul are loaded successfully in rvgl, but the bmp fails with your error message. Incidentally, on Linux I can't load any of the car's files, neither with RVGL nor with v1.2 under Wine.
As far as rvgl on Windows is concerned, the problem is that we use SDL to load the bitmap, and it takes the file path in the standard
UTF-8 encoding. But re-volt uses an extended Ascii encoding that is specific to Windows (called the
Windows-1252). The language strings and the parameters.txt files are all supposed to be saved in this encoding. Likewise, the folder names in Windows should use the same encoding (which it does by default), so that there is no mismatch between the path in the parameters file and the actual path in Windows.
So when we pass the ToyàPig path from the parameters file (in Windows-1252 encoding) to SDL, it assumes it's a UTF-8 path and does some internal conversion to Windows specific encoding before opening the file - but the path is already in Windows specific encoding in the first place..
We can try to workaround this by re-saving the parameters.txt file in UTF-8 encoding, but now the prms and hull which we are loading directly will fail (because this is not the encoding used by Windows file names). And of course, the name of the car displayed will be wrong too, because re-volt itself only supports the 1252 character set...
The story in Linux is entirely different: here UTF-8 is universally used (by default), even to encode the file names on the system. This is very clean and straightforward, and considering that SDL also expects UTF-8, we should update RVGL too to use the same standard. It means:
- Language and Parameters text files can be provided with UTF-8 encoding: this will open up the possibility to support numerous new languages, both for file / folder names and in-game, that we can't support right now with extended ascii.
- Text files using the legacy 1252 encoding will be automatically converted to UTF-8 when loading.
- All file paths can then be used directly on Linux, and converted to appropriate encoding on Windows.
Back to our original problem, we can bring back the old behavior on Windows by converting just the car texture path to UTF-8 before sending it to SDL, or we can load the texture ourselves to memory and let SDL to the necessary processing (I don't like this because it would take double the texture's size in memory during loading time and also delay the loading time). But maybe an urgent fix is not required: we can just wait till we switch over entirely to UTF-8.
) but I'll get into more details in a separate thread (I'll split your post).
(lucky me i have another backup, so i hope i can fix my dropbox soonly)
Even the rookie cars are locked?
