Were Super Nintendo games written in compile?

Because if they are, that would explain all the ridiculous slowdowns they have in some of the games. Think about this, Snes runs at 3.58 Megahertz, mega means million, and everyone knows million is a gianormous number. All 65816 opcodes are between 2 and 7 cycles, and games mostly use very simple arithmatic in them. An object moving consistantly in a straight line only requires adding a constant to the cooridinates. Jumping only requires subtracting a constant from a variable and adding the variable to the y-coordinate. And things like setting up the graphics only require simple load 'n' store opcodes to do. This is why I doubt Super Nintendo games were programmed in assembly, because if they were done in assembly they would have been way more optimized then they were. They must have been done in compile instead. I could go into more detail about cycles and opcodes if you'd like to further explain my point.

Snes games were programmed in Assembly. The Snes CPU isn't all that fast, as has been mentioned on this forum recently, the choice of CPU came about because of planned Nes compatability and wasn't the greatest choice. "compile" isn't a programming language itself, high level languages like C need to be compiled into machine code - ones and zeros.

You seem to know a fair bit of theory, but have you put it into practise and actually assembled code and run it yet?

Quote:

---

Originally Posted by playgen

Snes games were programmed in Assembly. The Snes CPU isn't all that fast, as has been mentioned on this forum recently, the choice of CPU came about because of planned Nes compatability and wasn't the greatest choice. "compile" isn't a programming language itself, high level languages like C need to be compiled into machine code - ones and zeros.

You seem to know a fair bit of theory, but have you put it into practise and actually assembled code and run it yet?

---

Yes, it just takes a really long time to make a game.

I make up my own assembly codes for stuff like collision detection when I'm bored. The only problem is that I have to do all this other stuff like drawing graphics before I can make a ROM of something.

You write code, and have no idea if it works or not (you don't know how to make a ROM, thus you can't see if it works or not, at least that is the idea I've got)...

Usually stuff written in assembly won't work on the first try :) I did once wrote a bit over 100 lines of Z80 code and it worked on the first try with intended results :cool:

Sorry, but I don't care about being politically correct.

I'm just asking how it could take a thousand cycles to add two bytes together if every adding opcode is 2 or 3 cycles.

And I'm busy drawing graphics now for my demo, please give me time!

the game is not just adding things together... there's whole bunch of other things to besides moving sprites... such as updating pattern tables, decompression of level and graphics data etc...

A lot of SNES games ran in 2.68mhz with for slower rom (carts). Only games that used faster rom could clock up to 3.58mhz. Even then, instructions that had operand source/destination in the work ram ran slight slower than 3.58mhz. 16bit LDA $xxxx is 5.667 instead of 5 cycles @ 3.58mhz, *if* $xxxx is work ram address. That's about 3.158mhz in speed. Not a huge different, but a difference none the less and it depends on the operands source/destination. It's pretty common to load and store variables in ram, so you can see where this is leading. A good snes cpu doc shows the opcodes in master cycles.

TmEE's right. There's a lot of other code running in a single frame's worth of cycles than one tends to think about. And lot of games use elaborate script engine which aren't always optimized to great levels. Speed is usually sacrificed in the favor of development time. Even Genesis games, with its higher clock speed, still slow down when you'd think they shouldn't. The slowdown in TF4 for example. You'd think you were playing a SNES shooter. There were some earlier games that had slowdown too.

The 65816 requires a lot of hand optimization if it's going to be comparable with a 68k system at twice the clock rate. The saving grace of the 65816 is it's fast opcode cycle times. Too bad 'work ram' brings those down some.

It's funny though, *thee* special effect on the SNES was when it didn't slowdown with a lot of action on screen. For all its eye candy. Haha. Surprised Rendering Rangers hasn't come up as a good example for snes.

I didn't know the RAM slowed it down on some of the opcodes. Maybe some programmers strategically timed their compression schemes to just make it into the frame, but got screwed over by not knowing about the slightly slower opcodes.

What is a script engine?

Were there any games that completely skipped decompression to maintain highspeeds? Did not using compression have a big (noticeable in gameplay) effect on the amount of sprite data? I'm guessing if you use too much compression you could end up having less frames than an uncompressed game because your limited by the RAM size, unlike raw data that can be pushed out of the ROM whenever you want.

Yeah, makes you wonder what the hell Nintendo was thinking on that one? But then again, it kinda goes with my and others suspicion: Considering the FC was released in '83, the SFC probably started development in 85. The way how some of the sPPU(not to mention there's two PPUs) hardware appears a lot like a patch work of last minute addons. The registers mapped to almost the same area as the FC, etc. The sCPU can operate in 8bit mode with ease as well. I wouldn't be surprised that they started with a custom 8bit 65x. Makes you wonder what kind of effect the MD might have had on SFC development changes.

A script engine is an interpreter. Some are complicated and some are less so. The CPU runs the interpreter, the interpreter runs the game script. One reason is that hardcoding levels and such is a pain, tedious, lengthy, and harder to debug. You can have one single script engine run everything(like SCUMM), or multiple ones running different tasks, with the main logic hard coded - etc.

The SNES 128k work ram is fairly decent in size considering the time. I'd imagine most of the frames gfx/frames/tiles are decompressed before the level/area starts. Tilemaps are usually compressed with RLE - so it's possible to decompress 'strips' at a time to ram and DMA the small update. SNES also have this funny hardware decompression(sPPU). It'll take 3bit tiles and expand them to 4bit on the fly. Free decompression with a 25% static savings - not bad. Doesn't require any ram and there's no overhead as long as a large group of tiles are 3bit mode.

LZSS is still a bit resource intensive to decompress. A lot of SNES games use it though. But something like a shooter that's 'constantly' scrolling, could possibly decompress sets of enemies & frames in advance for near future use, as the script engine would trigger without pausing the system. I've seen this in Gate of Thunder and Lords of Thunder, and some other shooters. I'm sure other shooter engines do this. I have seen instances where speed sensitive graphics are left uncompressed.

SNES games were written by children.

In 65816 assembly, I find 8-bit mode more useful most of the time. I don't like that extra cycle opcodes have in 16-bit mode. The only time 16-bit mode is better is on parts where you use a lot of numbers that are larger than 256, but there is still a lot of things you can do with just 8-bits. I also like Direct Page addressing better than Absolute addressing for similar reasons.

3 bit tile mode? What bits do you press?

I hate 8-bits... I am very spoiled by 68K... I begin to hate all CPUs with less than 8 registers, and which don't have registers that can be grouped to 16-bit or more. Z80 is really on the edge, its fun and pain at the same time, and my sound engine is my last 8-bit CPU program... 3000 lines (and growing) of mind-numbing-very-highly-optimized-not-so-well-commented Z80 assembly...
I like convenience over cycle counts... once I have a nicely working thing, then I can start worrying about cycles.

Quote:

---

Originally Posted by TmEE

I hate 8-bits... I am very spoiled by 68K... I begin to hate all CPUs with less than 8 registers, and which don't have registers that can be grouped to 16-bit or more. Z80 is really on the edge, its fun and pain at the same time, and my sound engine is my last 8-bit CPU program... 3000 lines (and growing) of mind-numbing-very-highly-optimized-not-so-well-commented Z80 assembly...
I like convenience over cycle counts... once I have a nicely working thing, then I can start worrying about cycles.

---

You're definitely a 68k kind of programmer ;)

Z80 is nice and easy to code for in comparison to the 6809 and 65x. Optimizing for it isn't as fun as the two others nor is it as effective and the slow cycle times are a killer(read: not good). Because of the really low cycle times, the 6809/65x have some really insane optimizations. Writing self modifying code is my favorite. Code lists are becoming my second love. I loooove coding on the 6809/65x and optimizing for 8bit elements :D

dragonboy: Definitely! Dropping into 8bit mode whenever is a great option to have. You just have to be careful about handling opcodes immediate with data, i.e. make sure you're in 8bit mode when using opcodes with 8bit operand and vice versa. Otherwise it will misinterpret the next operand as an instruction and the code will crash in one way or another. Dropping into 8bit mode and setting up some self modifying code would be a real nice optimization. 8bit mode is faster for self modifying code VS 16bit mode because of the bus being 8bit. But even in 16bit mode, you've got 0.7 MIPS (low average) vs Genesis 0.95 MIPS(high average). Not bad for a processor at under half the frequency.

As for the settings to decompress 3bit to 4bit tiles, it's on the sPPU side for the DMA. I forget the details. I'll look at my docs again.

Quote:

---

Originally Posted by tomaitheous

You're definitely a 68k kind of programmer ;)

Z80 is nice and easy to code for in comparison to the 6809 and 65x. Optimizing for it isn't as fun as the two others nor is it as effective and the slow cycle times are a killer(read: not good). Because of the really low cycle times, the 6809/65x have some really insane optimizations. Writing self modifying code is my favorite. Code lists are becoming my second love. I loooove coding on the 6809/65x and optimizing for 8bit elements :D

---

I had tons of fun with accidental self modifying code in my sound engine ;) I lead me to three major rewrites of some part of the code... you gotta love memory corruption bugs :P

Thankyou guys, I finally know what really is causing the slowdowns.

Now, why were there only like 1 out of 100 games of the Super Nintendo that had fully optimized programming, where as almost every other Sega Genesis game was fully optimized?

Quote:

---

Originally Posted by dragonboy

Thankyou guys, I finally know what really is causing the slowdowns.

Now, why were there only like 1 out of 100 games of the Super Nintendo that had fully optimized programming, where as almost every other Sega Genesis game was fully optimized?

---

ahhemmm. Asked a question? Anyone know the answer?

Quote:

---

Originally Posted by dragonboy

ahhemmm. Asked a question? Anyone know the answer?

---

BLAST PROCESSING!

I looked up script-engines to learn more about them, and I found an interesting artical interviewing some guy who worked on Secrets of Evermore. He was explaining how the game was made and it was really interesting. He said he used some Square Enix tile mapping program, and a specialized RPG high-level language.

So now I know more about script-engines, I don't think 65816 would be very good at it because of it's weird instruction set and weird addressing modes. The 65816 needs a human to pull his hair out fixing every little piece of code, to reach it's full potential. The 68000 seems like it would be better at it because it's opcodes make more sense.

Quote:

---

Originally Posted by dragonboy

I don't think 65816 would be very good at it because of it's weird instruction set and weird addressing modes. The 65816 needs a human to pull his hair out fixing every little piece of code, to reach it's full potential. The 68000 seems like it would be better at it because it's opcodes make more sense.

---

The level of the script language plays a large roll in its performance. Yeah - I'd say in general though, the 68k lends itself better at interpreted and high level languages. The 65816 has a simpler instruction set and faster instruction execution times, but the code is more complex when optimized and has to be more specialized/specific. The 68k is easy to code for, has a great instruction set, a real set of registers, additional addressing modes, and linear address range. The 65x and '816 are fast when hand optimized for specific situations. The C64 1mhz 65c02 has done some amazing things. Guess those coders never made it to the SNES? <_<

Sort of irrelevant, but the 65x and '816 CPUs were hardwired for the instruction sets. Similar to RISC that came afterwards - simple instruction set, hardcoded for fast instruction times, small dye size. The 68k is microcoded and the memory access is slower - but a bigger/complex instruction set to make up for it. If the original 68k had 1cycle memory access like the WDC chips instead of 4, it would have been insanely fast (and more expensive).

I find Snes games to be really depressing, how badly written their code was.:(

I also don't like Snes's reputation of having a cpu that is "horrendously underpowered." If I was the guy in the programmer's chair, I would have never left a game without hand-optimizing it to perfection, especially for a system with this kind of reputation.:(

I'm understanding this stuff, but it will always be depressing for me. So many people on the internet always overstates how underpowered Snes's cpu, and it really hurts my feelings.:(




Irrelevant, but why was it so hard for people to get the third background layer running? I mean, it's the same thing as the other 2, you just do the same thing 3 times instead of twice? The only difference was the third layer was limited to less colors than the other two were.

Quote:

---

Originally Posted by dragonboy

I find Snes games to be really depressing, how badly written their code was.:(

I also don't like Snes's reputation of having a cpu that is "horrendously underpowered." If I was the guy in the programmer's chair, I would have never left a game without hand-optimizing it to perfection, especially for a system with this kind of reputation.:(

I'm understanding this stuff, but it will always be depressing for me. So many people on the internet always overstates how underpowered Snes's cpu, and it really hurts my feelings.:(

---

There are lots of ignorant people on the internet. And if try to show some facts, they'll just shrug their shoulders and won't care - keep on believing what they believe because it's easier or it's a matter of pride. For extreme Genesis/Megadrive fanboys - the cpu speed was the one thing their system still had over the SNES. That's a very important fact to them.

For most snes nerds, it doesn't bother them as much. Sure games slowed down (some much more than others), but visually the system was amazing and the sound was awesome. The other advantages over rule the cpu speed difference. The trend I see the most, is that fanboys got their systems from "pre-teen" and younger. It was very personal. I'm sure Sega and Nintendo were laughing all the way to the bank ;)

It's funny 'cause what really mattered in the end were the games. Was it fun to play or were you just worried about what kind of effects it had? SNES had some fun/great games, but Sega fanboys won't "see" that - and vice versa with the snerds (snes nerds). Being a fanboy and having a favorite among your systems - is not the same thing.

Quote:

---

Irrelevant, but why was it so hard for people to get the third background layer running? I mean, it's the same thing as the other 2, you just do the same thing 3 times instead of twice? The only difference was the third layer was limited to less colors than the other two were.

---

Mainly because it wasn't needed. A good game doesn't need huge amount of scrolls. Matter of fact, multiple scrolls were waaaay over used on the 16bit era - especially on the Genesis/Megadrive. The Genesis didn't have a huge palette or lots of on screen colors, scaling, rotation, transparency like the SNES - so they pushed the scroll effect. You can see that when the SNES came out, the multiple scroll effects used in Genesis games seem to sky rocket. You could be in a small cave or room and there would be at least 2 BG layers scrolling - wtf? Thank god some of the newer 2D games have scaled this back. I was playing both the DS Castlevania games and immediately noticed quite a few areas had a single scroll even though the system push 2D like nobody's business. Same with sprites. Those games have great production value and know the place and time for such effects.

That 3rd layer on the SNES would make a great stats overlay window - either eliminating flicker or still have access to a 2 layer BG.

Yeah, it was kind of annoying at seeing the overuse of parallax in some Genesis games.

Maybe it's just that I've got bored of all the classic Snes game from playing them so much, then got interested in action games, and realized the Snes didn't have very many good ones. Back when I was little I had both a Super Nintendo and a Sega Genesis. Both broke. A four years ago my family was packing up to move to our new house and I found the old Super Nintendo in the basement. I noticed the "Nintendo repair" sticker on the back. Called the phone-number, and they repaired my console.

The games were fun to play again. I then found some old Snes games at a second hand store, and bought the ones I remember renting often. One time I asked for a Kirby game for Christmas, but my sister couldn't find any Kirby at the second hand store, so she gave me a Star Wars game. I didn't touch the Star Wars game until a few years later.

After playing beating every game several times, the games got very boring and repetative. I became interested in action games. I tried the Star Wars game for the first time and what happened? Slowdown! The very first time I had EVER saw an Snes game slowdown in my whole entire life. I always thought those little parts of SMW and DKC where it shows one or two frames for a slightly longer time than usual, when there was like a gazillion koopas or kremblens flying onscreen, a slowdown. Man, was I wrong! This Super Starwars slowsdown even when there is ONE enemy onscreen! Was all 3rd party games this badly made????!!! I mean I always thought slowdowns were the helpful "Matrix" moves. The slowdowns in Super Starwars: Empire Strikes Back, the picture not only slowsdown, the control get delayed also. If the only games on the system are classic 1st-party games I've played to death, RPGs, and games that slowdown with one onscreen enemy, than what a boring system for me.

Please tell me Super Starwars was the very worst game? I can't imagine any game more slow and depressing as that. I wouldn't be so upset about slowdown if I thought people were talking about those "99 enimies, half second long, matrix-moves" slowdowns that I was used to before I played Starwars: Empire Strikes Back.

Quote:

---

Originally Posted by Aarzak

Yeah, it was kind of annoying at seeing the overuse of parallax in some Genesis games.

---

I've always noticed, whenever a Super Nintendo game had parallax, it always looked more natural and less artificial than parallax on the Genesis. A few years ago I got an "arcade legends tv plug 'n' play" game that had Sonic 1 on it, and I noticed after like 2 minutes the parallax never scrolls up or down, while games on the Snes that had parallax layer, they usually scrolled up and down as easily as left and right.

Haha yeah, when the snes slowed down... it reallly slowed down. But yeah, a lot of the early games had slowdown problems. It's understandable when there's quite of enemies onscreen, but when there's only a few? That's when you get suspicious. A lot of the early games were bad programming + slow rom mode (2.68 MHz). Later games still had some slowdown in some parts, but it was much more reasonable.

I think Gradius 3 might be the king of slowdown on the snes. Heh - my friend lent my Super EDF - a first gen shooter for the SNES. Not a great game by any stretch of the imagination, but I borrowed it to pass the time. I beat it within two days. My friend couldn't believe that I beat the game so quickly. He had me prove it to him. It wasn't until he noticed I used the cluster type weapon. Haha - that weapon would slow down the game making it easier to dodge stuff. He claimed that was cheating - but hey, it was in the game ;) But then you have games like Space Megaforce. That game didn't slow down like the others and had more action on screen at once. Compile knew how to code for their target systems.

Thee SNES special effect was when it didn't slow down. Quite lot of later games used this effect ;)

I don't know if the original 1991 version of Super Mario World is like this, but in the 1994 Super Mario All Stars version of Super Mario World; there is one level in the game (I believe it is the second level after Vannilla Secret Fortress) where there is a part where there is almost 20 enemies onscreen at one time, but it doesn't slowdown at all.

maybe it's not really the slowdown itself that is bothering me most of the time. Maybe it's those pathetic attempts developers made by taking out important gameplay mechanics just to eliminate slowdown that didn't even work.

Sega Genesis games always had something fresh and new in every level, while Snes games were always just left over ideas from Nes games. Every Snes game, with the exception of Super Mario World and Yoshi's Island, had the boring "normal sprites on static background" gameplay design, whereas Genesis developers were very creative on how they used sprites and backgrounds and had more interactive on the level design.

Take for instance, the worm boss from "Rocket Knight Adventure." Sega Genesis games always had boss fights that were creative like that, while Snes games only had statues drawn on the background, which is really boring and pathetic.

i got a headache of reading all this text:daze:

Quote:

---

Originally Posted by acdc

i got a headache of reading all this text:daze:

---

why are you thinking of pissing me off?

I've been to chyropractor this Monday, and he straightened out my neck. He told me that a few nerves were being squeeze by the spine bones in my neck causing me to be nervous all the time. Haven't got angry at all this week, even when I'm thinking of stuff that always made me angry in the past.