next »

[qMopey]

Why do you need a file system? I just use this: https://github.com/RandyGaul/tinyheaders/blob/master/tinyfiles.h

Not a file system thing, but has very useful abstraction for looping over files and folders. What more would anyone want?

[JWki]

I just use the Win32 stuff mostly for file system stuff but tell me how you like boost's version I'm interested in a cross platform solution too.

[qMopey]

I just use the Win32 stuff mostly for file system stuff but tell me how you like boost's version I'm interested in a cross platform solution too.

Seconded. I used to just win32 stuff, but then eventually wrote Posix things too for more cross-platform. So why would anyone want to use Boost or something similar?

[oahda]

I don't just need to traverse files, but also move and copy files, get the current directory and so on. I'd use cstdio and dirent if that was enough, but in this case, it seems not to be. :c

Of course I could write a simple wrapper for good old system() to do stuff on the command line in UNIX and Windows respectively, but I want a bit of comfort too. Thanks anyhow!

Anyway, got the Boost lib working, so will be trying that now. c: It's just a small standalone command line utility I'm writing up quickly, so the code doesn't need to be perfect, and it'll be small enough that I'll probably just quickly rewrite it with the C++17 lib when that's possible anyway.

[JWki]

Well yeah you can always write a wrapper for the OS API I guess but that's somewhat daunting to do for all 3 platforms.

[Sik]

What's annoying is that POSIX already handles this (and that's like effectively an alternate standard library). Yeah it's C, but it wouldn't take much effort to wrap it in C++. It's pretty much standard on anything *nix, it would be nice if Windows actually adopted it =/ (the basic directory functionality is actually there inherited from Windows NT, but it expects ASCII filenames from what I recall)

[oahda]

Well, C++17 is going to have you covered, so look forward to it. c:

Enjoying the boost lib so far. Only issue I found is that it doesn't have a build in function to make deep copies of folders, so I had to recurse manually, but all the necessary functionality to do so is there, and that's a function written once (or in this case, copied from someone online who had already done the work) and then used over and over, so not too bad. Do hope the STL version will provide it, tho, since it seems like a reasonably common use case to me.

[qMopey]

What's annoying is that POSIX already handles this (and that's like effectively an alternate standard library). Yeah it's C, but it wouldn't take much effort to wrap it in C++. It's pretty much standard on anything *nix, it would be nice if Windows actually adopted it =/ (the basic directory functionality is actually there inherited from Windows NT, but it expects ASCII filenames from what I recall)

Nothing is stopping anyone from writing a posix wrapper for the Windows APIs

[Sik]

Yeah, I'm just more annoyed at how the solution was already there for a long while but it's useless in many cases due to bad support in one huge major platform. Reminds me of how stdint.h had to be avoided like the plague (or provide your own) because Visual Studio didn't come with one until a few years ago.

To be fair though no idea how all this fares on mobile. They try to discourage you from writing portable code to the furthest extent they can get away with.

[qMopey]

Yeah I think that's mostly Apple to blame. Apple is the most proprietary company I have ever seen in terms of code and APIs. It's ridiculous. Not a big wonder why most games are still played on Windows.

[oahda]

huh, for me mac and linux dev has always been basically the same thanks to their common unix core, while windows and mvsc has been the weird one out d:

[qMopey]

On Apple applications are launched from Objective-C. Proprietary language    Lots of posix pieces are missing and still platform specific. For example just getting time on Apple machines almost uses a posix API, but diverges into that mach_time stuff. Also, Xcode? Code signing? Need I say more?

 

At least Linux and Windows both allow the programmer to stick strictly to C. For example in my own game the only differences between Linux/Windows so far is file handling and threading. Oh and some tiny netcode differences (WSA startup stuff). But with xcode there are tons of annoying things. Like where is the working directory on Apple machines? Oh it's in some random weird folder (at least when using xcode), so that will have to be changed to the executable's directory.

[oahda]

I really don't ever touch Objective-C since I'm writing cross-platform C++ using libraries that abstract any of it away anyway, so you really don't have to go there unless you actually want to do everything from scratch for some reason. c:

My taking a look at NSTask was quite exceptional, and in the end I used a C++ lib anyway. But any use of it doesn't really bother me since it's so seamless thanks to the Objective-C++ compiler that allows files with mixed code that can share everything that both languages inherited from C, like primitives and pointers. Trying out NSTask required no additional setup in my C++ project, and I just stuck it in the middle of a C++ function. ε:

(also modern C++ STL is bridging a lot of gaps that used to be there, like threading, which is nice (but even before that, third-party solutions of course existed))

But each to their own! It's all habit in the end.

[oahda]

Considering using something like Qt for my editor after all, solely on the basis of highly valuing good localisation and proper Unicode support and text rendering, no matter if it's left-to-right Mandarin with one constant glyph for each codepoint or right-to-left Arabic with lots of ligatures and contextual glyphs and diacritics. I'm not sure, but I can't imagine ImGui handles all these use cases very well.

But I will also need this solved for the OpenGL game itself eventually. So is there already a solution out there? I feel like there must be...

Maybe this? Found some info too, so I think I'll give it a try.

[ferreiradaselva]

Pango and Cairo are already used in Gtk(2/3) applications. They definitelly have the best implementations to render text out there (including for eastern languages), *however*, they are bulky libraries. Also, be aware that they are LGPL libraries, so if you want to allow closed-source derivatives of your project, you must link to them dynamically.

[JWki]

Considering using something like Qt for my editor after all, solely on the basis of highly valuing good localisation and proper Unicode support and text rendering, no matter if it's left-to-right Mandarin with one constant glyph for each codepoint or right-to-left Arabic with lots of ligatures and contextual glyphs and diacritics. I'm not sure, but I can't imagine ImGui handles all these use cases very well.

But I will also need this solved for the OpenGL game itself eventually. So is there already a solution out there? I feel like there must be...

Maybe this? Found some info too, so I think I'll give it a try.

I might be somewhat opinionated, probably also because I'm in a lucky spot where I never needed software to be localized for me simply because most software is in English, but is full localization support really that valuable for tools?
I can get behind text rendering being incredibly important, you want free scaling and crisp glyphs for tools to be usable, but unless you plan on releasing your tools as a part of your game I guess I wouldn't bother with localization too much?

For the game itself of course, being able to render all sorts of fonts is desirable but I don't know if there's any games that actually handle text rendering that well.

[ferreiradaselva]

I agree with that. For tools, english is enough. The user will need to understand english anyway to write the code. For games, that's another story.

[oahda]

Don't necessarily intend on localising the tool itself, but the games very much so, and I do want to have tools to localise the game within the editor for example, and to enter things like names of authors no matter the language/script, so it's still necessary for me.

So Pango/Cairo is going semi-well. It's fundamentally working, but combining diacritics mess things up no matter the script.

So these Arabic and Devanagari words without diacritics are fine:



But these with them are not:



Both Pango and Cairo are the latest version (I even tried switching Cairo from stable to devel). It doesn't seem to be a fundamental flaw tho, because it seems to work for many other people, so I must be getting something wrong locally. Can't figure it out...

(it's not the font)

[gimymblert]

That's pretty though

[oahda]

Yeah, I'm using the Amiri font. ε: