4 ms·

Hi! I'm glad to see that the post is promoting constructive dialog about what does or doesn't make portable code, which is what the point actually was (in addi

Hi! I'm glad to see that the post is promoting constructive dialog about what does or doesn't make portable code, which is what the point actually was (in addition to shedding a bit of light about the state of porting Unity to Linux). I'll clarify a few things: 1. Unity was originally written for Mac OS X, then later ported to Windows (not the other way around). Given that it's more than possible to have a case-sensitive HFS+ filesystems (since, I think OS X Panther released in 2003?), IMO it would have been more future proof for us to be sure to develop on a case-sensitive filesystem. Unity users over the years have tried to run Unity on a case-sensitive HFS+ filesystem and failed, so it would have been nice for all of those guys. :-) 2. Note that the point in the article was not to avoid using OS-specific defines (that's impossible), it was to make sure to do something sane (like #error) in the #else case that would make it immediately clear something need to be implemented there. 3.1. Yes, the higher-level point is indeed, "Be smart/cautious about what language features to use for the sake of portability". 3.2 & 3.3. Of course it's just a matter of opinion, but I wish that we'd considered a more platform-agnostic approach to GUI handling when the number of platforms that Unity was ported to went from 1 to 2. I (and others) are still a fan of the menu-system-written-entirely-in-Unity-GUI idea, but others (within Unity), for very good reasons, disagree. Fair enough. Anyway, thanks for sharing your thoughts; when I write about anything I'm always looking forward to hearing a different perspective, and one of the main goals I had in writing the post was to promote constructive dialog about what it means to write "portable" code. :-)

akavel 11y ago
Thanks for the reply! Most of them make much more sense now. As to 1. and 2., I'd say you could want to consider merging those clarifications into the original article. In 1., arguably some background knowledge of Unity could be expected from the reader, and maybe I'm just not the intended target. But especially in 2., I'm afraid I can't agree that those clarifications are there, just hidden between words. There are very little words in 2. in the article. As to 3.2 & 3.3, I don't really get the clarifications unfortunately; I think it shows even more that I don't really have knowledge of Unity, so I'm starting to think maybe that wasn't really an article for me to start with. Thanks for the interesting and insightful discussion!

akavel 11y ago

Thanks for the reply! Most of them make much more sense now. As to 1. and 2., I'd say you could want to consider merging those clarifications into the original article. In 1., arguably some background knowledge of Unity could be expected from the reader, and maybe I'm just not the intended target. But especially in 2., I'm afraid I can't agree that those clarifications are there, just hidden between words. There are very little words in 2. in the article. As to 3.2 & 3.3, I don't really get the clarifications unfortunately; I think it shows even more that I don't really have knowledge of Unity, so I'm starting to think maybe that wasn't really an article for me to start with. Thanks for the interesting and insightful discussion!