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

161–170 of 254 posts

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

#161

Post by pjmlp »

kayoone wrote: post #147
Cthulhu_ wrote: post #135

Earlier quoted context omitted.

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 ?

Background apps are even worse, as by default they are suspended.

If the system requires memory the ones with higher memory footprint are the first ones to go. They aren't asked nicely, just killed.

This might have changed on newer versions though. I am typing this from memory.

Also on the Watch there are also time constraints. How quick an app is allowed to execute.

Windows Phone also has similar constraints.

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

#162

Post by pjmlp »

oldmanjay wrote: post #148
CrLf wrote: post #138

Earlier quoted context omitted.

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?

I guess the OP is referring to the code quality of said apps.

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

#164

Post by qrmn »

jkldotio wrote: post #49

I recall reading that at one point game programmers were using portions of their code as textures. Which reminds me of the story of Mel. http://www.catb.org/jargon/html/story-of-mel.html

Indeed, the old FTL game, Dungeon Master (an old RPG, its most direct modern successor-by-inspiration being Legend of Grimrock) put some copy-protection code in one of its sprites, where it hoped you wouldn't notice.

One part of it would repeatedly read one "weak" sector that had been incorrectly encoded on the disk in such a way that it would usually read inconsistently, and would crash the game with an obscure system error if it didn't read differently.

Cute, but kind of a problem when you have a much better quality floppy drive which read the weak sector consistently.

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

#165

Post by wnevets »

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…

>- Two lessons learned from it - We've put much better high-res textures for the eyes (hired someone from Texas to do it for us), when we got the idea rejected by Hideo himself (by the phone), he told us (through the interpretter) that the game during normal game-play did not have any eye-movement, so higher-res textures would look like crap, while with a blurry texture your own eyes won't see it as a problem - it's really sometimes LESS is better.

Could this be part of the reason why I didnt like the look of the gamecube port as much as the PS version?

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

#166

Post by mtinkerhess »

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…

That is some amazing info!

I found this video where you can see the effects of the sub-pixel vertex precision issue: https://www.youtube.com/watch?v=HrFcYbwz_ws

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

#167

Post by qrmn »

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…

Fascinating insights.

Lots of music on the PSX used a system like that, because that's a very natural fit for the PSX SPU. Tracker "modules" combine the sample data and tabulated sequencing data, but what you found more often on the PSX was separate sample wavetables and sequencing data closer to (i.e. literally converted from, and convertible back to) a MIDI format: it's smaller, timing-based, without all those pesky 00s wasting space. (It sounds better with the PSX reverb unit/buffer on top, of course.) It's actually very similar to what Minoru Akao did for the AKAO sound engine for the PSX Final Fantasy games, for example.

What did you think of the multi-tasking kernel/DMA bit in the "main" binary? (Or did you just remove that?)

By the way, the VR missions mentioned above were released as a separate add-on disc in many regions (rather than the later release Integral which the PC port was). If you do happen to have an original and can't play it on a PS2/PS3 because it doesn't recognise that the 'lid' is open (because it's a tray/slot-loader)... try launching the other executable, it runs fine :)

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

#168

Post by malkia »

mtinkerhess wrote: post #166
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…

That is some amazing info! I found this video where you can see the effects of the sub-pixel vertex precision issue: https://www.youtube.com/watch?v=HrFcYbwz_ws

Thank you for sharing this. This brings so many memories to me, as it was my first professional gig! I've put all my time into it, we were so fast back then, we've got the first level working on PC for two-three weeks. It took much more (7-8 months) to finish. At some point there was a deal whether we would allow load/save from any point in the game, but instead we proposed to include the VR Missions instead of it.

Early on due to my porting libraries I've introduced a severe bug, where the internal timer was 10x (or 100x?) faster, causing issues for loading/saving, this was resolved just weeks before shipping thanks to the other awesome Ukraine programmer. It was also a lesson for me to be less cocky, and take the blame sometimes.

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

#169

Post by javajosh »

kozak wrote: post #18
javajosh wrote: post #7

Earlier quoted context omitted.

There are some abstractions, like TCP sockets, that I don't think anyone would leave behind. But language abstractions like "classes" or even "functions" are certainly worth digging into. (The new lambda feature in Java 8 is an interesting case - you don't have to get into C to see the complexity there, but rather the bytecode, which is a kind of abstract sort of assembly.) I'm not terribly familiar with the scene, b…

Can you suggest some explanation of the lambda feature in byte code?

Sure - read this gist from the bottom up: https://gist.github.com/javajosh/55339742aad2f1a1b881

Be sure also to check out Brian Goetz's excellent "Lambdas under the covers" talk, linked in the gist.

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

#170

Post by malkia »

qrmn wrote: post #167
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…

Fascinating insights. Lots of music on the PSX used a system like that, because that's a very natural fit for the PSX SPU. Tracker "modules" combine the sample data and tabulated sequencing data, but what you found more often on the PSX was separate sample wavetables and sequencing data closer to (i.e. literally converted from, and convertible back to) a MIDI format: it's smaller, timing-based, without all those pesk…

I don't rememmber a lot of it.

Konami were very late with delivering their (MTS?) system that was their audio/tasking thing, we were not given anything in advance. As such we've just found in the code where the samples and music had to be played, and as I've said above we "stole" (downloaded) the music data from the web-sites that had them (not sure how they've got all the effects, or it could be that we also found some waveforms in the source package).

I think at some point the "radio-codec" (okay, that's the actual Radio that Snake talks to the others) used this system - maybe a bit like fibers/threads, when a message comes, then switches. I'm not sure what exactly I did, and how much I understood it well (threads/fibers were not my thing back then... that much) but we've got it working.

Post reply on HN