How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1 • Hacker News Board

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

#241

Post by vetinari » Fri, Jun 19, 2015, 10:55 AM UTC

rosege wrote: post #228

vetinari wrote: post #159

Earlier quoted context omitted.

One icon in Win95 had 512 bytes (32x32, 16 color, 4 bitplanes). One icon in Android has 256 kB (256x256, true color). The 800x600, 16-bit hicolor (that's what I used at the time) framebuffer had a bit under 940 kB. The 1920x1200 truecolor has 8,8 MB, not counting the texture backing stores used by modern display servers. The amount of RAM needed has to do with assets used by the code, not the code itself. The code it…

my android phone does :-) asus ze551ml

You phone is also Intel based, not ARM. That opens another question - would Intel be able to make phone SOCs, if Android SDK would compile to native ARM code, as some advocates prefer?

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

#242

Post by vetinari » Fri, Jun 19, 2015, 10:58 AM UTC

stuaxo wrote: post #205

frik wrote: post #128

Earlier quoted context omitted.

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…

Interesting... Fast 486 (120mhz) with 12mb at 640x480 was swapping my so much fun could watch the logo screen rendering slowly down the screen

I remember 386DX (40 MHz) with 4 MB to be unusable at all (yes, it was possible to install Win95, but that's all) and Pentium 120 with 16 MB and S3 card running 800x600 hicolor to be great. In 1996.

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

#243

Post by DCoder » Fri, Jun 19, 2015, 12:33 PM UTC

eru wrote: post #227

motdiem wrote: post #129

Earlier quoted context omitted.

That's an interesting point. I hadn't considered the impact of ondemand updates to future abandonware - looks like another case where pirated illegal versions might have better preservation than official ones.

Some fans even made patches for bugs in Master of Orion, in the binary.

Command&Conquer: Red Alert 2 and its expansion pack also received community patches (I contributed to them a lot) to its binary. When EA later released The First Decade bundle with all the old games in it, they removed the old copy-protection. Most games in the bundle were simply recompiled to remove it, but for the expansion pack they hex-edited the copy-protection to keep it community patch compatible.

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

#244

Post by dogen » Fri, Jun 19, 2015, 3:36 PM UTC

gambiting wrote: post #233

dogen wrote: post #229

Earlier quoted context omitted.

I remember an interview with some guys from criterion who said they always made sure to maintain 60fps through the development of their game.

At least in my own experience, this is not standard throughout the industry.

Oh yeah, I know it isn't. But it seemed to work for them back when they made 60 fps games.

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

#245

Post by balls187 » Fri, Jun 19, 2015, 9:22 PM UTC

teacup50 wrote: post #223

balls187 wrote: post #201

Earlier quoted context omitted.

> Modern game development seems to say "eh, a little hitching won't hurt anyone" Or just like in the PS1 days, game developers still have to make trade-offs to meet dead drop dates set by publishers. Online enabled patches can allow developers to be a little more cavalier with the quality, as they push to build more features closer to ship date.

"Online enabled patches can allow developers to be a little more cavalier ..." That just means that we get to deal with buggy crap while they tell themselves it's OK because they can ship another update. Sigh.

I'm going to give game developers the benefit of the doubt by believing they're not OK with shipping bugs.

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

#246

Post by phire » Fri, Jun 19, 2015, 9:30 PM UTC

zelos wrote: post #87

i_are_smart wrote: post #52

> 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.

Most Nintendo games still seem to be locked at 60Hz (sometimes 30 maybe?). Look at the fuss when people realised that Mario Kart 8 dropped to 59Hz sometimes ;-)

Nintendo generally picks a framerate and sticks to it. The N64 zelda games were actually locked at 20hz.

(It is possible to do 60hz on the N64, but it's really hard)

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

#247

Post by malkia » Sat, Jun 20, 2015, 7:13 AM UTC

deadlockgB wrote: post #231

malkia wrote: post #158

Earlier quoted context omitted.

I worked on the port of MGS to PC back in 1999-2000. Here is what I've learned: - Models were not "skinned" as it was popular in the day. Some textures were covering only the front part of the body, others arms, etc. As such it was possible to use very little colors per texture (16) and use palettes (which is a very small "texture" in the graphics memory). If models were skinned they would've required all the colors…

> Hopefully he kept the original "C" code You mean "Fortunately he kept the original "C" code? Great read anyway!

Thank you! And thanks for the correction, but it looks like I can't correct it anymore (no more editing allowed).

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

#248

Post by malkia » Sat, Jun 20, 2015, 7:22 AM UTC

nickpsecurity wrote: post #210

malkia wrote: post #158

Earlier quoted context omitted.

I worked on the port of MGS to PC back in 1999-2000. Here is what I've learned: - Models were not "skinned" as it was popular in the day. Some textures were covering only the front part of the body, others arms, etc. As such it was possible to use very little colors per texture (16) and use palettes (which is a very small "texture" in the graphics memory). If models were skinned they would've required all the colors…

Two things to take away for coding in general: clever CRC trick; dedicated optimization programmer. These might benefit other projects in the future.

The compilers back then were horrible (gcc2 something?). Our next project was the other way around - porting IHRA Drag Racing from PC to Playstation... now that was a bitch, and showed how inexperienced we were :) (it's much easier to port to something where you have better hardware and software all along).

The IHRA Drag Racing game (PC) version had a full simulation of the engine (valves, torque) - e.g. for any configuration it'll calculate right away the torque/gear ratio tables (okay, I was never a car buff, and my memory is very short here), but essentially there was an algorithm, which I later understood certain car-tuning services were using to adjust real cars! - I mean there were DOUBLES and lots of fortran-looking code written in "C".

Where we failed was trying to reuse this code on the PSX. First there was no hardware floating point, and what took 10 seconds of calcuation on PC took 45 minutes on PS1 - unacceptable.

Again our boss made a crazy idea - why we don't precalculate some values and store them on the CD - way more limited than the PC, but still something. Not sure how the values were chosen, but overall the game was not a success - one magizine rated it, as one of the worst PSX games ever... I left the project early on, as I felt it wasn't doing good (and was feeling really bad since then about it, as I felt like deserting the person that took care of me, and brought me to US) - http://www.mobygames.com/game/playstation/ihra-motorsports-d...

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

#249

Post by nickpsecurity » Sun, Jun 21, 2015, 2:24 AM UTC

malkia wrote: post #248

nickpsecurity wrote: post #210

Earlier quoted context omitted.

Two things to take away for coding in general: clever CRC trick; dedicated optimization programmer. These might benefit other projects in the future.

The compilers back then were horrible (gcc2 something?). Our next project was the other way around - porting IHRA Drag Racing from PC to Playstation... now that was a bitch, and showed how inexperienced we were :) (it's much easier to port to something where you have better hardware and software all along). The IHRA Drag Racing game (PC) version had a full simulation of the engine (valves, torque) - e.g. for any conf…

I'm guessing the compilers got better with the modern game consoles? They should be great for latest since it's just multi-core x86.

Regarding engine simulation, that's a trip that it was useful enough mechanics were using it. Kind of disturbing they were using it though... Yeah, precalculation is kind of the goto way to deal with this sort of things for many resource- or performance-constrained systems. Always worth remembering.

I looked up the game on eBay. I can't get a consistent price because everyone starts at $10 and works down from there. Still worth somewhere from $1-9 plus shipping. Your worst project is at least helping people with bill money. Not the worst outcome. ;)

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

#250

Post by kuschku » Sun, Jun 21, 2015, 7:42 AM UTC

Klathmon wrote: post #220

kuschku wrote: post #213

Earlier quoted context omitted.

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.

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…

I am working on an open source project, we have a simple IRC client for android (it uses a server for the translation between IRC and our protocol, the server also allows the app to show messages from times when the device was off).

This app already has over 8MB storage space and 34MB RAM. And the app has only 5 images overall in it, uses no Google services, and has only about 25k LOC.