Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

quora.com

Post reply on HN
Print view View original

231–240 of 254 posts

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

#231

Post by deadlockgB »

malkia wrote: post #158
timboslice wrote: post #95

Earlier quoted context omitted.

Metal Gear Solid

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!

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

#232

Post by lern_too_spel »

pjmlp wrote: post #226
lern_too_spel wrote: post #211

Earlier quoted context omitted.

That shows how little you understand about the Android build tools. Dalvik and ART are not compilers. Prior to this year, javac compiled the Java code to .class files and then dx translated the Java bytecode in the .class files into Dalvik bytecode in a .dex file, with some simple dedupe optimizations. Only this year did the Android build system switch to Google's own compiler.

Go take a degree in computer science, learn about intermediate code representation, compiler frontened, compiler backend, CPU instructions, JIT compiler, AOT compiler, register selection. Then make little drawings about which piece of Android is converting intermediate code representation into native CPU instructions. For brownie points compare the quality of generated Asssembly code between Hotspot, Dalvik and ART f…

Already done and wrote a non-optimizing lisp compiler and an optimizing toy compiler with common subexpression elimination and fancy register allocation.

I gather from your response that you've realized you were wrong about Android not using javac but were too proud to admit it. Don't worry, we can fix your pride problem with these tasks below:

1. Dalvik and ART don't take jar files as input, so it is impossible to get your brownie points. Learn why.

2. Oracle's Hotspot targets x86 and x86-64, and Dalvik and ART are mostly focused on ARM. Learn the difference between ISAs.

3. Hotspot and Dalvik make different tradeoffs between CPU and memory both in their choices of garbage collectors and in their JIT strategies. Think about why that would be.

4. The word "compiler" by itself refers to a program that translates source code into object code. Notably, an assembler is not usually considered to be a compiler, and JIT "compilers" were originally called dynamic translators for three decades, with JIT compiler only appearing in the 90s. Given that terminology background, figure out why most people would call javac a compiler but not Hotspot or Apple's Rosetta.

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

#233

Post by gambiting »

dogen wrote: post #229
gambiting wrote: post #75

Earlier quoted context omitted.

The problem is, that fps stays below 30 for 90% of the development cycle. Only in the last few months of a project everyone rips out useless code, debug code, debug overlays, loggers, extra network connections for statistic and performance servers,and finally you can produce a "nearly" final version of the game that doesn't have any debug code in - and only in that state you can see how it will run on actual hardware…

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.

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

#234

Post by fosforsvenne »

gambiting wrote: post #57
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.

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 also why improving fuel/power efficacy in industry usually doesn't help the environment.

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

#235

Post by brobinson »

Natsu wrote: post #224
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…

> it also uncovered things like "CONTINEKU" "METARU GIRU SORIDU" (Continue, Metal Gear Solid), and at first I was like... are these folks writing english with japanese symbols? It's pretty normal for Japanese people to write English words in katakana, especially in things like games. Many program menus are perfectly readable by English speakers if you can read katakana. It's something taught in every Japanese school,…

Close, it's "soriddo" (ソリッド).

English loan words in Japanese are so fascinating to me. Here's an example: "limited slip differential" -> リミテッド・スリップ・デフ (rimiteddo surippu defu)

(The ・ is used to separate foreign words/names when a Japanese speaker would not be able to figure it out)

This must be how Romance-language speakers feel when they see their words modified and incorporated into English.

If you want to learn the Katakana syllabary, try this website I found recently: http://katakana.training

There's also http://hiragana.training for the other syllabary.

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

#236

Post by Natsu »

brobinson wrote: post #235
Natsu wrote: post #224

Earlier quoted context omitted.

> it also uncovered things like "CONTINEKU" "METARU GIRU SORIDU" (Continue, Metal Gear Solid), and at first I was like... are these folks writing english with japanese symbols? It's pretty normal for Japanese people to write English words in katakana, especially in things like games. Many program menus are perfectly readable by English speakers if you can read katakana. It's something taught in every Japanese school,…

Close, it's "soriddo" (ソリッド). English loan words in Japanese are so fascinating to me. Here's an example: "limited slip differential" -> リミテッド・スリップ・デフ (rimiteddo surippu defu) (The ・ is used to separate foreign words/names when a Japanese speaker would not be able to figure it out) This must be how Romance-language speakers feel when they see their words modified and incorporated into English. If you want to learn th…

Yes, it's surprising how many things you can figure out just by being able to read hiragana and katakana. Though there are a lot of things that tend to be anomalous, like the insertion of small tsu characters in places an English speaker would not imagine a glottal stop, even assuming an English speaker who even knows what that is.

Sometimes it really takes imagination. I have a family member who has an arcade game labeled "Hangly Man" (a Pac-Man clone). It took quite a while for it to dawn on me to reverse that back to kana (HANGURI) and figure out that it was meant to be "Hungry Man."

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

#237

Post by ars »

fosforsvenne wrote: post #234
gambiting wrote: post #57

Earlier quoted context omitted.

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 also why improving fuel/power efficacy in industry usually doesn't help the environment.

https://en.wikipedia.org/wiki/Jevons_paradox

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

#238

Post by gambiting »

adestefan wrote: post #90
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.

The worse thing that ever happened to game development was the on-demand updates. There is nothing worse than buying a game on release day only to wait for it to download a patch.

When we submit games to Sony/MS/Nintendo for publishing, we usually have to do it 2-3 months in advance. What are programmers supposed to do in that time between "end" of development and release date? Of course everyone works on little things that were left, you might as well release them as a patch!

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

#239

Post by [deleted] »

lern_too_spel wrote: post #232
pjmlp wrote: post #226

Earlier quoted context omitted.

Go take a degree in computer science, learn about intermediate code representation, compiler frontened, compiler backend, CPU instructions, JIT compiler, AOT compiler, register selection. Then make little drawings about which piece of Android is converting intermediate code representation into native CPU instructions. For brownie points compare the quality of generated Asssembly code between Hotspot, Dalvik and ART f…

Already done and wrote a non-optimizing lisp compiler and an optimizing toy compiler with common subexpression elimination and fancy register allocation. I gather from your response that you've realized you were wrong about Android not using javac but were too proud to admit it. Don't worry, we can fix your pride problem with these tasks below: 1. Dalvik and ART don't take jar files as input, so it is impossible to g…

[deleted]

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

#240

Post by vetinari »

vardump wrote: post #209
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…

Android doesn't support LPAE? That's pretty surprising, any sources about that? LPAE doesn't need any usermode support to function. What specifically does Android do to prevent using LPAE in underlying Linux kernel?

Well, one thing is what Linux kernel supports by itself, other is, what does the board support package for your chipset. So maybe there is LPAE Android device somewhere, where the SoC provider did bother, but in general, nobody does.
Post reply on HN