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

181–190 of 254 posts

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

#181

Post by akhilcacharya »

fra wrote: post #19
kayoone wrote: post #3

Pretty amazing what kind of skills game development required back then. One side of me is happy that we have all these great tools today, the other is sad because you hardly use this low level stuff in todays software development world. We are solving different problems today, but the level of software development skills required for a game that today could be done by a single person in Unity in a few weeks is quite…

Some day I will write a blog post about the tricks we have to pull off to fit all code & assets - or get animations running at 30FPS - on Pebble. Trust me when I say this: low level development is alive and well at hardware companies.

I talked to a Pebble firmware engineer at Bitcamp who told me about the hoops they had to go through. Really neat stuff.

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

#182

Post by codezero »

__z wrote: post #157
gergles wrote: post #116

Earlier quoted context omitted.

To read the rest of this comment, please log in or append a secret URL parameter to the URL.

What's the secret URL parameter?

?share=1, though it's not a secret, it was posted about when this change went in: https://blog.quora.com/Making-Sharing-Better

Then again, who's going to find that old blog post :P

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

#183

Post by __z »

codezero wrote: post #182
__z wrote: post #157

Earlier quoted context omitted.

What's the secret URL parameter?

?share=1, though it's not a secret, it was posted about when this change went in: https://blog.quora.com/Making-Sharing-Better Then again, who's going to find that old blog post :P

Thank you!!

(I figured out you don't have to pass anything specific into the share parameter, you can do "?share=poop" or even just "?share."

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

#184

Post by ryandrake »

gambiting wrote: post #75
brianwawok wrote: post #72

Earlier quoted context omitted.

Is there no standard? Like, if fps drops below 30 on a play through - red light and fix.

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…

That sounds like a very, very risky software development process. I think best practice is to make sure release builds are done and are used for testing from day one. QA doesn't test with all this debug code and debug overlays do they?

#ifdef DEBUG

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

#185

Post by yellowapple »

kayoone wrote: post #127
spatulon wrote: post #39

Earlier quoted context omitted.

Yes, the PS1's 2MB of RAM are pretty generous compared to some embedded platforms. A typical engine controller ECU in a car might have 256KB of RAM (and maybe 2-4MB of flash).

but you usually don't stuff 3d models and textures in an engine controller ECU ;)

Not with that attitude you don't :)

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

#186

Post by derefr »

cnvogel wrote: post #56
listic wrote: post #51

I wonder if anyone controls the physical layout of bytes on the disk, at least for things like installing large software packages on an HDD, or a major release of an operating system on a DVD. It doesn't look likely: every time I install Ubuntu, I feel the process could be made much faster.

At least for Windows there's now a way to install the OS so that it only occupies one continuous large filesystem image with the compressed install files, and only stores the changes to this frozen filesystem images in the "traditional" way. It's called "wimboot". http://labalec.fr/erwan/?p=1078 That way installing the OS mainy consists of copying this huge image file, hence the "physical layout of bytes on the disk"…

That's effectively how CoreOS works.

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

#187

Post by bentcorner »

Cthulhu_ wrote: post #136
timboslice wrote: post #101

Earlier quoted context omitted.

This is why we see all these Early Access games that run like garbage. They are still in the develop new features and fix bugs phase, and have not yet gotten to the optimization/strip out debug code phase.

And yet, I wonder if they couldn't release a production build without all that (maybe crash handling/reporting). Early access games are what agile development is to software - or should be. Going to production several times a day without giving up on the application's performance, and such. Early access game devs pushing unoptimized releases should set up their release system betterer.

This exactly - no reason why you couldn't ifdef everything that is debug only, if your team is consistent with it from the very start.

Backfilling existing code with ifdefs and dealing with compile breaks and other more weird things can be intimidating, time consuming, with hard to define ROI, so I can empathize if someone doesn't do it.

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

#188

Post by malkia »

Retra wrote: post #180
wnevets wrote: post #165

Earlier quoted context omitted.

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

That's one of the appeals of classic 8-bit-style artwork: characters features are so poorly defined that it's easy for the player to mentally substitute their own perspective for the character's. (The character is essentially imagined to feel how you feel.) This can give the character a kind of 'charm' that hi res doesn't really do.

The art in the games of Bitmap Brothers, and many other games - Star Control I/II, Heroes of Might and Magic I, II & III (all with different styles), the grotesque gothic view of Disciples ][ (beautiful!) and plenty of other 2D games.

For anyone that enjoys it, here is some great art done with 8-bit palette cycling (cylcing dozen or more colors to achieve animation) - http://www.effectgames.com/demos/canvascycle/ - (select other bitmaps too)

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

#189

Post by yellowapple »

Cthulhu_ wrote: post #76
listic wrote: post #51

I wonder if anyone controls the physical layout of bytes on the disk, at least for things like installing large software packages on an HDD, or a major release of an operating system on a DVD. It doesn't look likely: every time I install Ubuntu, I feel the process could be made much faster.

Do you still use a CD / DVD to install your OS? That's probably the problem right there; CD's/DVD's are relatively slow. Go for an install off a flash disk (where physical layout shouldn't matter), and / or a web install where only the relevant software compiled for your hardware is downloaded.

CDs/DVDs don't have to be slow (or at least not as slow as they typically are). Most speed problems are the same speed problems one encounters with spinny / non-SSD hard drives: namely, that data isn't sequential, requiring a lot of skipping around the disk in order to piece together files.

Web installs are also much slower unless you have a reliable internet connection (which is not a given). Installing from a USB stick (preferably of the 3.0 variety in a 3.0 port) is indeed the best option for all but the oldest of machines (in which case you'll need a boot floppy to start the machine up with a bootloader capable of initializing the boot medium (USB, CD/DVD/BD, network) and booting from it).

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

#190

Post by codesushi42 »

pjmlp wrote: post #48
codesushi42 wrote: post #24

Earlier quoted context omitted.

> I am quite sure there are other contenders like home grown engines, LibGDX, Marmalade, Cocos (all variants), SDL, MonoGame, DirectXTK, Project Anarchy , Apple own Scenekit and SpriteKit,... It doesn't matter how many frameworks are out there. If you hang around the game dev scene long enough, you'll see that most small devs are using Unity, and if not that, Cocos2DX. Just head over to Gamasutra, /r/gamedev, or brow…

> It doesn't matter how many frameworks are out there. .... Former IGDA member, Gamasutra subscriber and GDCE attendee here, hence why I asked for numbers. > Reducing package size isn't really comparable to writing portions of your game in assembler. I don't consider that low level coding or pushing hardware limits. It is not, but the goal of fitting as much code as possible in small packages is.

> Former IGDA member, Gamasutra subscriber and GDCE attendee here, hence why I asked for numbers.

Maybe "former" is why. There are no numbers published to confirm or deny. It's apparent if you keep up with the community and ask developers what they use.

> It is not, but the goal of fitting as much code as possible in small packages is.

You're really talking about reducing sizes of assets & included libs. That has more to do with optimizing DL time than hardware performance, and nothing to do with low level coding where you're writing machine instructions without touching a higher level of abstraction. Not the same at all.

Post reply on HN