Of course we know that consoles have little RAM sizes n stuff, even until PS3 with 512MB
The Atari 2600 had a ridiculous amount of 128 bytes.
NES had 2KB
SNES hab 128kb+
I dont really know what they did on SNES in term of programming language but I think it was already C at this point, whereas ATARI was definitely assembler and NES mostly assembler if I’m correct.
and then you have especially the PSone with 2MB system Ram and 1 MB GPU RAM…
How would you even get all that great shit in the RAM and onto the screen with those limitations ? textures and everything…
Are there like in depth interviews or documentation on how coding in the pre PS2 area was done ? =D
Lots and lots of very clever hacks. They were’t written like a Java 4K game where it’s a reductive process from the game you want to pack it in to the desired size, more an incremental process of starting with a few squares on the screen, vaguely arranged like your idea, then seeing what you can do with them from there. They took advantage of timing in ways we don’t think of now. An object (conceptually, no way it was OOP) could cease to exist once drawn, and you had til the next redraw to bring it back, so in the meantime, use the available RAM to do other things. That sort of craziness.
Most interesting Atari 2600 games had expansion RAM on the cartridge, but you’re talking about a few kilobytes maybe. “Textures” are a pretty recent luxury. Hand-drawn sprites were the rule before then.
In the 80s the 6502 processor was the most widely used in computers and consoles so you could look into programming that kind of system.
There is a ton of information out there.
e.g.
It goes into loads of gritty details of how games managed to squeeze out playable games on a tiny, tiny system. And it’s super readable too.
Also remember that a lot of older hardware (particularly 8-bit and 16-bit consoles) had chips designed to throw around game-like graphics. Tile maps and sprites were basically built-in, which saves a lot of memory and code size.
The missing no glitch as well as many other glitches in Pokemon Red and Blue are examples of how limited memory was utilized. The same space that was used in a battle might be used for something else in a menu or in the overworld. This was why using Escape Rope in the Safari Zone let you catch Pokemon exclusive to that area in the Cinnabar Island water. Variables were only properly initialized if you got to the island without flying or teleporting. Its also why missing no corrupted your hall of fame records, why glitch Pokemon depended on your name, and why it only worked if you didn’t surf to get to the island. Its also how you could catch Mew in game if you used a glitch while carrying a Pokemon with the right stats (or any other pokemon with different stats).
Variables were very tightly packed into memory. I don’t know if space was located manually or done algorithmically. (Modern compilers essentially do the same thing with algorithms called register allocation. The number of registers are limited (and are faster to access), the same way RAM was, even though there is lots of RAM now, so similar methods can be used to move the location of variables as needed. Luckily good compilers for good languages spare us from register allocation while also guaranteeing correctness.)
Yeah CCC videos are great and stuff.
But I would really like to see some people that ACTUALLY worked on games back then talk about it. Seems rare D:
In general programmer interviews like that are rare.
Thats why I love every talk John Carmack gives
I always blame OS for this. I think the games run on top of some kind of firmware or whatever in the lower layer of OS. Normal PC use OS that bloated with non-game related stuff. But ofc this is just my humble thought.
I’ve only coded for the ps2 and the ds. Much of what I coded for the ps2 was an octree based renderer for an f1 racing game in a now defunc outfit so not much knowledge there.
The ds(and gba) on the other hand, have a dedicated 2d engine and a 3d engine. It also has a vram you could use for both engines. On top of that they have an iwram for speedy functions.
They could also support a multitude of gfx and sound formats(all can be compressed) to minimize vram use.
For the ds you have 4mb for code and data but you have a facility to use a filesystem like nitro.
In the ps2 we used cg shaders(at least that’s what the sdk they sent me said) as fpr the ds it’s direct register access.
Have you tried browsing the free section of the GDC Vault? There are more than a few postmortems of classic games given by the original developer/members of the development team. Looking at the GDC 2011 content, there are listings for postmortems on Doom, Maniac Mansion, and other classic PC games. If you want console/arcade postmortems, that page also includes Marble Madness, Pac-Man, and Pitfall. The amount of technical talk varies by presenter, but they’re usually pretty informative and entertaining no matter what.
Considering you can fit a java VM in about 4K, you could write a NES game in java assuming you don’t create many objects. My comment wasn’t about what one could do, but about what was done.
Nah, that outfit was twice bigger that what I outsourced. Though I know someone named “Dan” who coded physics for their ps2 F1 game while he was there. assuming you’re referring to the former psygnosis.
You might have known him if you worked there.
I had an NDA when I worked on the render from my outfit(lots of devs went elsewhere and they needed help from outsourcing). The outfit did that job is quite closer to my country that the uk.
they focused on efficiency (from what i know , born in 1999 so i dont know too much)
only stored data that was essential the rest was all read of firmware written onto the card.
assuming you’re referring to the former psygnosis.