Live data from Hacker News

How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

quora.com

141–150 of 254 posts

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#141
post #128

Earlier quoted context omitted.

Win95 machines with 4 MB RAM were exceptions, not the rule. It was very painful to use such machine, as it was swapping all time time, otherwise doing nothing. Any realistic setup had 8 MB RAM or more. Application at that time also didn't support i18n, didn't anti alias fonts, had low-res, low-color assets, that were enough at 320x200(240)/640x480 resolution.

A Pentium 133 with 8MB and 800x600 (32bit colors) run fine in with Win95a and several open applications. Try that with Android, even with 2GB RAM and quad core CPU - the Java based system on top of Linux is quite resource hungry. Flagship Android 5 phones have at least twice the hardware spec (twice as much RAM and CPU) of the iPhone 6 and are comparable in performance and user experience (latency) and not faster. Th…

Java is not the problem, rather Google's shitty compilers.

Lots of industrial applications run embedded Java with a few KBs and acceptable performance for their use cases.

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#142

Earlier quoted context omitted.

I get the sentiment (they should have tested more thoroughly), but I for one appreciate the on-demand update mechanism. Would you rather play a game with previously unknown bugs, or have them smashed on launch day and get a patch to make your experience more stable?

Games were stable enough before. And the stability of an average game in the first few month definitely went down with the introduction of on-demand online updates. Not only that, it's not entirely uncommon to see half-gigabyte patches.

Is that so much when the games themselves have ballooned into the double-digits of gigabytes? A .5 gig patch isn't a whole lot when Dragon Age: Origins takes up 20gb in the first place (and thats a pretty old game)

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#144

> and this had to be paged in and out dynamically, without any "hitches"—loading lags where the frame rate would drop below 30 Hz. This is what gets me. Modern game development seems to say "eh, a little hitching won't hurt anyone", and then we wind up with games that run like shit. Even on consoles.

With internet based games I wonder if that loading screen/hitch is essentially finding you a server as you move from one zone to another if the server you were on was too crowded. I also wonder if they are doing the equivalent in modern consoles - pushing the limits with graphics, etc. where you simply can't avoid the hitch. It would be good to hear someone's perspective on this that works on these types of games.

Moving from one server to another can be instantaneous. Just use the cellphone model where they do proper handoffs between base stations. As to loading assets, plenty of games used a streaming model where you can explore huge worlds without issue.

PS: Skyrim is an interesting case where there is a player made patch to make city's open world where the original game has a loading screen. http://www.nexusmods.com/skyrim/mods/8058

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#145
post #122

Earlier quoted context omitted.

That would have to be Andy. I'm really kind of a hack when it comes to lisp programming. :) But yes, Andy's lisp code is certainly great -- all the more so because he also wrote the lisp compilers that compiled it. :)

He didn't use a commercial lisp? I thought he used Allegro?

He did use Allegro, but only to host his own compilers.

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#146
post #92

Earlier quoted context omitted.

Care to elaborate?

Presumably it's another complaint about developers these days being lazy, taking up too much memory/CPU cycles, blah blah...

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.

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#147

Earlier quoted context omitted.

That has nothing todo with what op is referring to. Even on iOS you have a virtual memory system, like a normal PC does. If your app runs out of ram it will page to storage and the OS handles this for you. The PS1/N64 did not have any storage beyond RAM and also no virtual memory management so you had to write all the paging from CD/Cartridge to RAM yourself. Quite a difference.

Sort of. iOS does have a virtual memory system, but it's not as forgiving as a full OS would be; applications that fail to free up memory when asked to (i.e. in a low memory situation) are killed by the OS. See also: https://developer.apple.com/library/mac/documentation/Perfor...

That should be much easier to optimize against vs having no paging at all though. Are Apps running in the background asked to free up storage or be killed before the active app needs to do the same or are they referring to the active app ?

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#148
post #138
post #113

Earlier quoted context omitted.

Embedded yes, but modern mobile is miles away from this. ~1GHz dual core, triple issue out-of-order CPU with 512MB-1GB RAM and maybe 10-20GB storage? That was a reasonable desktop PC not that many years ago.

Yet we have basic apps like the phone app stuttering on such "high-end" hardware.

Is your point something interesting or are you just snarkily pointing out that perfection has not yet been attained?

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#149

> and this had to be paged in and out dynamically, without any "hitches"—loading lags where the frame rate would drop below 30 Hz. This is what gets me. Modern game development seems to say "eh, a little hitching won't hurt anyone", and then we wind up with games that run like shit. Even on consoles.

I work as a programmer in games industry,and I feel like the problem is made worse by artists and level designers who add more stuff without worrying about performance. I can make a super efficient physics system or model loader,but that only means that someone somewhere is going to add more particle effects or lights or whatever, or maybe placing too many props in the scene so PS4/X1 can't handle it. In fact, the se…

This is eerily similar to the problems we face in the browser space. Make CSS styling faster and developers will just write more complex CSS to take advantage of it. Then people blame the browser (and the Web in general) for being slow.

The difference is, sadly, that we don't control the assets at all. :(

Re: How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1

#150

Earlier quoted context omitted.

These concerns are back for VR. Also, remember that Crash Bandicoot was made at a time when devs weren't sure how mouse-look should work.

Well, mouse look was already in use with shooters at that point; it was well known. Maybe you mean behind the character third-person camera? Or just the concept on consoles?

Quake came out a few months earlier and had mouselook turned off by default (and I (somehow) played the whole game with only the keyboard). So I would agree that the concept wasn't well-known or established yet.
Post reply on HN