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?