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

[Drew Sebastino]

I actually did make a working demo of a character jumping, (using the walker code) but it wasn't very useful because I basically just did bcc on the sprite y variable so that if it went far enough down the screen, it would "pop" it above the line. I don't remember exactly how I did it (I'm sure I could rewrite it, but I kind of want to make a horizontal shooter) but I remember using a register that I would check to see if the character was in "ground mode" (checking if you are going to press the jump button) or "air mode" (decreasing the y velocity which was a register every frame so that it would eventually become negative and would make the character fall. It also checked if you were below the line I made.)

[MottZilla]

I know I'm going to sound crazy for this but If I were to pick a main problem with the SNES, It wouldn't be the main CPU speed, but rather the two PPU's speed. I almost don't see why people complain so much about the CPU speed when you can 1. Optimize your code as much as possible. And If you still have slowdown than proceed to step 2. Add an expansion chip. You can always add more processing power for moving everything around, but It's not like you can add more BG layers or increase sprite overdraw. (After all, It's a video game console, not a calculator. ) Basically, what I am saying is that you can add on to the CPU, but not the PPU's.

I certainly disagree. You can only optimize your code so much, and you may still run out of time to process each game frame in time. You say "add an expansion chip" like this is something anyone can do or do so simply. That's certainly not the case. It adds complexity to your design and definitely cost. If you look at the SNES library, a very small percentage of games used expansion chips. You mention not being able to do anything with the PPU running out of BG layers or dropping sprites. The average game player probably can't name any game where this seemed like a big problem. I do recall some games where you can see sprite drop but it is not a problem or distracting like it was on NES with the flicker to compensate. And not enough BG layers, I'm not sure what any example of that would be.

An healthy improvement would have been if the SNES could have accessed all RAM and ROM at "Fast" speed. But it would have increased the cost of the DRAM in the console and the ROM in every cartridge. Or maybe just changing RAM access to "Fast" and leaving it up to each game whether or not to have 'FastROM' would have been another improvement. If we move on from the CPU, I'm sure we could complain about the SPC before the PPU. Maybe the SPC could have used additional memory or some kind of faster transfer mechanism.

But like koitsu said, it's history now. There's no changing it and we can debate it all day but still it changes nothing.

[psycopathicteen]

You can only optimize your code so much, and you may still run out of time to process each game frame in time.

Yeah, but you can still optimize your code to run 10x faster than what you usually saw in SNES games, before optimization becomes difficult.

[tepples]

Super FX adds sprite overdraw. Look at the title screen of Yoshi's Island. Each of those buildings revolving around the center of the island is a quadrilateral drawn by the Super FX coprocessor, and those are sent to the PPU.

What you are calling added sprite overdraw is really just a buffer they set up. The sprites aren't moving, the tilemap is just changing. (If you notice, all the hills and buildings are using the same color palette.)

Exactly. The Super FX is compositing the extra sprites to a buffer, and from the viewer's point of view, the buffer creates the illusion of more sprite overdraw. It's like PC games and Lynx games, which draw all sprites to a frame buffer and then display that.

If you use the Gameboy player, you still can't do split screen with a friend.

A modern PC is orders of magnitude more powerful than a GBA, with support for displays that substantially exceed 1080p. Yet PC games likewise tend not to offer split screen.

Also, the GBA's low resolution really stands out on a large TV.

GBA: 240x160.
Super NES, zoomed in to fit the entire width of an HDTV: 256x168, with 28 lines hidden off the top and bottom.

Also, do you think you could go over the whole BG thing again? I kind of got lost while reading it

Each 8x1 pixel sliver (or 16x1 if half-width pixels are enabled) of the background is based on 16 bytes of data.

• Mode 0: 8 bytes nametable, 8 bytes tiles
• Mode 1: 6 bytes nametable, 10 bytes tiles
• Mode 2: 4 bytes nametable, 8 bytes tiles, 4 bytes offset
• Mode 3: 4 bytes nametable, 12 bytes tiles
• Mode 4: 4 bytes nametable, 10 bytes tiles, 2 bytes offset
• Mode 5: 4 bytes nametable, 12 bytes tiles (half-width pixels)
• Mode 6: 2 bytes nametable, 8 bytes tiles (half-width pixels) , 4 bytes offset
• Mode 7: 8 bytes nametable, 8 bytes tiles

EDIT: Incorporates typo corrections by psycopathicteen

Based on this, It seems like you could say that with every new BG layer, you loose 2bpp.

Correct. You lose 2 bits to nametable fetches.

[psycopathicteen]

Mode 2 is 4 bytes name, 8 bytes tile, 4 bytes offset
Mode 3 is 4 bytes name, 12 bytes tile

[bazz]

Neviksti is legendary. I only know so much about him/her (I think he's a guy). here are some things I remember:
. Created the Star Ocean uncompressed Gfx hack (I think it was him, others could have been involved I dunno much about it)
. Created pcx2snes graphics conversion tool
. investigated using the XBand for internet communications on SNES
. I think he managed to alter the Tototek Superflash CPLD to support multiple save-games.
. Created the popular snes-starterkit package, including its useful source library routines.

He's probably done a lot more cool things on SNES and other consoles. He seems to pop up being involved on just about anything!! I remember he had valuable input on the development of the WLA-DX assembler(s).

[Drew Sebastino]

yes maybe u understand the basic grasp now of how to implement jumping, but you should NAIL IT DOWN with a demo. The fixed point math reference tepples made is extremely important on these systems without floating support. It's a useful way to use the bytes/words as a cheap decimal fractional notation. Very important to learn I think.. Depending how good you are with the SNES u might want to postpone this and learn more satisfying things first, that's up to you. Plus if you make a demo that interacts with the player by jumping you will have gained real experience in making your ideas come to life..

Alright, Here's a quick demo I made just recently. (The physics are so terrible that I would never put them in an actual game though.)

jump.rar

(14.39 KiB) Downloaded 111 times

You can only optimize your code so much, and you may still run out of time to process each game frame in time.

Yeah, but you can still optimize your code to run 10x faster than what you usually saw in SNES games, before optimization becomes difficult.

Sadly, I don't doubt it. I think that we all know what the rea$on is. (Getting the game out faster.)

Also, I never said that it was easy (although admitting it did sound like I said it was) to add an expansion chip. I just that at least you can upgrade the CPU.

The average game player can't see this?

Overdraw Problem.png (8.88 KiB) Viewed 2297 times

And about asking for more backgrounds, you could always ask for more. For example, Say if in a game, you had a foreground, background, and a large boss character. One of them would have to use a 2bpp layer. A lot of people who designed games for the SNES really didn't even use BG layer 3, I guess because they felt that it was useless. I've literally seen games that use BG layer 3 for creating a status bar that consists of about 12 8x8 tiles. If there were games for the SNES that properly utilized BG layer 3, they would have to be the Donkey Kong Country Games.

About the SPC needing to be upgraded more that the PPU's, I wouldn't know, as I've never even touched the SNES's sound system.

I guess there's no sense in complaining, though, as the past is the past...

[psycopathicteen]

I honestly think that the programmers just didn't know how to optimize their code. If you know how to write efficient code, why not write efficient code to begin with. You can argue that efficient code takes longer to write, but I just haven't seen an example of this happening. Every example of code optimization I've seen was always about taking bloated code, and reducing it. I never seen anybody make a routine faster by making it longer and more complicated.

[tepples]

Every example of code optimization I've seen was always about taking bloated code, and reducing it. I never seen anybody make a routine faster by making it longer and more complicated.

Taking a bunch of branches out of the inner loop often makes the routine longer but faster. Or compare early versions of my VWF tile drawing routine, which looped to shift the tile, to the one that Blargg wrote, which uses a branch tree.

[rainwarrior]

I honestly think that the programmers just didn't know how to optimize their code. If you know how to write efficient code, why not write efficient code to begin with. You can argue that efficient code takes longer to write, but I just haven't seen an example of this happening. Every example of code optimization I've seen was always about taking bloated code, and reducing it. I never seen anybody make a routine faster by making it longer and more complicated.

Well, the examples of optimization you have seen are quite limited, then, perhaps mostly limited to replacing badly written code with the same algorithm but done with more skill or care? This is the kind of optimization a C compiler can be pretty good at, but optimization isn't just about trimming fat, it's about understanding both the process and the goal and making it faster. You know more about the goal than a compiler does, and you can make much higher level decisions than it can.

There are lots of opportunities for optimization that add complexity to an algorithm. Tepples already hit upon a simple example. Unrolling loops is a trivial example that adds more code but can increase speed. (Again, this is simple enough for a compiler to do in many cases.)

It's hard to come up with easy examples of complexity-increasing optimizations, but that's because the good examples of it are complicated solutions to complicated problems. There are cases where there are generic problems like sorting a list where you can choose between a simple implementation like insertion sort, or a more complex but faster heap sort, etc, but most real world examples are very specific. Even the choice of algorithm I just mentioned is not generic; there are even situations where the insertion sort would be a faster choice.


Here's an example. I took a challenge to write sudoku solvers with some friends of mine, to see who could write the fastest one.

1. I start with the simplest solution. Systematically try the numbers 1-9 in each empty space, check for validity, and recursively continue until the board is filled. (~50 lines of code, ~450 seconds)

2. Do a bunch of simple optimizations to solution 1 that the compiler was unable to do (aggressively unroll loops, rearrange data structures, etc.). (~250 lines of code, ~250 seconds)

3. Maintain a sorted list of spaces to check by how many solutions remain in each, check the one with the least number of solutions first. (~500 lines of code, ~16 seconds)

In this case I drastically increased performance by increasing the complexity of my code. I could have tried to do more reductive optimizations on #1 but I doubt I could have squeezed much more performance out of it. I needed to add more information about the problem/goal into the algorithm, and this required more code.


In my professional life, I usually want to see someone write the simplest and most maintainable version of an algorithm first, after which optimizations become a necessary distortion of that clear version in the name of speed, only to be done when that speed is needed. In my experience most optimization attempts at the professional level reduce readability and increase complexity (and of course, take longer to write). There are many cases where someone sees a better algorithm to use that is both faster and smaller and easier to maintain, but these are very rare gems, and finding them is a joyous occasion.


There is, of course, occasionally someone just writes bad code because they're incompetent or tired or for whatever reason, but this isn't the norm, because if this is your consistent level of operation you'll probably be fired. Fixing bad code is not what I think of when I think "optimization", this is more like... "taking out the garbage".

[tepples]

There is, of course, occasionally someone who just writes bad code because they're incompetent or tired or for whatever reason, but this isn't the norm, because if this is your consistent level of operation you'll probably be fired.

You say "occasionally"; I say "daily".

[psycopathicteen]

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. 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.

[Drew Sebastino]

Although I'm not adding anything to the subject, have you ever seen Super R-Type? It's quite possibly the most inefficiently programed game I've ever seen. So much so that when the game actually goes to normal speed, (when there are absolutely no enemies on screen and you are not pressing the fire button) It actually gives off the illusion that the game just miraculously sped up. Also, to top off what a technical disaster it is, the game uses 8x8 and 16x16 sprites. (it seemed like most early SNES games started off this way and then moved to 16x16 and 32x32 sprites, with the notable exception being the Donkey Kong Country games. Although this sounds ridiculous, were people not aware of $2021?) 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...) and many things are 32x32 meaning that they have to be made of 4 sprites. Because of this, there are many points in the game where it literally runs out of sprites, and things start to miraculously disappear.

[MottZilla]

I've not played Super R-Type. Perhaps it's just an example of a developer's first SNES title. Or one of the first for them.

Capcom's early title Final Fight is known to suffer slowdown and have sub-par sound quality. And Konami's Gradius III ofcourse is known for intense slow down. 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.

[93143]

I've not played Super R-Type. Perhaps it's just an example of a developer's first SNES title. Or one of the first for them.

IMO it's a pretty good game despite the slowdown. But R-Type III was a later effort and is much better. It seems Irem more or less got the hang of the system in the meantime.