81–90 of 254 posts
> Ultimately Crash fit into the PS1's memory with 4 bytes to spare. Yes, 4 bytes out of 2097152. Good times Wow. Just wow. One can only imagine the amount of hard work and sweat that was put into making this possible. And the pride of developers when it actually worked and the game has become a success. Great story.
Earlier quoted context omitted.
That's not really the same though. You are not really limited by RAM in most cases, also you are not limited by slow storage media like CD/DVDs as it was/is with most of the consoles. The reality is, hardly anyone on mobile writes their own engines (a part from some of the big players) because it's just too much of an investment and Unity (or one of the other popular engines) is well optimized and allows much faster…
It's the same. All iOS devices except the iPad Air 2 have less than 2GB RAM (most 512 MB). Android 1-4 devices have often less than 1GB RAM. It's common that only 1-3 apps can stay in RAM depending on the platform and the apps memory usage (foreground apps, not background services). Applications/games in the Win95/PS1/N64 era were coded a lot more efficient. Back than, a common Win95a PC had 4-8MB RAM, (highend was 3…
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.
> Ultimately Crash fit into the PS1's memory with 4 bytes to spare. Yes, 4 bytes out of 2097152. Good times Wow. Just wow. One can only imagine the amount of hard work and sweat that was put into making this possible. And the pride of developers when it actually worked and the game has become a success. Great story.
Some of the developers nowadays need to take clues from these guys.
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"…
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…
" the other is sad because you hardly use this low level stuff in todays software development world." I don't think there is a dichtomy. It's always about smartly leveraging available resources. The problem with modern development perhaps is then that there are these tempting high level orthodoxies that often obscure the core matter at hand. Ie. focusing on some pointless candied abstract object interface rather than…
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"…
We were installing into standard hardware so it was pretty good. But if your hardware varies this approach isn't great.
We could also have created a fresh filesystem on the device and untarred into it but we wanted to keep se Linux attributes.
> 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.
If you haven't read the "Making Crash Bandicoot" blogposts, you're in for a treat. http://all-things-andy-gavin.com/2011/02/02/making-crash-ban...
If you haven't read the "Making Crash Bandicoot" blogposts, you're in for a treat. http://all-things-andy-gavin.com/2011/02/02/making-crash-ban...
It's interesting that they were concerned with dizziness and the camera, concerns which seem to have unfortunately evaporated in most 3d games made since, to their detriment.
> 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.