nesdev.org

6502 said:

And no, we are not being content with what is possible, we bitch constantly about what is NOT possible.

Eventhough I'm with Tomaitheous with the idea of a PPU to cart bus, you bring up a good point about bitching about what is not possible and not being happy about what is possible. I can't wait until the day I can shout "the Super Nintendo's cpu is so dang fast!" without some jerk asking me for "citation needed."

psycopathicteen wrote:I can't wait until the day I can shout "the Super Nintendo's cpu is so dang fast!" without some jerk asking me for "citation needed."

I'm sure every programmer here knows the S-CPU is capable is plenty, especially if the homebrew programmer is not bound by the limitations of a commercial developer (not talking about enhancement chips or even FastROM). I don't see much difficulty in getting a fast paced action game like gunstar heroes or metal slug running at 60FPS with some optimised code. If you're talking about non-programmers and their view of a slow SNES CPU, why does it bug you? Their opinion isn't really qualified to begin with so it's no big deal.

@ReaperSMS: I think I saw a 16bit ROM with selectable 8bit/16bit outputs on an SA-1 cart so you might be right about that.

Case in point: If the original Contra (not Contra Force) and Recca run on an NES, a game like Gunstar Heroes could certainly run on a Super NES with fast ROM. The lack of MMC3-style bankswitching isn't much of a problem because you can just dump a 64-tile bank in with DMA copy and still have time for OAM DMA and nametable updates. It won't handle crazy mid-frame shit like in Cosmic Epsilon, but HyperZone demonstrates that Mode 7 reduces the need for that.

Eventhough I understand that programmers had a limited time to program games, I still don't understand what exactly they cut corners to finish their games on time.

Because programmers like eating.

psycopathicteen wrote:Eventhough I understand that programmers had a limited time to program games, I still don't understand what exactly they cut corners to finish their games on time.

Because if they don't please asshat executive producer who wants it out BEFORE christmas wants it out before christmas, you try and please him in fear of ya know.....getting fired?

I know WHY they cut corners, I asked WHAT corners do they cut?

Yes, I get it, programmers don't spend time optimizing their codes, but intentionally slowing your codes down doesn't make the clock in your office run backwards either?

psycopathicteen wrote: Eventhough I'm with Tomaitheous with the idea of a PPU to cart bus, you bring up a good point about bitching about what is not possible and not being happy about what is possible. I can't wait until the day I can shout "the Super Nintendo's cpu is so dang fast!" without some jerk asking me for "citation needed."

I think the biggest appeal of retrocoding is to figure out how a system works and to explore its boundaries. To code FOR the architecture, not AGAINST it.

SNES is pretty tame compared to some other architectures. Like I said, if you want some REAL coding challenge, do something for the Atari VCS. There is no other system out there where your coding skills and inventiveness ultimately determines how well your game looks, and what your game can do at all. Take a very primive, but also very flexible graphics chip and make the 6502 do practically all the work.

I think during the SNES lifetime, the hardware was explored pretty well. It was the most popular system of its era and the developers were quite competitive. They HAD to be.

What if Nintendo wasn't always able to get a competitive pricing/availability on fast memories? If they need to have them in every cartridge, they could basically get screwed over at any minute.

The problem is not the access speed of the ROMS, but the broken 65816 design and some other dubious choices. WRAM is a huge bottleneck. If they could have thrown out their custom DRAM design, and hooked the 65816 directly to a 100ns SRAM, then 5.37Mhz CPU speed wouldn't have been a problem.

But then again, there are still those 2 mysterious TCKSEL pins at the CPU.....

I think that the SNES was, from day one, regarded by Nintendo as a system, which should be expanded by additional chips in the cartridges. Always the goal to make some extra bucks and milk the developers.

Could have been just like the NES, where the /CE line for the internal memory comes out to the cartridge port. The NES cartridge port has plenty of wasted pins, and they seem to have done just fine regardless of that.

As we already said: for full functionality, a whopping 50 aditional pins (the PPUs have TWO address buses for each 8 bit data part).

6502freak wrote: I think during the SNES lifetime, the hardware was explored pretty well. It was the most popular system of its era and the developers were quite competitive. They HAD to be.

If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

psycopathicteen wrote:

6502freak wrote: I think during the SNES lifetime, the hardware was explored pretty well. It was the most popular system of its era and the developers were quite competitive. They HAD to be.

If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

Oh please,

Play through Soul Blazer. Yes the fighting sucks, but there's so many neat effects they do. (Soul of Reality predating Ocarina of Time's Lens of truth, the Northern Lights, the palette cycling animations, the "underwater effect", fog and torchlight effects, invisible sprites in the model city).

psycopathicteen wrote:I know WHY they cut corners, I asked WHAT corners do they cut?

Yes, I get it, programmers don't spend time optimizing their codes, but intentionally slowing your codes down doesn't make the clock in your office run backwards either?

Making modular / reusable code would probably be the aim of a team of commercial developers. It won't be the quickest, but it'd probably be the most maintainable and easiest to debug, especially if you're not working alone and others have to deal with your code. It'd also be the most compact. The typical SNES game was 8mbits and if it was small enough to shoe-horn into a 4mbit ROM, they'd definitely try. Having stuff like dedicated macros for all your sprite drawing, huge tables for quick lookups, unrolled loops for building tilemaps to update with the screen would eat up space in an 8mbit or 4mbit ROM very quickly. Although with 32mbit or even 16mbit ROMs for free (including fastrom), there's really no reason why a homebrew programmer wouldn't take advantage of those to get enormous speedups.

Some time back (November or something) I optimised SMW's tilemap building code which was a pretty poorly written loop that ran 32 times for each layer that had to be updated. The unrolled versions took up about 20KB of code after trimming all the fat. It ran much, much faster than the original and with some optimal memory layout by the original game it would've run even faster by getting the DP register in there. But if I was trying to cram everything I could into an 8mbit ROM (or 4mbit in SMW's case) I wouldn't be trying that at all. 20KB just for one part of the game and there's many more to do after that. SMW does actually make use of unrolled loops, although it only does it for one case and it's not even stored in ROM. They just generated the code in RAM using a small routine in ROM.

Giant tables, unrolled loops and all of that wouldn't really work when you're pressed for ROM space. Although with 32mbit ROMs for free, there's no reason not to go that route in modern hacks or homebrew (with 8Mbyte possible with enhancement chips). The performance gains are huge but may or may not worth it if you're paying for every megabit. Having a functional, but not optimally coded game with more graphics or levels etc. probably would've been more appealing to a game developer depending on how much they're willing to spend.

whicker wrote:

psycopathicteen wrote:

6502freak wrote: I think during the SNES lifetime, the hardware was explored pretty well. It was the most popular system of its era and the developers were quite competitive. They HAD to be.

If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

Oh please,

Play through Soul Blazer. Yes the fighting sucks, but there's so many neat effects they do. (Soul of Reality predating Ocarina of Time's Lens of truth, the Northern Lights, the palette cycling animations, the "underwater effect", fog and torchlight effects, invisible sprites in the model city).

All those effects are common place for Super Nintendo games.

psycopathicteen wrote: If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

Strong words, which of course, in order to be credible, need some backing up. What area do you think the SNES wasn't particularly well explored?

Some titles even featured 3D software raycasting (Wolfenstein 3D, Jurassic Park and... *sigh* Super Noah's Ark 3D). Something you'd never expect the SNES to do well enough without special chips in order to be playable.

6502freak wrote:

psycopathicteen wrote: If you consider "well explored" as in using hacked on hardware special effects just to make use of hacked on hardware special effects, then I agree it was well explored. But if you consider "well explored" as in programming original special effects through creative use of hacked on hardware special effects, I disagree.

Strong words, which of course, in order to be credible, need some backing up. What area do you think the SNES wasn't particularly well explored?

Some titles even featured 3D software raycasting (Wolfenstein 3D, Jurassic Park and... *sigh* Super Noah's Ark 3D). Something you'd never expect the SNES to do well enough without special chips in order to be playable.

Sure

-fake scaling and rotation
-tile per offset mode
-multijointed sprites
-animation
-dual layer collision
-collision with wavy or tilting background layers
-tile grid animation with collision
-Mode-7 with waves

Yes, some of these might've been used in a couple games, but none of them were used nearly as much as they should've.