nesdev.com's "not" longest thread ever.

[Sik]

Capcom's early title Final Fight is known to suffer slowdown and have sub-par sound quality.

When they made Final Fight I think they didn't trust the CPU at all, in fact if I recall correctly every graphic is uncompressed (yep, this is why Guy and a whole level are missing, they wasted all the space they had). I guess they probably didn't think the CPU would be fast enough to decompress graphics without a loading screen.

[bazz]

were people not aware of $2021?

I assume you meant $2101

[tepples]

I still can't wrap my head around SNES games that lag with 4 or 5 characters onscreen. Collision takes like 30 or 40 cycles, and you have 45000-60000 cycles per frame.

Is that both sprite-to-sprite and sprite-to-background collision? Besides, it's not just collision; it's also each object deciding where to move in the next frame. How long does it take a unit to A* its way to its destination?

I did manage to find bad oam handling techniques through disassembling some games, but I am pretty sure it's not even the worst example of inefficient code in said games.

Interesting. About how long does it take you to find blatant inefficiency in a randomly chosen game? I'd be willing to help you with a "SNES WTF" blog.

The reason why this would be a problem is that most of the sprites in the game aren't even 8x8 (heck, the r-type 2 arcade board, the Irem m72, didn't even support sprites smaller than 16x16...)

How much overdraw did the m72 support? On the Super NES, you get only 34 slivers of 8x1 pixels each on each line, and putting an 8x8 bullet in a 16x16 sprite cel costs you an extra sliver across its entire height plus two slivers on the additional height.

I guess they probably didn't think the CPU would be fast enough to decompress graphics without a loading screen.

Super Mario All-Stars also uses uncompressed tiles, apparently because it needs to stream a bunch in during vblank to simulate MMC3 bank switching.

I assume you meant $2101

War was beginning.

[Sik]

I guess they probably didn't think the CPU would be fast enough to decompress graphics without a loading screen.

Super Mario All-Stars also uses uncompressed tiles, apparently because it needs to stream a bunch in during vblank to simulate MMC3 bank switching.

It wasn't starved for ROM space though =P

But yeah good question, do all the graphics for a level (well, a section) fit in VRAM?

[tepples]

Super Mario All-Stars also uses uncompressed tiles, apparently because it needs to stream a bunch in during vblank to simulate MMC3 bank switching.

good question, do all the graphics for a level (well, a section) fit in VRAM?

SMB2 and SMB3 use animated tiles (moving grass, spinning ? blocks, etc.). Even if they did all fit in VRAM, the game would need to rewrite the nametable to animate them, and that's probably more complex code-wise than just uploading new CHR.

[psycopathicteen]

Finding oam manipulating code is easy, but I don't know how to find physics and AI. Is there anything better than BSNES debugger? I have the feeling that I'm not using the right kind of program.

[tepples]

Finding oam manipulating code is easy, but I don't know how to find physics and AI. Is there anything better than BSNES debugger? I have the feeling that I'm not using the right kind of program.

As I wrote in this post: Find the RAM that the OAM manipulating code reads when determining positions of sprites. Then find what writes to that RAM, and you should end up in physics. This requires a debugger that can break on RAM reads.

[psycopathicteen]

Super Ghouls and Ghosts makes that difficult, because it has an intermediate sprite table between the game logic and OAM buffer, that keeps changing address in RAM.

[tepples]

If a game is trying to use runtime ASLR techniques to stop Game Genie/Action Replay from working, similar to those adopted by later Pokémon games, then perhaps you can try proceeding forward from player input.

[Drew Sebastino]

What you said though about running out of sprites is certainly interesting. With 128 sprites you have quite a situation when you still run out of them.

Like I said, this could have easily been avoided if they had used the 16x16 and 32x32 combination. There is a part in level 3 of that game where there are these flying enemies that use 4 16x16's and when you shoot them, they leave 3 4 16x16 explosions behind them, and this lasts until they hit the ground. With 8 of these enemies on screen (It does happen) you effectively run out of any room for anything else (including you're ship, which is always onscreen) If the game had used 32x32 sprites, everything would have taken the exact same size and you would have only used 32 sprites instead of the full 128. Like what 93143 said, when Irem made R-type 3, they saw the error of their ways and used 16x16 and 32x32 sprites among other things.

About the missing level in Final Fight, I thought I might chime in and say that there is a very overwritten version of it still in the game. (There's a Youtube video of it online.)

I assume you meant $2101

Opps... Yeah, you're right. I tried to remember what it was without looking it up. (Which obviously didn't go too well. )

The reason why this would be a problem is that most of the sprites in the game aren't even 8x8 (heck, the r-type 2 arcade board, the Irem m72, didn't even support sprites smaller than 16x16...)

How much overdraw did the m72 support? On the Super NES, you get only 34 slivers of 8x1 pixels each on each line, and putting an 8x8 bullet in a 16x16 sprite cel costs you an extra sliver across its entire height plus two slivers on the additional height.

I don't know. There really isn't much documentation on the Irem m72. (Nothing really outside of these websites: http://www.system16.com/hardware.php?id=738 and http://patpend.net/technical/arcade/m72.html)

What I do know, though, is that the system runs at the resolution of 384x256. Pretty Big! Interestingly, when it's successor came out, the Irem m92, the resolution was actually reduced to 320x240 (perfect 4:3 aspect ratio!) Based on the resolution and this: (I couldn't get the picture to be 384x256. )

M72 Overdraw.png (132.22 KiB) Viewed 2466 times

I would say that the overdraw is just barely 384 pixels long. (The game doesn't try anything more daring then that.)

I assume you meant $2101

War was beginning.

What?

About the BSNES Debugger, there is certainly room for improvement. A lot of features that are missing are found in other emulators for different consoles like visual boy advance. The two things that (In my opinion) need the most improvement are: the vram viewer, (you can't even look at it using different palettes) and the oam viewer. It would be really nice if they showed you the graphics the sprites are using and if they told you the 9th x bit and fixed the character selection for each sprite (When the 9th character selection bit is enabled, it still says it is using tile 256 instead of 512.) I'm sure the memory editor probably needs help, but I haven't even figured out how to change any values using it. I click the numbers, but it doesn't let me edit them. I see that there is a box on the side that lets you type stuff into it, but nothing happens if you type in 1-F, but if you type in nonsense like T, the program crashes.

[Drew Sebastino]

Either I'm insane, or I just saw a post that said "Someone almost set up us the bomb." What is "the bomb" anyway? And I'm pretty sure it was supposed to be "Someone almost set us up the bomb."

[tepples]

"What is "the bomb" anyway?"

Apparently you didn't get signal a decade ago. First read Wikipedia's article about "the bomb", then watch these videos:
Zero Wing intro
Invasion of the Gabber Robots, a remix of the Zero Wing intro (also as video)
Mmm WHAT YOU SAY !!

[MottZilla]

Capcom's early title Final Fight is known to suffer slowdown and have sub-par sound quality.

When they made Final Fight I think they didn't trust the CPU at all, in fact if I recall correctly every graphic is uncompressed (yep, this is why Guy and a whole level are missing, they wasted all the space they had). I guess they probably didn't think the CPU would be fast enough to decompress graphics without a loading screen.

Final Fight and U.N. Squadron were their first titles. Maybe they didn't yet have time to develop tools for the SNES for compressing graphics. Why do you assume they thought it would "require a loading screen"? It seems more likely to me that they didn't have the tools already available since they were the first titles and they did not have the time/money/experience to develop them for the first titles. And then when the Final Fight Guy special edition was released they were not going to invest the time into doing what they should have, put all 3 characters and the missing level back in.

I don't think it had anything to do with trusting the cpu or not. Just the usual time is money combined with no pre-existing company tools and routines for dealing with compressing graphics.

[psycopathicteen]

I've been trying to reverse engineer R-Type today, and it looks like the slowdown might be easy to fix. Almost half a frame is spent doing what appears to be a metasprite drawing routine, and it just barely misses the end of the frame.

[MottZilla]

I hope you try to fix it and succeed. It would be quite an interesting patch to actually optimize a game to reduce or eliminate slowdown. I wished someone could do that for Mega Man The Wily Wars on the Genesis as it suffers some pathetic slow down in many places.