Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm pretty sure Half-Life required a lot less than that. The first PC I played it on only had 16 or 32MB of RAM.


Those games were all written to "bare metal", talking to Win32, DirectX, etc. Most modern apps like Slack use a pile of giant frameworks which handle most cross-platform portability, at the cost of massive explosions of resource usage. It's a lot more work to write platform-specific code without those frameworks. I don't defend their choices, they're big enough to pay that cost, just explaining where this comes from.


> It's a lot more work to write platform-specific code without those frameworks

Qt/QML abstracts over a ton of platforms, lets you write UI code in JavaScript, is extremely easy to pick up, has a WYSIWYG drag-n-drop editor and consumes a small fraction of the resources Electron does.

The overuse of Electron is not because everything else is impossibly hard; it's just old-school fashion-driven development.


I've got a lot of experience with Qt, since I ported Google Earth from Windows to mac and linux, and it was Qt based back then. You have the problem of having slightly non-native feel because Qt has to code around platform differences to present a unified API. When we first released the app, we took a lot of criticism because of its non-native feel on all platforms (except for Linux, which doesn't have a native feel). So, if you want a top-quality app, you're probably breaking it apart into a platform independent core and then writing your interface separately on each platform using native API's. I wish that the cross-platform abstractions worked well enough to be indistinguishable from a native well-coded app, but we're not there yet.


I didn't suggest Qt as an alternative for native toolkits to achieve a native look and feel; while it can be done it's a lot of work. I suggested Qt (specifically, QML) as an alternative to Electron, which doesn't care about native look and feel.


Bloat is making me so angry that I'd take an as400 textual interface as native feel any day. The web era is one step too much in the wrong direction to me. I enjoyed the hyper genericity of the web, but I'm tempted to say we need a little bit more of the flat and trickful things of the past.


You guys should remember that a lot of crap we write nowadays is a consequence of bloated languages and "move fast break things" attitude.

Doom and Half life were at their core exceptionally optimized C.


Behind the trees you don't see a forest: Half-Life used 32MB of memory on 1024x768 display. By 4 or even 2 byte color it is 2MB just to store picture output. Modern apps work with 4k2k*4byte color, which on itself is 8 times more memory.


I think I understand the point you're trying to make (modern apps draw to larger screens, and therefore must use more memory) but this is a poor comparison for a number of reasons. The most obvious of these reasons is that graphics cards are leagues ahead of where they were back in the days of Half Life. Sure the framebuffer takes a bit more memory, but a 4k frame is only about 32MB of memory at 32bits per pixel.

Anyway, you're root argument is still somewhat valid: Half Life was working with some really tiny constraints compared to modern machines, and did amazing things within those limits. Modern apps, were they coded to the same level of optimization as Half Life, should be much, much smaller and more efficient than they are. But as it turns out, the human cost of developing video game software is high, and the one area where Electron truly succeeds is in its ease of use. By driving development costs down for non-game apps, it balances out its high resource usage, and to a company producing software, that's enticing. I think that's awful (and would prefer to run optimized software personally) but the industry seems to disagree with me.


So, 2 MB for the display. And then there are the textures for the walls, plants, people, monsters, etc. And the vertex data for each of the models on the level. And the level itself. And then there are the light maps for static lighting. That's at a minimum. After that there is the memory required for the AI. Much of the models and textures won't be used in any given scene, but might get used in the next frame, or the next half second, and to avoid long pauses when a new model is loaded they all have to be in memory. If Half Life could have been done in less memory, I'm pretty sure they would have done it. It probably started off using a lot more memory and they probably spent a lot of time getting the memory down so that your mid-class machine could play it.


So that accounts for 16MB of the 1500 used, where is the other 1484 going?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: