Jump to content
  • Advertisement
Sign in to follow this  
GnuVince

What were SNES games programmed in?

This topic is 4894 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Guest Anonymous Poster
There's some info and tutorials in the Super NES Programming wikibook.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Quote:
Original post by Anonymous Poster
Yup, snes games were coded in pure assembly.

The reason why snes could still do so nice graphics, despite the weak cpu, is the sweet 2D graphics chip allowing for a lot of cool effects with clever coding.

True dat. Then, of course, there were those enhanced cartridges which granted some games even greater graphics capabilities, such as true 3D.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravyne
Also, while we tend to think of things like ASM as being instruction-level languages, theres no reason that an assembler can't impliment some higher-level constructs such as functions and loops. These systems are called high-level assemblers(also: Macro Assemblers.)


Yeah, you can probably implement those in Assembler, but the logic of the game remains hidden behind all these MOV, ADD, JMP, etc. With a language that's higher level, like C or Forth already mentionned, you can talk about the elements of the games (NPC's, items, enemies, etc.) with words that make sense. That's why I'm so impressed that among all these instructions, the programmers were able to keep track of the game.

Share this post


Link to post
Share on other sites
I don't see how
move_and_draw_player(3,43);

function move_and_draw_player(dx, dy) {
player_x += player_dx;
player_y += player_dy;
draw_player_sprite(player_x, player_y);
}
is really any different in terms of "remembering" as

ld b,3
ld c,43
call move_and_draw_player

move_and_draw_player:
ld a,(player_x)
add a,b
ld (player_x),a
ld b,a
ld a,(player_y)
add a,c
ld (player_y),a
call draw_player_sprite ; Assumes routine takes b,a as args
ret
Just because it's assembly doesn't mean you can't use sensible variable names and routine names! Structured code in ASM is entirely possible, and if anything more important than in other languages where you need to be able to keep track easily.
Unless you mean an object-orientated system, which is easy enough to implement through arrays and such.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
A fair few well built Macros helped me in my Snes coding days, arr fun days, dug out my source code to Street Racer to remind myself what it was like. Mode 7 was very cool indeed :)

Share this post


Link to post
Share on other sites
I'm pretty sure that spec is for the original Nintendo. Genesis had a combination of a Z-80 and a 68000. A CPU speed of 3.52 MHz suggests likely an Intel 8088 or something along those lines, and the 68000 kicked the ass of that (and Genesis wasn't that much ahead of SNES AFAIK) - ran 7.83 MHz IIRC and was more bang for the buck - er, clock cycle - besides. (I should know, I grew up on the Macs running 68000s :) )

But anyway. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
I'm pretty sure that spec is for the original Nintendo. Genesis had a combination of a Z-80 and a 68000. A CPU speed of 3.52 MHz suggests likely an Intel 8088 or something along those lines, and the 68000 kicked the ass of that (and Genesis wasn't that much ahead of SNES AFAIK) - ran 7.83 MHz IIRC and was more bang for the buck - er, clock cycle - besides. (I should know, I grew up on the Macs running 68000s :) )
Nope, it was 'only' a 3.52 MHz system, though some games with slow rom chips only ran at about 2 MHz instead. The original NES ran at about 1.78 MHz (I should know, I'm currently coding for it).
There's a big difference between the RISC-like 6502 (65816 in this case) and a 68000 though. Most 68000 took between 4-20 cycles to execute while the 6502 could handle them in about 2-7 instead.

Share this post


Link to post
Share on other sites
Quote:
Original post by doynax
There's a big difference between the RISC-like 6502 (65816 in this case) and a 68000 though. Most 68000 took between 4-20 cycles to execute while the 6502 could handle them in about 2-7 instead.


I don't know if its accurate to call the 65816 'risc-like' If I remember correctly It supported memory modes not usually associated with a risc system, also it only had a couple general purpose regs. It only really seems to hold the risc ideal in that it basically executed 'simple' instructions quickly. The 68000, on the other hand, has 16 registers and IIRC, was closer to the classic risc load-store ideal. On the other hand, as you stated, cycle times were quite long for a risc system.

In the end its probably a wash as to which system is more or less RISC. Suffice it to say that they were probably equally powerful, give or take. What really set the SNES apart from the Genesis, was the GPU and sound quality of the SNES.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!