4 ms·

...and remember that Quake 3 required 64 MB to run, while Half Life managed to run on 96 MB of ram.

by BartSaM 9y ago

Narishma 9y ago
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.
- NTDF9 9y ago
  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.
  - lostmsu 9y ago
    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.
    - prewett 9y ago
      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.
    - flukus 9y ago
      So that accounts for 16MB of the 1500 used, where is the other 1484 going?
    - zeta0134 9y ago
      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.
- oppositelock 9y ago
  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.
  - mixedCase 9y ago
    > 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.
    - deleted 9y ago
      [deleted]
    - oppositelock 9y ago
      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.
      - mixedCase 9y ago
        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.
frik 9y ago
Half Life 1 run on 32MB ram.

...and remember that Quake 3 required 64 MB to run, while Half Life managed to run on 96 MB of ram.

Narishma 9y ago

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.

NTDF9 9y ago
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.
- lostmsu 9y ago
  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.
  - prewett 9y ago
    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.
  - flukus 9y ago
    So that accounts for 16MB of the 1500 used, where is the other 1484 going?
  - zeta0134 9y ago
    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.
oppositelock 9y ago
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.
- mixedCase 9y ago
  > 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.
  - deleted 9y ago
    [deleted]
  - oppositelock 9y ago
    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.
    - mixedCase 9y ago
      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.

frik 9y ago

Half Life 1 run on 32MB ram.