5 ms·
I very much disagree with JBlow because I came from games, I had similar opinions, and then I worked on "real software" (Chrome) and I had my thinking corrected
by greggman3 4y ago
I very much disagree with JBlow because I came from games, I had similar opinions, and then I worked on "real software" (Chrome) and I had my thinking corrected. The problems JBlow and similar game devs are solving are not the same problems being solved elsewhere if you they really tried to solve the *same* problems I strongly believe they'd change their minds.
IIRC one example he once brought up was a text editor written with a small amount of code. Yea sure, I also had a word process that fit in 16k (https://en.wikipedia.org/wiki/AtariWriter https://en.wikipedia.org/wiki/AtariWriter) but we're not on ASCII based computers with only text mode. Just a full unicode font takes 10s of megs of space. We're asking our software to draw fonts in any size, in several styles, in any language, and with emoji. That alone would break most of his assumptions because you can't just put them all in memory as pre-rendered glyphs, your user's don't have enough memory. Yet in games, most game devs would just basically say "F-that, you only get ASCII" or "F that, we're only supporting EFIGS + Katanana" and we only need 1 style.
Two good articles on the issues of text that games never deal with
https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/
https://lord.io/text-editing-hates-you-too/ https://lord.io/text-editing-hates-you-too/
The point being, it's the same all the way down in all areas. Game networking is not nearly as complicated as say the networking in a browser, that has to be able to run N video streams + M audio streams + X WebRTC video chats + Y Websockets, and video capture + audio capture and sending that data over the net, etc vs some game which if it ever plays video (many don't) only ever plays one video at a time, in known sizes and formats, and usually not streamed over the net but read directly from storage, etc...
Or take just displaying images. Most games know up front how many images will be displayed. You might even give your artists a budget, no area of the game can use more than XX megs of image data. A browser can't run with those limits. Go look at imgur.com or scrolldit.com or pinterest. Situations games never deal with.
And on top that there's just getting shit done. If I can write an app in a high-level system and ship on iOS, Android, Windows, Mac, iPadOS, I'm going to. I don't care that it's more bloated than if I hand coded assembly language for each one and neither do my customers. Sure they care if my app is buggy or the UX sucks but that's got nothing to do with whether I squeezed out every last byte and cycle out out of it. HNers like to rant about apps that use some kind of less than native framework but nearly all them are using well made apps that use those frameworks, they're just not aware of it because the people making them did a good job.
- zzo38computer 4y agoI do not want emoji on my computer, and I hate Unicode. I also think that bitmap fonts are less fuzzy, and can be better at the proper size. I write software avoiding Unicode as much as possible; if you need international text then you can specify which code page numbers to use. But, that still would be possibility of text directions, Chinese/Japanese (without Han unification), etc, but using a simpler way. (Even, this is as someone writing a game engine, I add possibility to specify code page numbers, and use fonts for those code pages. Currently only 8-bit characters but in future possibly also EUC (and/or other multibyte character sets) so that Chinese/Japanese text, etc is also possible.) GTK is terrible (I prefer Xaw). Use of Unicode is one problem, but then although there is a menu to insert Unicode control characters, they are not visible even while editing (making it difficult to edit), and I also do not like the use of kerning during editing.
- scrollaway 4y ago> I do not want emoji on my computer, and I hate Unicode. Ok well good for you but that’s akin to saying “I don’t want other languages than English on my computer and I hate the color Green”. It’s completely irrelevant what you prefer, the point of general computing is that it’s not for you, it’s for everybody. If you are writing software for everybody then I’m sorry but xenophobic assumptions just don’t hold. Because really, what’s hidden in the meaning behind your post is “I don’t want people who speak languages other than English to be able to communicate as easily as me”. I’m sure that’s not your intent but it is the direct result of your actions.
- zzo38computer 4y agoIt is not true. I do want people who write in other languages to be able to communicate (better than me, not worse), using better encodings than Unicode. I do intend to support other languages writing, including international text (text directions, multibyte encodings, etc). However, Unicode is too messy and isn't good (and has problems such as the Han unification, ambiguous widths, changes in versions of Unicode which complicate the specification, etc). Some people think that TRON code would be better, although TRON has its own problems (for example, its design means that character sets other than JIS don't fit properly), even though there are some advantages, especially for writing in Japanese. My opinion is that it is better to not use a single character set for everything; instead, different ones are useful for different purposes. (And if needed, program to convert encodings is possible, although this can result in incorrect characters sometimes, depending on the context. It is an approximation if you have no other choice, but it would be better to use proper fonts and text handling for the appropriate code pages.)