5 ms·

> Ultimately Crash fit into the PS1's memory with 4 bytes to spare. Yes, 4 bytes out of 2097152. Good times Wow. Just wow. One can only imagine the amount of h

by M4v3R 11y ago

> Ultimately Crash fit into the PS1's memory with 4 bytes to spare. Yes, 4 bytes out of 2097152. Good times Wow. Just wow. One can only imagine the amount of hard work and sweat that was put into making this possible. And the pride of developers when it actually worked and the game has become a success. Great story.

saurenandroid 11y ago
Some of the developers nowadays need to take clues from these guys.
- escherize 11y ago
  Care to elaborate?
  - untog 11y ago
    Presumably it's another complaint about developers these days being lazy, taking up too much memory/CPU cycles, blah blah...
    - colomon 11y ago
      The basic clock app on my Android phone takes 33MB of memory. That is completely and utterly insane. Except for playing MP3 alarms, everything on it could be done on a 64K Commodore 64 without breaking a sweat. And of course, the actual code for playing an MP3 is baked into the Android operating system, so that's not what's taking up all the space.
      - scott_s 11y ago
        Is it actually taking up an additional 33 MB, or is it just using libraries that are probably already loaded into physical memory, and it just happens to map those into its virtual address space?
      - Klathmon 11y ago
        The basic clock app on your Android phone has up to 4k assets, shadows, faux-3d layering, tons of animations, multi-touch support, gesture support, includes a timer, a countdown timer, an alarm system, every timezone imaginable, a separate "night mode", automatic "home time" for when you are traveling, multiple clock styles (digital vs analog), and all of the code runs in a VM. Besides some of the features, there is no way in hell a Commodore 64 would be able to handle the textures, input, and UI of an app like that. And while you may think that those things are useless, to the overwhelming majority it's the reason why they use that app at all. Besides, why not use 33MB of memory? I think the number of people that would actually benefit from being able to have 30MB more memory (while using the clock app) on their Android devices is literally 0. Plus being able to be somewhat wasteful with memory provides tons of benefits. It speeds development time, it reduces CPU usage via caching (which reduces battery consumption), it allows higher res textures and a nicer UI, it allows easier-to-maintain code, and tons of other little benefits.
        kuschku 11y ago
        No. Multi-touch is in the system libraries, shadows and faux-3d layering and animations, too, the alarm system and every timezone imaginable is in the system, automatic home time is in the system. The app uses 33MB of storage on disk. Only the app, none of the above mentioned libs. The Facebook app is nowadays 159MB. That’s 120 floppies. For a single app.
        Klathmon 11y ago
        I thought you were taking about RAM memory, not storage memory. Also, the Facebook app (on my Android device at least) is 40.36MB... But accounting for assets, multi-language translations, functionality, and the fact that it contains a bunch of multi-platform code (multi platform meaning Android with Google services, android with Amazon's stuff, Android with none of that, etc... which means it cant depend on a lot of "system" libraries that might not be there), and more then 40mb isn't even that bad. That being said the Facebook app is a bit of an outlier, with most apps being in the 5MB range.
        11y ago
Sir_Cmpwn 11y ago
The story of how Mew (Pokemon) came to be is also pretty interesting. From memory: when they were getting close to shipping, they had a completely full cart (only one or two bytes to spare). They removed all of the debugging stuff, which freed up enough space for a new Pokemon to be defined. A programmer secretly added Mew right before they shipped, and Nintendo didn't find out until a couple of weeks later.
- maccard 11y ago
  Yep - http://www.nintendo.co.uk/NOE/en_GB/news/iwata/iwata_asks_-_pokmon_heartgold_version__soulsilver_version_16288_16289.html http://www.nintendo.co.uk/NOE/en_GB/news/iwata/iwata_asks_-_...
- Navarr 11y ago
  That sounds like a rumor. Mew already existed in the storyline unless that programmer then added the entire Mew storyline (inc. Mewtwo) - otherwise there was no reason for Mewtwo to exist
  - Sir_Cmpwn 11y ago
    maccard posted a source a moment ago: http://www.nintendo.co.uk/NOE/en_GB/news/iwata/iwata_asks_-_pokmon_heartgold_version__soulsilver_version_16288_16289.html http://www.nintendo.co.uk/NOE/en_GB/news/iwata/iwata_asks_-_... The character of Mew was meant to be referenced through the story, but not actually catchable. Considering that you can only get Mew by exploiting bugs in the game, it's pretty believable that it wasn't added above the radar.
    - gambiting 11y ago
      You could obtain Mew in completely legitimate ways, it was given through promotional events in Japan: http://bulbapedia.bulbagarden.net/wiki/Mew_(Pok%C3%A9mon)#In_events http://bulbapedia.bulbagarden.net/wiki/Mew_(Pok%C3%A9mon)#In...
      - 11y ago
bryanlarsen 11y ago
4 bytes to spare isn't surprising. When you're crunching things down, you stop once it fits. I once worked on a project that used 4x of its memory space when the project was half done. When I was done, I had 13 free bits of space. Yes, bits; I was doing a lot of bit picking to get it to work. What was surprising is the lengths they went to to make things fit. A solver? Wow. My problem was relatively straight forward in comparison: just bit packing and silly amounts of code reuse: Hey, these two completely unrelated routines have the same 7 byte sequence; can I make it common? Fun times, I miss projects like that.
- stackcollision 11y ago
  Yes, this is kind of like "of course the remote is in the last place you look, why would you keep looking once you found it?" A little more than a year ago I was working on a very space-constrained device: only 2kb of program flash (an attiny23 for those curious). I had to use libusb with this, which ate up a huge portion of that space. My first shot at the main program put me over the limit by almost 500 bytes. By the time I was done, I had packed the program + the usb lib into the program flash with 4 bytes to spare. Man, was that fun.
- eru 11y ago
  I wonder why they didn't use an off-the-shelf bin packing solver. But I guess open source solvers weren't a thing back then, and the commercial ones were way too expensive. (Not too mention that the devs might not have heard of these beasts.)

by M4v3R 11y ago

saurenandroid 11y ago

Some of the developers nowadays need to take clues from these guys.

escherize 11y ago
Care to elaborate?
- untog 11y ago
  Presumably it's another complaint about developers these days being lazy, taking up too much memory/CPU cycles, blah blah...
  - colomon 11y ago
    The basic clock app on my Android phone takes 33MB of memory. That is completely and utterly insane. Except for playing MP3 alarms, everything on it could be done on a 64K Commodore 64 without breaking a sweat. And of course, the actual code for playing an MP3 is baked into the Android operating system, so that's not what's taking up all the space.
    - scott_s 11y ago
      Is it actually taking up an additional 33 MB, or is it just using libraries that are probably already loaded into physical memory, and it just happens to map those into its virtual address space?
    - Klathmon 11y ago
      The basic clock app on your Android phone has up to 4k assets, shadows, faux-3d layering, tons of animations, multi-touch support, gesture support, includes a timer, a countdown timer, an alarm system, every timezone imaginable, a separate "night mode", automatic "home time" for when you are traveling, multiple clock styles (digital vs analog), and all of the code runs in a VM. Besides some of the features, there is no way in hell a Commodore 64 would be able to handle the textures, input, and UI of an app like that. And while you may think that those things are useless, to the overwhelming majority it's the reason why they use that app at all. Besides, why not use 33MB of memory? I think the number of people that would actually benefit from being able to have 30MB more memory (while using the clock app) on their Android devices is literally 0. Plus being able to be somewhat wasteful with memory provides tons of benefits. It speeds development time, it reduces CPU usage via caching (which reduces battery consumption), it allows higher res textures and a nicer UI, it allows easier-to-maintain code, and tons of other little benefits.
      - kuschku 11y ago
        No. Multi-touch is in the system libraries, shadows and faux-3d layering and animations, too, the alarm system and every timezone imaginable is in the system, automatic home time is in the system. The app uses 33MB of storage on disk. Only the app, none of the above mentioned libs. The Facebook app is nowadays 159MB. That’s 120 floppies. For a single app.
        Klathmon 11y ago
        I thought you were taking about RAM memory, not storage memory. Also, the Facebook app (on my Android device at least) is 40.36MB... But accounting for assets, multi-language translations, functionality, and the fact that it contains a bunch of multi-platform code (multi platform meaning Android with Google services, android with Amazon's stuff, Android with none of that, etc... which means it cant depend on a lot of "system" libraries that might not be there), and more then 40mb isn't even that bad. That being said the Facebook app is a bit of an outlier, with most apps being in the 5MB range.
        11y ago

Sir_Cmpwn 11y ago

The story of how Mew (Pokemon) came to be is also pretty interesting. From memory: when they were getting close to shipping, they had a completely full cart (only one or two bytes to spare). They removed all of the debugging stuff, which freed up enough space for a new Pokemon to be defined. A programmer secretly added Mew right before they shipped, and Nintendo didn't find out until a couple of weeks later.

maccard 11y ago
Yep - http://www.nintendo.co.uk/NOE/en_GB/news/iwata/iwata_asks_-_pokmon_heartgold_version__soulsilver_version_16288_16289.html http://www.nintendo.co.uk/NOE/en_GB/news/iwata/iwata_asks_-_...
Navarr 11y ago
That sounds like a rumor. Mew already existed in the storyline unless that programmer then added the entire Mew storyline (inc. Mewtwo) - otherwise there was no reason for Mewtwo to exist
- Sir_Cmpwn 11y ago
  maccard posted a source a moment ago: http://www.nintendo.co.uk/NOE/en_GB/news/iwata/iwata_asks_-_pokmon_heartgold_version__soulsilver_version_16288_16289.html http://www.nintendo.co.uk/NOE/en_GB/news/iwata/iwata_asks_-_... The character of Mew was meant to be referenced through the story, but not actually catchable. Considering that you can only get Mew by exploiting bugs in the game, it's pretty believable that it wasn't added above the radar.
  - gambiting 11y ago
    You could obtain Mew in completely legitimate ways, it was given through promotional events in Japan: http://bulbapedia.bulbagarden.net/wiki/Mew_(Pok%C3%A9mon)#In_events http://bulbapedia.bulbagarden.net/wiki/Mew_(Pok%C3%A9mon)#In...
    - 11y ago

bryanlarsen 11y ago

4 bytes to spare isn't surprising. When you're crunching things down, you stop once it fits. I once worked on a project that used 4x of its memory space when the project was half done. When I was done, I had 13 free bits of space. Yes, bits; I was doing a lot of bit picking to get it to work. What was surprising is the lengths they went to to make things fit. A solver? Wow. My problem was relatively straight forward in comparison: just bit packing and silly amounts of code reuse: Hey, these two completely unrelated routines have the same 7 byte sequence; can I make it common? Fun times, I miss projects like that.

stackcollision 11y ago
Yes, this is kind of like "of course the remote is in the last place you look, why would you keep looking once you found it?" A little more than a year ago I was working on a very space-constrained device: only 2kb of program flash (an attiny23 for those curious). I had to use libusb with this, which ate up a huge portion of that space. My first shot at the main program put me over the limit by almost 500 bytes. By the time I was done, I had packed the program + the usb lib into the program flash with 4 bytes to spare. Man, was that fun.
eru 11y ago
I wonder why they didn't use an off-the-shelf bin packing solver. But I guess open source solvers weren't a thing back then, and the commercial ones were way too expensive. (Not too mention that the devs might not have heard of these beasts.)