It is currently Sun Dec 10, 2017 10:43 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 62 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Mon Nov 20, 2017 12:37 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7312
Location: Chexbres, VD, Switzerland
Commodore 64's hardware is definitely neither supperior nor inferior, but was designed with a very different philosophy.

- Graphics have less colours, but they're not fully saturated
- Horizontal resolution is typically sacrified for more colours -> non square pixel aspect ration
- There's much, much more RAM
- CPU is about twice slower (as the bus is shared with the video chip).
- Less sound channels (3 instead of 4), but those are much more powerful than NES' sound channels
- If more than 8 sprites are needed, software multiplexing must be used, but sprites are much bigger and usually metasprites aren't required.
- Typically jostick with single button are used, which is inferior to NES' joypad, but the keyboard is available if more buttons are needed.

So while the C64 is "mostly" inferior to the NES in some points (sound, RAM) it shines.


Top
 Profile  
 
PostPosted: Mon Nov 20, 2017 3:21 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1508
Bregalad wrote:
So while the C64 is "mostly" inferior to the NES in some points (sound, RAM) it shines.

Well, RAM was a necessity because you cannot run a game directly from disk, so all of its program code has to go into RAM first.
So, it's not really that much of an advantage over the NES, is it?

Besides, did anybody ever actually run out of RAM space on the NES? You have 2048 bytes (minus 256 for sprites). This should be more than enough for every game.

I'm working on a full-blown "Zelda"-like adventure game and my only worries regarding RAM is whether I can manage to put all variables in zeropage (except for some huge arrays). But I think I will never ever run out of regular RAM space, even if we ignore the additional 8 KB of battery RAM.


So, the only real advantage of the C64 over the NES seems to be the sound chip.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Mon Nov 20, 2017 5:12 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
DRW wrote:
Well, RAM was a necessity because you cannot run a game directly from disk, so all of its program code has to go into RAM first.
So, it's not really that much of an advantage over the NES, is it?

It's hard to pick a winner here... It's true that 64KB of RAM is a lot, and even when most of it is used for code and data, significantly more than 2KB should still be left for general use. On the other hand, since the NES runs games directly from ROM, you can have almost instant access to more than 64KB of code and data through bankswitching, and cartridges can easily pack extra RAM to compensate for those 2KB. However, AFAIK, the Commodore 64 can also use cartridges, in which case it could probably have these advantages too.

Quote:
Besides, did anybody ever actually run out of RAM space on the NES? You have 2048 bytes (minus 256 for sprites). This should be more than enough for every game.

That's... very optimistic of you. We know for sure that several developers back in the day felt like they needed extra RAM on the cartridge, not only the ones that needed battery backup. Sometimes the extra RAM may not be necessary, but it certainly makes things easier/faster. It's definitely easier to have unrestricted access to an entire level map in RAM than decode it on the fly from ROM and "patch" any changes they might have suffered in real-time. 2048 bytes is far from excessive if we're talking about 16-bit-type games. Varied enemies with complex behavior in large levels can quickly consume a lot of RAM. I particularly find it very fun to try and map all the functionality of 16-bit games to the constraints of the NES, and IMO, most of the time it can indeed be done, you just end up with a more complex program than if you had all the space in the world.

Quote:
I'm working on a full-blown "Zelda"-like adventure game

The original Zelda is a pretty early NES game, and the screen-by-screen gameplay is definitely a RAM saver. In my experience, the biggest RAM killers are level maps and objects, and neither of those are particularly troublesome if the map in question is only 1 screen large and all the objects are the ones inside it.


Last edited by tokumaru on Mon Nov 20, 2017 5:15 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Nov 20, 2017 5:13 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19322
Location: NE Indiana, USA (NTSC)
DRW wrote:
Besides, did anybody ever actually run out of RAM space on the NES? You have 2048 bytes (minus 256 for sprites). This should be more than enough for every game.

Good luck doing a finely destructible and backtrackable map the size of a Super Mario Bros. 3 level without extra work RAM in the Game Pak. For instance, an article by the programmers of M.C. Kids explains that without work RAM, the game might have needed smaller levels, possibly coarser destructibility, and certainly more programming complexity. Something like SimCity would be right out, as the prototype appears to need more than 32K of RAM: some for work RAM and some for save. The game's map alone is 120x100 spaces.


Top
 Profile  
 
PostPosted: Mon Nov 20, 2017 5:28 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
tepples wrote:
Good luck doing a finely destructible and backtrackable map the size of a Super Mario Bros. 3 level without extra work RAM in the Game Pak.

Do you really need the entire map to be destructible, though? Most games don't. If you have up to 1.024 blocks (that's over 4 full screens worth of 16x16-pixel breakable blocks) you can save their existence state in 128 bytes, 1 bit per block. That does increase the complexity of the program though, because you have to treat breakable blocks as objects, and patch the level map cache accordingly, but it's doable. One advantage of treating breakable blocks as objects is that you can have complex backgrounds behind them, since the level maps are "clean" of breakable stuff.


Top
 Profile  
 
PostPosted: Mon Nov 20, 2017 7:11 pm 
Online
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 296
Location: Hong Kong
Well. Simcity. Just Simcity. I bet the mandatory extra RAM added to the manufacture cost was one main reason the NES/Famicom of it got canceled.


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 12:32 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7312
Location: Chexbres, VD, Switzerland
DRW wrote:
So, the only real advantage of the C64 over the NES seems to be the sound chip.

And even then, we could agree that 4 channels is better than 3, no matter how featured they are, since it allows for significantly more harmonic/rythm without resorting to annoying arpeggios. Also the individual C64 channels officially doesn't have direct volume control (but with a trick they can have it).


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 2:13 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1114
Location: Gothenburg, Sweden
If you max out (and you're likely to), 4 is definitely more than 3. But at the same time considering the SID chip was much more flexible on what each channel could do (change roles, have a filter), you could make an interesting, varied and illustrative soundtrack in ways you can't on the nes. You're more likely to use two channels in order to sound like one more complex channel here and there on the NES, too.

One example of the SID being more "Illustrative" would be comparing the "scream" effects in the intro song to ghouls n ghosts (c64) to Shadax' scream in Solstice (NES), both by the same artist (uh, couldn't find an example of someone losing a life on youtube... oh well).

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 2:21 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 916
Location: Sweden
Home computers costed more than home consoles though, so they could afford to have more RAM. Or is there are reason why computers needs lots of RAM besides for disk loading (FDS only has 32 kB PRG-RAM and 8 kB CHR-RAM)? I'd think (arcade) games would be the most hardware demanding programs for a computer.
Nintendo wanted to make a home version of their arcade machines but that didn't cost as much so I guess they needed to cut down on things like RAM and colours.


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 2:43 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1114
Location: Gothenburg, Sweden
Besides the disk/tape loading, I guess the answer is BASIC-dependent software and GEOS (optional but popular).

Plus it's not just games. A fullblown graphics editor etc etc might eat more "work" RAM than your average game.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 2:52 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1114
Location: Gothenburg, Sweden
Oh, and SID having proper hardware accelerated ADSR envelopes both helps the composer out a lot and would burden any music driver less.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 3:43 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 596
DRW wrote:
Besides, did anybody ever actually run out of RAM space on the NES? You have 2048 bytes (minus 256 for sprites). This should be more than enough for every game.

All the time. Sprites take 256 bytes. ZP takes 256 bytes. Stack + famitone take 256 bytes. Then you should leave space for cc65's stack, let's say 64 bytes. Down to 1216 bytes before any of your own things.


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 5:25 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1864
Location: DIGDUG
cc65's stack.

If you program like me, with all globals, no recursion, and only occasionally passing more than 1 variable to functions... (Like my jammin honey game)...

I have only 16 bytes reserved for the c stack. It gets used mostly for the metasprite function that Shiru wrote.

However.

My Vigilante Ninja 2 game completely ran out of RAM space. There was only a few dozen left on the 2 pages used for level data, but due to a bug, this was unusable, because if you jumped into the top of the screen it would occasionally check those bytes for collision, even though they aren't properly level data.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 7:08 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19322
Location: NE Indiana, USA (NTSC)
calima wrote:
Sprites take 256 bytes. ZP takes 256 bytes. Stack + famitone take 256 bytes. Then you should leave space for cc65's stack, let's say 64 bytes. Down to 1216 bytes before any of your own things.

I'd add about 128 bytes for a video memory transfer buffer. But I'd dispute the "ZP", as a lot of "your own things" can go there.


Top
 Profile  
 
PostPosted: Tue Nov 21, 2017 9:32 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
I normally use 212 or so bytes of page 1 as my VRAM transfer buffer, the rest goes to the stack. I may use more than that in programs with less traditional graphics engines (e.g. a raycaster).

ZP is indeed mostly for our own stuff... I try to put all my variables there, while arrays and a few of the less frequently used variables occupying the remaining pages.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 62 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Memblers and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group