shouldn't have animation been a bigger issue than speed

What does get me puzzled is that the Super Nintendo can only have 16-kB (or 128*256 pixels) of space in the V-ram at once to hold all the onscreen sprite graphics, and can only load up about 128*96 pixels during V-blank and doesn't let you to touch any kind of video registers at all during active display.

I wonder why no developers were bothered by this, but always claimed the cpu being the big issue. I don't see any problem with it's cpu. It's an accumulator-based cpu, it uses the entire ram space as it's register set because it only takes 1 cycle per memory access, is that really that hard to grasp?

No.

Yes.

No...

Depends on the program. Some will be CPU bound, and others graphics bound. If you just do simple operations on bytes (and maybe some words), the app probably won't be CPU bound. If you use simple cell-based displays, it probably won't be graphics bound. If you use large variables or complicated algorithms, you may wind up CPU bound. If you try to treat the display in a pixel-based manner, you may wind up graphics bound. It's best if the programmer understands the abilities of the console well so they can work to it's strengths. Conversions of existing apps are where you would probably run into trouble. Older hardware works best with code written specifically for that hardware.

Damn you Chilly Willy.

Buzzkill

Quote:

---

Originally Posted by Chilly Willy

Conversions of existing apps are where you would probably run into trouble. Older hardware works best with code written specifically for that hardware.

---

I know, I find it sad that there are so many 68000-only optimizations used in released Super Nintendo games that actually resulted in the 65816 running much slower than it should. Doing things such as using INX and DEX, in circumstances where you could've just indexed with the next offset.

It's harder to talk up differences in animation quality, and less convincing.

Quote:

---

Originally Posted by Tanegashima

Damn you Chilly Willy.

Buzzkill

---

That's Mr. Buzzkillington the Third to you. :p

:D

Quote:

---

Originally Posted by j_factor

It's harder to talk up differences in animation quality, and less convincing.

---

I know, but whenever somebody is interviewing a programmer, the programmer always talks shit about the cpu (eventhough it is his fault for not programming it the right way) but they never mention about the dma speed and the v-ram size?

The 65816 can compete when the programmer actually realises the correct way to program an accumulator-based cpu.

For accumulator-based cpus, the way they're supposed to be programmed is: you load a value into the accumulator, then you use opcodes and memory values to manipulate the value of the accumulator, then you use another opcode and another memory values to manipulate the value of the accumulator, and again and again and again.

See there really is non of this load-operate-store baloney people do all the time for 65816-like cpus. It's all a never ending stream of manipulating what was left in the accumulator.

Quote:

---

Originally Posted by dragonboy

I know, I find it sad that there are so many 68000-only optimizations used in released Super Nintendo games that actually resulted in the 65816 running much slower than it should. Doing things such as using INX and DEX, in circumstances where you could've just indexed with the next offset.

---

As someone else said before, optimizations exist on two levels; low level and high level. If the higher level logic is unoptimized, optimizing low level might not have much of an impact.

One thing I always wanted to know is, how the hell do game gameplay/graphics engines work? I tried figuring out how to make one, but it is just so confusing. How can someone make an algorithm that takes care of everything that you would ever think of in a game, were you can just change a few numbers around whenever you need to add something in the game, and be done?

Is there some kind of organization that all game engines have? Like, are they seperated in distinct parts?

Game engines are as varied as the programmers. That said, the basic philosophy is always the same: take the problem and break it into smaller steps. Recurse until you've reached the lowest level needed. There are many books on game design. Many colleges and technical schools have courses on it. I suggest checking online as I know I've seen a few web pages on game design. Check a bunch of different pages/books/whatever, then look at some open source games. That will give you an idea of how others have made their games. Start with simple games like Tic-Tac-Toe and the like. Work your way up to Quake 3. :)

not necessarily speed makes a big difference for game play for an RPG sure I'd prefer good animation and sound or maybe for an adventure to but for sports and action and arcade games I want speed.

I know speed is important for action games. What I'm saying that it is EASY to program speed. Easy for me. I have no idea why it's so hard for everyone else. I can easily program raw speed for the Super Nintendo in my sleep.

What I am saying is, what if because the Super Nintendo could only update about 96*128 pixels of sprites during v-blank using it's DMA, some programmers might've been lazy and instead of getting around the limitation by using v-ram animation (which also has a very limited size), they forced the system to slowdown so they can send the rest of the sprite patterns during the next v-blank.