Yes, I have seen that.

Ah, right, files are UTF8 on modern systems, so things tend to be more complicated. Sigh.

Well, good point. I think I get the file name from a function which traverses a directory and calls a callback function for each file name that matches a simple pattern, like "*.lua". Inside I have a ALLEGRO_FS_ENTRY from which I get the path name...

After all, it might be necessary to change more code than I anticipated. There's a lot of small things that pile up.

If only. In that case things would be easier.
As I recall, it's UTF8 on OS X (or at least the interface lets you pretend its all UTF8), but it's UTF16 (?) on Windows, and whatever you want on Linux.

Yes.
I've kept notes of my porting effort for my game, which I'll clean up and post here at some point (sooner rather than later, I hope).

No reason we couldn't add those in 5.1, right?

Great job you guys! Even the readme_msvc.txt build procedure is manageable. I would just add:

• When converting an MSVC 9 project to MSVC 10 (to work around the CMake naming bug) several compiler errors will result related to int64_t. To fix this, uncomment the line: #define ALLEGRO_HAVE_STDINT_H in alplatf.h.

• Another option is to alter the CMake file so the Allegro DLL's don't have dots in their names. In the common.cmake file change: `SUFFIX -${ALLEGRO_SOVERSION}.dll` -> `SUFFIX -${ALLEGRO_DLL_SHORTVER}.dll`. Now CMAKE will generate valid MSVC 10 project files. Note this is not a good option if you want your Allegro programs to dynamically link to the Allegro library files built and shared by everyone else.

• Running the examples. There are two other options:

  1. Build the INSTALL project. This copies the library files into MSVC's search path (%VCINSTALLDIR%\bin). Then you can select a startup project and run it with F5 (from within MSVC).

  2. Copy the Allegro DLL files to a new directory (like C:\ALLEGRO_BIN). Then append that directory to your system %PATH%. Now you can run Allegro 5 programs from any path on your system (including from within MSVC)

I made a cursory survey of all the example programs, and I found some things that might need fixing:

• ex_utf8, ex_ttf, ex_font and ex_config fail to compile with warning C4819 if the default locale is not set to English (mine was set to CP949, Korean). The work-around is to set the system locale to English.

• The Windows taskbar is rendered over ex_dualies. This problem is common to most of the dual monitor/fullscreen window examples. In addition, ex_dualies has some intermittent problems:

  • Occasionally causes explorer to crash on startup.

  • Sometimes the Mysha display only shows a solid green color.

  • Sometimes the Windows taskbar is not restored to its original size+location.

• ex_fs_resize does not work very well with a dual monitor setup. It fails to change the resolution; it just sits in a semi-opened state (the log window is open, but the other window is just a sliver in the taskbar.) ex_fs_resize works if the monitors are duplicated, showing the exact same thing at the same resolution.

• ex_threads sometimes results in one of two types of errors:

  1. When starting: fatal error (Callstack attached.)

  2. When closing: First-chance exception at 0x7741f49f in ex_threads.exe. (Callstack attached.)

• ex_winfull taskbar also has some issues with the Windows taskbar being rendered over the Allegro display. On a dual monitor setup, I actually see two windows: the regular one on one monitor, and fullscreen window on the other. Clicking on the regular window causes the taskbar to occlude the fullscreen one. Works fine if the monitors are set to duplicate eachother instead of extend the desktop.

• speed also has a problem with the Windows taskbar covering the Allegro window when switching to fullscreen mode with "F". The work-around is to click the taskbar, then click the Allegro window. I do not see the "regular sized" window with this one (like ex_winfull)

• Building the run_tests projects results in several failures. These tests all passed in a previous SVN version of Allegro. List of failed tests attached.

Environment:

• Ran all examples from within MSVC; RelWithDebugInfo

• Allegro 5.0.0rc1

• MSVC Express 2010

• Windows 7 32-bit

• Lenovo X301 laptop

• FS-HS240LEDT external monitor

Thanks for testing!

• Does this mean MSVC 10 has stdint.h?

  
  

• ex_utf8, ex_ttf, ex_font and ex_config: unfortunately I can't find a decent solution to this. I don't really want to externalise the strings or use hex codes as some of these are meant to be readable examples. Apparently MSVC will treat these files are UTF-8 encoded if they have the stupid byte order mark (BOM) at the start; can you test if that works? I can't believe there is no command line option to force the input encoding.

  
  

• I believe the failing test cases are related to r13800. I did not have time to investigate whether the library or the test suite is at fault.

Yes, and Allegro supports it correctly. The problem is CMake does not build proper MSVC 10 files, and the MSVC 9 ones are not compatible.

Yes, it compiles... but it doesn't quite fix it. The BOM introduces compilation warnings in the English locale, then! There are still (different) warnings for the Korean local, too. The Unicode literal outputs of both programs are not properly printed; the UTF tests fail and/or hang.

Sample warning when compiling BOM file in Korean locale (CP949):
warning C4566: character represented by universal-character-name '\u25A2' cannot be represented in the current code page (949)

Sample warning when compiling BOM file in English locale (CP1252):
warning C4566: character represented by universal-character-name '\u25A0' cannot be represented in the current code page (1252)

I tried several other encodings, too: Unicode, Unicode Big-Endian, UFT-7. The only combination that worked was UFT-8 without signature compiled in English Locale.

And of course build for Windows:
allegro-5.0.0-rc1-mingw-3.4.5.7z
allegro-5.0.0-rc1-mingw-4.2.1-sjlj.7z
allegro-5.0.0-rc1-mingw-4.4.0.7z
allegro-5.0.0-rc1-mingw-4.5.0.7z
allegro-5.0.0-rc1-msvc-10.0.7z
allegro-5.0.0-rc1-msvc-8.0.7z
allegro-5.0.0-rc1-msvc-9.0.7z

I forgot to mention I tried L"", too. MSVC complains about incompatible types. I also tried the "_T()" macro without any luck.

I suppose it might work if we modify Allegro a little. Is that what you mean by runtime conversion? I was reading the L"" macro messes up non-MSVC compilers, though...

L"" convert to UCS-2, not UTF-16.

Yes, I have seen the stuff in a4_aux* already. I think I'll do similar things for config files, I just have to add support for override_config_file to what you have already done there.

Path and file system handling is an issue. For example, I have a function in place that takes care of auto saves. So all auto saves are collected from the file system, then the oldest are deleted, such that only a given maximum number of such auto saves exists. This requires matching file names, using a pattern like "auto*.vacs", then sorting the entries by modification date. Sure, this is possible with the new interfaces, except for the pattern matching... how would I do that? Which library to use here, that doesn't come a with massive overkill?

For the game loop and display stuff, I think I'll just re-write those parts. Will hopefully result in less and cleaner code. And yes, there's an occasional access to key[] and mouse_b...

Yes, that was just like my experience with the skater demo. I have to praise whoever wrote that demo for doing input handling the way it was done. Also for not using the A4 GUI, in which case I'd not have attempted the port.

The patch seems to do the trick. No MSVC compiler warnings in US or Korean locales, and the UTF output looks good in both the resulting executables.

Thats something I really want, so I might help with it. Well see if I have the knowledge and skills

The only way that's happening is if someone who wants it, writes the code. I don't have anything against that feature, I just don't want or need it I do believe that the loaders will load 8 bit bitmaps, but up convert on load (not entirely sure).