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.

Most programmers probably get tripped up because they're used to programming a PC. They fall into the classic trap: when a problem occurs, throw memory/cpu power at it. Such a method won't work on older consoles... or even new ones, depending on the game and the PC it was aimed at originally.

You avoided that pitfall by starting with the hardware, then working towards what you wanted based on its limitations.

I can think of 2 reasons why the low bandwidth + small v-ram can cause slowdown:

1) They forced the system to lag on purpose so they can finish the dma load without uglier glitches.

2) They programmed some insane algorithm that keeps track of what was left already in the v-ram and what was not, that takes almost the entire frame for the cpu to perform.


Using forced blank bars on the top and bottom of the screen can fix the bandwidth. Capcom always did this, but they never made use the extra bandwidth, for some odd reason?

They did use the extra bandwidth, at least in case of SF2, but apparently its not really enough in all cases.

Street Fighter 2 does not look like they used the extra bandwidth. Maybe if they built the sprites out of 32x32 and 64x64 blocks, yes, if they built the sprites out of 8x8 and 16x16 blocks, then no.

the smaller sprite sizes were used because it allows you to spare some space in the cart to fit all the animations into a power of 2 ROM size...

If it uses 8x8 and 16x16 sprites, it doesn't need the bars at all.