Game Sack

Quote:

---

Originally Posted by tomaitheous

But there I agree there's a difference between what pushes the limits of the system, and what pushes the exceptions of software for the system. I don't look at Toy Story as something that particularly pushes the systems limits, than I do as game developers being clever about design. Not everything that looks above and beyond the norm, means it's pushing the system's limits.

---

Good point.

I think one of the issues here is that "push hardware limits" is a subjective term IMO.
So, like you said, you can read it as something like: "makes the hardware do something which it wasn't designed to do". But even if we fall that line of thinking, not everything that is outside the original scope of the design is actually taxing the hardware (which the word "push" would imply IMO).
In the end, also as you said, most people end up listing games which are somewhat visually impressive to them.

Quote:

---

But even if we fall that line of thinking, not everything that is outside the original scope of the design is actually taxing the hardware (which the word "push" would imply IMO).

---

I agree. From of this thinking then how look what system is running the code (game)?

I think to be able to accurately say which games are really pushing the hardware one would need to put a lot of work on understanding the consoles' architectures first and then run those games in debug mode to really see what's going on on each case.
Of course, that's not the kind of thing that you should expect from shows like Game Sack which are aimed in the general public and tailored to the "informative fun" formula.

So, yeah, it is what it is. Lol.

Quote:

---

Originally Posted by tomaitheous

But there I agree there's a difference between what pushes the limits of the system, and what pushes the exceptions of software for the system. I don't look at Toy Story as something that particularly pushes the systems limits, than I do as game developers being clever about design. Not everything that looks above and beyond the norm, means it's pushing the system's limits.

---

Re-quoting it since I forgot to write about the Toy Story aspect of it the last time.

I agree with most of what tomaitheous said here; most of what the game shows is good use of hardware if anything and many times it's very far from even taxing it for what I've explored using debuggers.
One detail that went unnoticed in the Game Sack episode (and usually goes unnoticed) is how much of VRAM update/DMA transferring is involved in scenes like the one where the dog is chasing you. There's a shitload of DMA transferring going on during that scene and I really don't remember any other game on the Mega Drive which used such giant transfers with a good performance result.
If there's something really taxing the hardware in that game, IMO, are the scenes like that one. But, then again, it doesn't mean it's doing something completely outlandish in terms of hardware usage.

Stupid Game Chasers

Well, Toy Story does break the 64 color limit and has some pseudo 3D effects, which were pretty uncommon to see on Genesis. Having all that along with big sprites, etc, makes it look like it's pushing the hardware.

I don't know what you would expect. Throwing a debugger on and seeing which games are using max CPU and memory isn't necessarily going to give you good results either, as just because a game is using a lot of CPU or RAM or DMA doesn't mean it's doing so efficiently.

It's not so much about what's going on under the hood as how it shatters expectations about what the system can do. And Toy Story is well beyond what was generally expected on Genesis.

If you dint think Toy Story pushes the hardware, I'd be curious to see from a technical perspective why that is, as long as a technical explanation for some games you do (that GS hasn't covered).

>Be ToyStory
>omg it breakz da limit!
>Still looks brown as fuck

But, it's now 128 shades of brown! :p

I always thought that Sonic 2 pushed the hardware, by trying to be too fast. There are certain areas where the game has a huge slowdown, or others where you can get Sonic to leave the screen. Unless that was all done on purpose. The most common leave-the-screen I can think of is in Chemical Plant Zone.

I get not fixing the slowdown in the underwater parts of Sonic 1(making it feel more like you're under water), but I kind of find it awkward when people complain about slowdown when hit, while having a large number of rings. There's an explosion of sprites suddenly appearing on screen. Shouldn't it make sense that that would cause some slowdown?

Road Runner has similar almost-leaving-the-screen moments in Desert Demolition. You have to get past stage 1 though, which has slowdown as you have moments of running past 6 balloons in a row, holding anvils, that pop.

Since watching this vid I finally took the plunge and bought a PS3, just for GTA V. I haven't even seen this game in action on any platform and have had enough of missing out. Can't wait!

Quote:

---

Originally Posted by segarule

I cannot explain my philosophical point because i have limitations in english. But only the fact that yout said "That´s the scope of design for these systems" proves that hardware not was "pushed to limits". One thing is use a mapper to have more Ram, for example. Other thing is you put a FM chip built in cartridge and any claim: "wow! amazing! This game pushed the hardware to limits". I understand "push hardware to limits" use any trick to command the system to make a function which the system not was ready in realize it. I can not explain what i would like in my native language to english. Like i said when i use a MMC chip to not only give more ram to system but more tiles, create split screen, change irq to sound, it surpass the hardware limit. Maybe i not have explained correctly, so forget it.

---

I just want to say, that I understand the frustration of the language barrier thing. You have my sympathies there. I definitely have a lot of respect for people who are quite fluent in another language.

My only gripe about the whole "mapper" thing when it comes to the NES, is that people posting about it rarely understand what it's actually doing (any of the chips). The majority of mapper chips don't really do a whole lot with the NES system, and because nintendo was cheap - they were constantly adding small changes to them - hence why there are so many mappers.

Mappers themselves weren't new tech to the NES/famicom (they have been around years before), and even the SMS, TG16, Genesis, and SNES uses them. The Neo Geo even uses them. Most mappers on the NES/Famicom do just that; map in/out memory. There's nothing special about that. And in the age of 8bit memory address range limitations, they were quite common (even x86 machines used them). Being extended to the video ram (PPU) was by design. The NES/Famicom needs hardware on the cart; there's no ram for tilemaps or tiles/sprites on the system itself.

One could argue about the audio thing, but the audio lines on the cartridge are there for a reason; audio upgrades. The TG16, Genesis, SNES also as them (probably sms too). Even the 7800 had them. But I agree, when you stick something like the FM chip on the NES - that seems totally out of scope with era, and not technically impressive either. Yet for some reason, I have no qualms about giving the SMS a pass on this one.

The IRQ is extended to the cartridge port for a reason. So why is it "unnatural" in the use of carts on the NES? It does what it's supposed to do; whether it's for video or anything else, is irrelevant. I have yet to see any valid argument showing otherwise, other than the tried "wasn't part of the original system". Again, applying some other centric game console perspective onto the NES - it all that it amounts to (the opposition).


Gamers rarely understand design scopes. There's this perception that the SNES processor was weak, therefore they had to add chips to the cart to make up for it. When the reality is, Nintendo wanted a specific price point for the system and the already advance audio and video designs are the bulk cost of the system. The 65816 is a very-very-very cheap processor cost wise. Nintendo predicted that software would be more demanding as the product spanned its life; thus addon cart chips were part of the original design be extended open bus of the B bus to the cart itself (there are two buses in the SNES that are mapped to the same lower fixed address range so the main cpu can access them at all times). That's how it was designed; rather than having additional cost to the gamer upfront with an expensive cpu, add the tech as it's required. By comparison, the 68k was a very expensive cpu. If Sega had gone with a cheaper processor, they would have had budget for better color/DACs and audio. Just two ends of the same spectrum of design. Nintendo saw how adding new tech to a system expanded its life and capability with the Famicom, and used that knowledge going forward with the SNES; expandability. How this equates to "cheating", is nothing than some construct on gamers minds with little understanding of things. There were no standards or guidelines console designers had to stick to.

Quote:

---

Originally Posted by tomaitheous

I just want to say, that I understand the frustration of the language barrier thing. You have my sympathies there. I definitely have a lot of respect for people who are quite fluent in another language.

My only gripe about the whole "mapper" thing when it comes to the NES, is that people posting about it rarely understand what it's actually doing (any of the chips). The majority of mapper chips don't really do a whole lot with the NES system, and because nintendo was cheap - they were constantly adding small changes to them - hence why there are so many mappers.

Mappers themselves weren't new tech to the NES/famicom (they have been around years before), and even the SMS, TG16, Genesis, and SNES uses them. The Neo Geo even uses them. Most mappers on the NES/Famicom do just that; map in/out memory. There's nothing special about that. And in the age of 8bit memory address range limitations, they were quite common (even x86 machines used them). Being extended to the video ram (PPU) was by design. The NES/Famicom needs hardware on the cart; there's no ram for tilemaps or tiles/sprites on the system itself.

One could argue about the audio thing, but the audio lines on the cartridge are there for a reason; audio upgrades. The TG16, Genesis, SNES also as them (probably sms too). Even the 7800 had them. But I agree, when you stick something like the FM chip on the NES - that seems totally out of scope with era, and not technically impressive either. Yet for some reason, I have no qualms about giving the SMS a pass on this one.

The IRQ is extended to the cartridge port for a reason. So why is it "unnatural" in the use of carts on the NES? It does what it's supposed to do; whether it's for video or anything else, is irrelevant. I have yet to see any valid argument showing otherwise, other than the tried "wasn't part of the original system". Again, applying some other centric game console perspective onto the NES - it all that it amounts to (the opposition).


Gamers rarely understand design scopes. There's this perception that the SNES processor was weak, therefore they had to add chips to the cart to make up for it. When the reality is, Nintendo wanted a specific price point for the system and the already advance audio and video designs are the bulk cost of the system. The 65816 is a very-very-very cheap processor cost wise. Nintendo predicted that software would be more demanding as the product spanned its life; thus addon cart chips were part of the original design be extended open bus of the B bus to the cart itself (there are two buses in the SNES that are mapped to the same lower fixed address range so the main cpu can access them at all times). That's how it was designed; rather than having additional cost to the gamer upfront with an expensive cpu, add the tech as it's required. By comparison, the 68k was a very expensive cpu. If Sega had gone with a cheaper processor, they would have had budget for better color/DACs and audio. Just two ends of the same spectrum of design. Nintendo saw how adding new tech to a system expanded its life and capability with the Famicom, and used that knowledge going forward with the SNES; expandability. How this equates to "cheating", is nothing than some construct on gamers minds with little understanding of things. There were no standards or guidelines console designers had to stick to.

---

that was really nicely explained and even a lunk like me understood it.

OK, but even accepting that, they're still not pushing the boundaries of the console, any more than the SVP chip did the Genesis.

A mapper that just maps memory and adds some interrupts is perfectly fine. An entire extra processor or audio chip? That's another system by that point. I'd even count the MMC5's per tile colour attributes as not really being the NES anymore.

Most mappers on the NES just let is access bigger roms, that is fine really, just forward thinking on nintendo's part. Even things like the decompression chips used in late SNES carts, they are just serving as extra rom space as far as I'm concerned.

I don't think address limitations should count against a system, because they are meant to be broken by mappers, and have been since the Atari 2600.

A lot of demos released for the C64 rely on hardware bugs that often result in memory corruption and crashes on the real hardware. Should this count as pushing the system? It certainly is pushing the poor machine to the point that it crashes, but is that something the 'machine can do' at that point?