Which is exactly why every Nintendo console has had a lockout chip. Shovelware on the Atari 2600 stained the record of video games in general.MottZilla wrote:It's sad that a few bad efforts tend to stain a system's record in that way.
Fastrom patches?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
I think in terms of shovelware, both SNES and Atari VCS can be easily compared. On both platforms, there are lots of great but also lots of bad games. The lockout chip was introduced so that Nintendo would have the absolute monopoly on cartridge production. Everyone had to buy all cartridge stock in advance from Nintendo, with pricing and thus profit margin set by Nintendo. The CIC chip was the key for Nintendo's iron, draconian grip on the market.tepples wrote:Which is exactly why every Nintendo console has had a lockout chip. Shovelware on the Atari 2600 stained the record of video games in general.MottZilla wrote:It's sad that a few bad efforts tend to stain a system's record in that way.
-
- Posts: 592
- Joined: Thu Aug 28, 2008 1:17 am
- Contact:
I think it made even minor slowdown for SNES games, more apparent. People were looking for it or expecting it. Granted, a lot of the first year release games slowed down quite often from what I remember. A large majority of them. Yet nobody seemed to care when Genesis or TG16/PCE games slowed down. It was acceptable. But, there were certain expectations about the SNES - being the last console out on the market in the 16bit generation (true/real system, not counting that CD-I and other junk). And the slowdown did help out in some games (I was able to beat Super EDF because of one of the weapons that caused the game to slow down a lot)MottZilla wrote: It's sad that a few bad efforts tend to stain a system's record in that way. Gradius 3's epic slowdowns (which didn't bother me that much, as I said it can be helpful) and I also remember Final Fight being complained about because of few enemys on screen at once, no two player, poor music quality, etc. which some people took to mean it was something wrong with the SNES and not that it was the developer's fault.
Some bullet hell games intentionally slow down the frame rate when more than a certain number of objects are present in order to give the player a fighting chance. Even many PC bullet hell games do this, and this number doesn't vary from PC to PC so as not to change the game's difficulty on different hardware. But then this number is often far greater than the number of sprites that the Super NES PPU can show in the first place.
See screenshot
See screenshot
I don't see a problem with having an iron grip on the control of software released for your own platform like they did. I'm not sure which SNES games you can think of as shovelware, I'm sure there is a good bit but I don't think it's on the level of the VCS or other platforms. SNES has some really great games and while games like Final Fight and Gradius 3 suffered from various technical issues I don't believe that it ruined the experience completely. I certainly enjoy Gradius 3 despite the slowdown. And I played Final Fight as a kid and honestly I didn't notice the issues that I would notice today. Ofcourse I never played the arcade original when I first played the SNES version.6502freak wrote: I think in terms of shovelware, both SNES and Atari VCS can be easily compared. On both platforms, there are lots of great but also lots of bad games. The lockout chip was introduced so that Nintendo would have the absolute monopoly on cartridge production. Everyone had to buy all cartridge stock in advance from Nintendo, with pricing and thus profit margin set by Nintendo. The CIC chip was the key for Nintendo's iron, draconian grip on the market.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Something I've always wanted to say but couldn't find a more perfect time to say it.koitsu wrote:I remember having a chat with Neill Corlett about Gradius 3's slowdown, and based on his disassembly analysis, it appears to be intentional rather than an effective of slow/normal vs. fastrom or CPU speed.
I always wondered if programmers ever intentionally programmed slowdown because they thought they had to.
I blame the slowdown issue responsible for the long delayed Snes homebrew development scene. Most people simply avoid development for the Super Nintendo with the assumption that everything they do will cause slowdown.
-
- Posts: 592
- Joined: Thu Aug 28, 2008 1:17 am
- Contact:
I've heard a few people say this too, but what specific area of code points to this? Is his disassembly made public?koitsu wrote:I remember having a chat with Neill Corlett about Gradius 3's slowdown, and based on his disassembly analysis, it appears to be intentional rather than an effective of slow/normal vs. fastrom or CPU speed.
You'd have to ask him. The conversation was held maybe 8 years ago.tomaitheous wrote:I've heard a few people say this too, but what specific area of code points to this? Is his disassembly made public?koitsu wrote:I remember having a chat with Neill Corlett about Gradius 3's slowdown, and based on his disassembly analysis, it appears to be intentional rather than an effective of slow/normal vs. fastrom or CPU speed.
Agreed tepples. I don't think the slowdown has anything to do with it. While the SNES CPU speed does discourage C programming which might be related to psycopathicteen's point, you can just as well use ASM. On GBA you don't have this issue but you still have a somewhat similar hardware setup.tepples wrote:Since 2002 I've been blaming the GBA, a similarly powerful platform with a far lower barrier to entry.psycopathicteen wrote:I blame the slowdown issue responsible for the long delayed Snes homebrew development scene.
Another barrier is the Sound system. On GBA I imagine its easy to get audio going where as on SNES you have limited options, very limited.
Let me state the big problem with ASM. There are two parts of a game: the back-end and the front-end. The back-end or "model" implements the rules of the game, such as how high a fat plumber can jump, and the front-end or "view" displays the result to the player. If one language compiles on two platforms, then ports of a game to those platforms can share a back-end, and only the front-end must change between platforms. You can see this in the source code for Lockjaw Tetromino Game, which has both an Allegro front-end and a GBA front-end (which shares a lot of its code with a DS front-end) calling the same back-end. But sharing the back-end across platforms only works among platforms that support a given language. The Super NES alone has two incompatible assembly languages for the two CPUs, one for decoding music sequence data into a series of DSP commands and one for everything else, as you mention next:MottZilla wrote:Agreed tepples. I don't think the slowdown has anything to do with it. While the SNES CPU speed does discourage C programming which might be related to psycopathicteen's point, you can just as well use ASM.
On GBA you have the vaguely NES-reminiscent Game Boy APU to get started. You also have a pair of 8-bit PCM audio buffers, and as long as you know the basics of digital signal processing, you can mix those in C for reasonable performance if you're not rich enough to license someone's ASM mixer.Another barrier is the Sound system. On GBA I imagine its easy to get audio going where as on SNES you have limited options, very limited.
Last edited by tepples on Fri May 21, 2010 10:22 am, edited 1 time in total.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
I didn't know there was ever an SNES development scene in the first place.mic_ wrote:You mean "long gone"? Several demos and cracktros where released on the SNES in the 1990s.I blame the slowdown issue responsible for the long delayed Snes homebrew development scene.
Anyway, I have a pretty decent SNES game engine that I've been dying on posting the source code. I recommend playing around with it if you want a head start at SNES development without starting from scratch.