Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (552)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  RAM size on consoles: How did they make those old awesome games?  (Read 1953 times)
0 Members and 1 Guest are viewing this topic.
Offline Cero
« Posted 2013-09-15 15:23:21 »

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

Offline sproingie

JGO Kernel


Medals: 202



« Reply #1 - Posted 2013-09-15 16:52:53 »

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.
Offline DrZoidberg

Senior Member


Medals: 15



« Reply #2 - Posted 2013-09-15 17:45:06 »

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.
https://www.youtube.com/watch?v=fe1-VVXIEh4
https://www.youtube.com/watch?v=9hLGvLvTs1w
http://1morecastle.com/2012/06/world-nes-homebrew-development/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #3 - Posted 2013-09-15 17:47:51 »

You should totally read this book:

http://mitpress.mit.edu/books/racing-beam

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Several Kilo-Bytes

Senior Member


Medals: 11



« Reply #4 - Posted 2013-09-15 18:30:56 »

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.)
Offline jonjava
« Reply #5 - Posted 2013-09-15 19:54:25 »

MissingNo.*

http://en.wikipedia.org/wiki/MissingNo.

Offline Cero
« Reply #6 - Posted 2013-09-15 23:29:10 »


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 :P

Offline ReBirth
« Reply #7 - Posted 2013-09-15 23:43:42 »

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.

Offline relminator
« Reply #8 - Posted 2013-09-16 02:37:48 »

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

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.

Samples for the ds here(opensourced)

www.rel.phatcode.net/index.php?action=contents&item=Projects

Space Impakto and Fuzed ds are all ds games that fit inside the 4mb barrier(no external files used).

I cannot put up a ps2 code here because it was a commercial game.
Offline CodeHead

JGO Knight


Medals: 41


From rags to riches...to rags.


« Reply #9 - Posted 2013-09-16 04:49:42 »

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 Tongue

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.

Arthur: Are all men from the future loud-mouthed braggarts?
Ash: Nope. Just me baby...Just me.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #10 - Posted 2013-09-16 05:20:08 »

SNES generation was almost all asm.  The N64 gen would have been mostly C.
Online SHC
« Reply #11 - Posted 2013-09-16 05:39:19 »

NES Games can be made with C.

http://shiru.untergrund.net/articles/programming_nes_games_in_c.htm

Offline Roquen
« Reply #12 - Posted 2013-09-16 07:25:21 »

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.
Online SHC
« Reply #13 - Posted 2013-09-16 07:29:03 »

@Roquen

Not as a reply to you. I just wanted to say that they can be made with C as well.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #14 - Posted 2013-09-16 08:46:09 »

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.

SCEE Liverpool?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline relminator
« Reply #15 - Posted 2013-09-16 13:25:29 »

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.

SCEE Liverpool?

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.  Smiley  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.

Offline lcass
« Reply #16 - Posted 2013-09-19 22:21:37 »

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.
Online SHC
« Reply #17 - Posted 2013-09-20 01:56:07 »

Maybe ram is sufficient since they used pixel graphics.

Offline EgonOlsen
« Reply #18 - Posted 2013-09-20 19:54:06 »

You should totally read this book:

http://mitpress.mit.edu/books/racing-beam

I second this. It's really worth reading if you are interested in ancient stuff.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (23 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (41 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!