ObjReader Community

Discussion => Post Your Questions & Comments Here => Topic started by: James Fuller on May 26, 2016, 01:20:55 pm

Title: File IO
Post by: James Fuller on May 26, 2016, 01:20:55 pm

Mike & Patrice,
  A few questions for the experts.

  What methods do you use to for your binary file IO, CRT or WinApi and why.

  How do you handle text file IO.
    A. Do you always use ascii?
    B. Do you always use UNICODE?
    C. A mix of the above.

  Are most of the apps you write UNICODE or ascii?

  Thank you,
    James

Title: Re: File IO
Post by: Patrice Terrier on May 26, 2016, 02:12:04 pm

James

In the case of ObjReader, the .MTL, the .OBJ, and the WinLIFT .SKS are always plain ASCII files.

However the C++ source code itself for ObjReader, GDImage, and WinLIFT is full UNICODE.

For example all GDIPLUS code is always using UNICODE while the deprecated GDI32 is still ANSI.

All file IO are based on the core API fscanf to read formatted data from stream.
And CreateFile to read from texture files.

However, remember that in C++ CreateFile is indeed CreateFileW when defined for UNICODE, and CreateFileA for ASCII.

And i am using MultiByteToWideChar to convert from ASCII to UNICODE (see the code below).

Code: [Select]

                hFile = CreateFile(zPath, GENERIC_READ, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
                memset(&zPath[0], 0, sizeof(WCHAR) * MAX_PATH);
                if (hFile != INVALID_HANDLE_VALUE) {
                    DWORD dwBytes = 0;
                    BYTE* buffer = new BYTE[nSize];
                    if (ReadFile(hFile, &buffer[0], nSize, &dwBytes, NULL)) {
                        MultiByteToWideChar(CP_ACP, 0, (LPCSTR) &buffer[0], nSize, zPath, MAX_PATH);
                        wcsncat_s(zMessage, zPath, _TRUNCATE);
                    }
                    delete [] buffer;
                    CloseHandle(hFile);
                }...

Title: Re: File IO
Post by: Michael Lobko-Lobanovsky on May 26, 2016, 09:40:08 pm

Hi James,

We have three parallel implementations of our Wavefront Obj viewers: in 64-bit C++ (called ObjReader64), 32-bit PowerBASIC (called ObjReader) that used to be taken historically as the C++ implementation prototype but is still maintained in working order, and 32-bit FBSL (called Objector).

Patrice has described file IO for ANSI (PB) and Unicode (C++) implementations. Please note that historically, .OBJ model files and .MTL material library files are expected to be written in ASCII as there's a lot of usable 3D software, both professional and indie, that wouldn't allow Unicode chars to be used in either those text files or texture/model/material file names. Hence the reduction of C++ Unicode capabilities to ANSI-only APIs in what concerns the model/material/texture file naming and input.

The FBSL implementation is built around the same concepts as Patrice's ObjReaders but uses a lot of different code solutions utilizing FBSL's built-in BASIC as well as its dynamic C and assembly jitters. FBSL is historically ANSI-only software though it does provide AnsiToWide() and WideToAnsi() built-in functions for handling the rare cases where Unicode would be a must as e.g. in constructing GDI+ string literals.