Dreamcast VGA

[Scooter]

That sounds more like an art direction rather than a hardware limitation.

More than likely art direction dictated by a hardware limitation.

I really like my N64, but try Beetle Adventure Racing sometime. It really is a fun game, but it is quite often very difficult to tell what's going on on the screen. I'm sure there are others.

Even Perfect Dark which makes use of the Expansion Pack has really bland and fuzzy textures which make even finding a door in a wall sometimes difficult to do. As a comparison, I never had that problem with Syphon Filter.

[kool kitty89]

Jeez, you're right. I tried it out on my TV and it looked like shite

You know you can switch the TV from anamorphic 16:9 to normal 4:3 resolution, right? (or at least you should be able to...)

N64 just did alot of things wrong, most notably the horrendously low-quality textures. The RAM expansion sorta fixed it, but it was like $30 extra and was only compatible with a few games, most of which had slowdown when it was being used. Project 64 helps alot though if you have the right filters turned on. Also, BITD, Nintendo's stubborn insistence on cartridges made the games cost astronomical prices up to $70~$80 while PSX games (and later DC) would sell for $40 all day long.

Not really defendign the whole cartridge issue (which happened for a couple reasons -especially propritary format, and had a number of repercussons for Nintendo -losing Square probably the biggest in Japan)

Anyway, the texture cache was quite limiting, but no more so than the PSX's was. (when using mip-mapping the 4kB cache is effectively the same size as the PSX's 2 kB cache iirc)
They didn't have to use filtering, it was a chioce, and soem textures are indeed unfiltered. (soem DS ports have blocky graphics by comparison)

The repeated textures is another issue though, that would be related to texture cache and ROM space I think. The ROM issue is double edged though, it may limit overall storage capacity (at practical cost ranges), but also allowed soem exploits liek Factor 5 did to work around th elimited cache by streaming texture data from ROM.

The RAM expansion was worth it if you got one of the games that absolutely required it, like Perfect Dark (sort of) or Majora's Mask. (I know the latter isn't your kind of game, but it's the main reason we got our expansion pak) Plus, you could get one for cheaper later on, from 3rd parties, sales, or used. (I think we paid full price though)
In the case of the Lucas Arts games, most were available in even higher resolution, and better draw distance, texture res, and fraemrate on PC anyway. (plus they were cheaper -if you had a decent PC at least)

There were other unfortunate limitations imposed by nintendo though, like poor and even intentionally restrictive support of the programmeable RSP microcode. (they were late to distribute any decent tools and withheld the "turbo 3D" code they had available already) That could have made for more optimized game einghines with better trade-offs, liek more polygons/s (more polys on-screen and/or higher framerate) at less features for textues (perspective correction and filtering), Z-buffering, antialiasing, more emphesis on 2D, etc. SO they could have had PSX style 2D games (in terms of 3D rendering type) but with much higher framerates and/or poly-count, or soem compromise in-between; not to mention the possibility of optimized 2D games and interesting possibilities for non-polygon based rendering. (raycasting, height maps, voxels, etc)
All on top of the decision not to go with optical media. (I'm not sure why a propritary optical format wasn't considered or hefty security system, maybe they didn't have the time -though I'd have thought using a custom form factor for standard CDs might have been a simple route)

N64 had no audio hardware with which to make chiptunes. All music on N64 is just compressed. Sometimes it was over-compressed and had terrible audio quality, sometimes a game would simply not use too much music in order to maintain a higher quality, occasionally a game might devote a large amount of its space to music, and often they simply used carefully-chosen sounds that would survive high levels of compression. Alternatively, they could have used some sort of software synthesizer to generate music, but I'm not aware of any games that did that.

What the hell are you talking about? The N64 either used the CPU or RSP to generate audio. In a few cases they used streaming, compressed audio, but most of the time it was sample based music. (midi, mod players, or trackers)
It could get chip tuny sounds better than the SNES, Amiga, and some contemporary PC soundcards if they wanted to. (just use samples of the desired sounds)

[j_factor]

What the hell are you talking about? The N64 either used the CPU or RSP to generate audio. In a few cases they used streaming, compressed audio, but most of the time it was sample based music. (midi, mod players, or trackers)

I didn't say it was streaming audio, I just said it was compressed. Samples are also compressed. The CPU and RSP are both processors, not audio chips; they do not generate audio, they merely play it.

It could get chip tuny sounds better than the SNES, Amiga, and some contemporary PC soundcards if they wanted to. (just use samples of the desired sounds)

So could any computer, but it's not actually a chiptune anymore. [I guess you could argue that it's a chiptune if it's composed of samples of real chip sounds, but it's certainly not an N64 chiptune.]

[Chilly Willy]

The CPU and RSP are both processors, not audio chips; they do not generate audio, they merely play it.

No, the CPU or the RSP are indeed the source that generates the audio. The only thing the audio hardware does is play a 16 bit stereo buffer at a speed the CPU sets. The CPU or RSP has to create the data that fills the buffer. It's usually wavetable synthesized audio done by the RSP or the CPU. Think of it like a PC with only an audio codec - the codec merely converts the data in memory from digital to analog, but it cannot create the data in the first place. The PC's CPU does.

[j_factor]

No, the CPU or the RSP are indeed the source that generates the audio. The only thing the audio hardware does is play a 16 bit stereo buffer at a speed the CPU sets. The CPU or RSP has to create the data that fills the buffer. It's usually wavetable synthesized audio done by the RSP or the CPU.

I'm hearing contradictory statements here. You're gonna have to be more specific than "wavetable synthesis" because that can mean multiple different things. And what audio hardware are you referring to? I've not seen any documentation that states that any piece of the N64's hardware is devoted to audio.

Think of it like a PC with only an audio codec - the codec merely converts the data in memory from digital to analog, but it cannot create the data in the first place. The PC's CPU does.

This analogy makes no sense to me. Neither the codec nor the CPU should create the data, the data would come in the form of pre-existing files, and the CPU just processes it. The only situation I'm familiar with where a CPU creates audio data is in either emulation or physical modeling synthesis, in which case the sound is algorithmically generated. But that's still not exactly a chiptune.

[kool kitty89]

I didn't say it was streaming audio, I just said it was compressed. Samples are also compressed. The CPU and RSP are both processors, not audio chips; they do not generate audio, they merely play it.

Just like the SNES... or Amiga. (albeit Amiga samples aren't very compressed) In fact, that would make the Genesis, the last major console released which was capable of "real" chiptunes...

I'm hearing contradictory statements here. You're gonna have to be more specific than "wavetable synthesis" because that can mean multiple different things. And what audio hardware are you referring to? I've not seen any documentation that states that any piece of the N64's hardware is devoted to audio.

It's "wavetable systhesis" in the sense of sample based synthesis, that's sampled instruments and sounds played back and manipulated to "synthesize" music. Similar principals apply to the Amiga, SNES, various PC sound cards, roland's sound canvas (which has become the baseline standard and MS's generic software generated general midi for windows), the Apple IIgs's Ensoniq chip, Sega CD's Ricoh chip, software mod players in the Genesis (Toy Story intro, maybe Earth Worm Jim 2) or 32x, etc. (different formats and such, but same basic principal -note that soem are fixed to samples in ROM, while others can add samples in RAM -or are strictly limited to RAM -I think the SNES, Amiga, and IIgs are in the latter category)

The Roland MT-32 would not be an example though, as it's a bit of a different animal, though samples are part of what it does, it also can generate it's own waveforms (I think), but also works in a number of ways that common sample based synthesis does not. (Roland uses the term "linear arethmetic synthesis")

This analogy makes no sense to me. Neither the codec nor the CPU should create the data, the data would come in the form of pre-existing files, and the CPU just processes it. The only situation I'm familiar with where a CPU creates audio data is in either emulation or physical modeling synthesis, in which case the sound is algorithmically generated. But that's still not exactly a chiptune.

Well that makes sense in the same contxt that the CPU or RSP has to process data fromt he cartridge from soem compressed format into a linear 16-bit PCM stream. Now, it could be as aimple as decoding an audio stream or more complex, as in using samples (probably compressed) and some kind of list for playing music (be a tracker, or midi) using those samples played at varying pitches for certain lenghts of time and with other effects to create the desired final musical arrangement. (still an oversimplification)

[tomaitheous]

No, the CPU or the RSP are indeed the source that generates the audio. The only thing the audio hardware does is play a 16 bit stereo buffer at a speed the CPU sets. The CPU or RSP has to create the data that fills the buffer. It's usually wavetable synthesized audio done by the RSP or the CPU. Think of it like a PC with only an audio codec - the codec merely converts the data in memory from digital to analog, but it cannot create the data in the first place. The PC's CPU does.

So it only has a 16bit stereo audio buffer system? That's it? No multiple channels and such with their own dividers?

[Chilly Willy]

Seems some folks have the wrong idea about the N64 audio. The only audio hardware the N64 has is a set of ports. These include: the address of the buffer to play, the number of samples in the buffer, a control register, a status register, the sample rate, and the sample size. The address and length registers are actually FIFOs, so you can set them multiple times to queue up multiple buffers that play one after the other. The DMA channel for the audio pulls the length and size from the FIFOs, then DMAs the data to the DAC (digital to analog converter) at the rate and sample size currently set in the registers. So you really only have one (stereo) channel that can be played at a set rate and sample size.

The CPU or RSP has to create the data that is in the buffers. It may be as straightforward as just pointing to PCM data loaded from the rom into ram (everything has to be in ram for audio and video - there is a dedicated DMA channel just for transferring rom to ram). That would be used for things like sound effects, like gunshots. If those samples are compressed, the CPU has to decompress them.

Music could also be stored in rom in a compressed form, then decompressed in ram to play. That uses a lot of rom space, and cpu power, so it's rarely done (unless on a PC or modern console). Most music is in some kind of MIDI/tracker format, where you have a set of prerecorded instruments and a score that describes the music. The CPU (or RSP in the case of good N64 players) then generates the audio data from the instruments using the music score. I suggest j_factor go look into how timidity or mikmod works since he seems to be unfamiliar with how most music is done on PCs and consoles.

[j_factor]

Just like the SNES... or Amiga. (albeit Amiga samples aren't very compressed) In fact, that would make the Genesis, the last major console released which was capable of "real" chiptunes...

Well, I'm under the impression that most people today that make music on/for the Amiga probably wouldn't consider themselves chiptune artists. They would consider mod music to be a separate thing. I don't know that I've seen any SNES stuff.

And either way, it's still at least a little different with Amiga and SNES, in that both of those systems have a dedicated sound chip. Even ignoring every other technical detail about how the music is created and played, how can you call something a chiptune, if it's not coming from an audio chip?

It's "wavetable systhesis" in the sense of sample based synthesis, that's sampled instruments and sounds played back and manipulated to "synthesize" music.

That's exactly what I thought it was. It plays/alters samples. It's not generating wave forms.

Most music is in some kind of MIDI/tracker format, where you have a set of prerecorded instruments and a score that describes the music. The CPU (or RSP in the case of good N64 players) then generates the audio data from the instruments using the music score.

That's not the same thing. It generates the audio data in the sense of creating the finalized audio track, but it's not generating audio, meaning the processor is not the original source of the actual sounds. Nothing you said in this post contradicts my original statement.

[Chilly Willy]

That's not the same thing. It generates the audio data in the sense of creating the finalized audio track, but it's not generating audio, meaning the processor is not the original source of the actual sounds. Nothing you said in this post contradicts my original statement.

Got it - so the source of art is in the paints, not the artist...

You've got a very odd way of thinking there. Suppose the CPU generated the instruments (like a simple sine or square wave) - is it still not the source of the audio? You need to study the subject more, then come back when you have a leg to stand on.

[j_factor]

Got it - so the source of art is in the paints, not the artist...

The source of pigment is in the paints, not the artist.

You've got a very odd way of thinking there. Suppose the CPU generated the instruments (like a simple sine or square wave) - is it still not the source of the audio? You need to study the subject more, then come back when you have a leg to stand on.

You keep telling me to study the subject, but you still haven't actually said anything that refutes what I originally said. If you're going to argue, have an argument.

[Chilly Willy]

The source of pigment is in the paints, not the artist.

But pigments are not art, and waveforms are not music.

You keep telling me to study the subject, but you still haven't actually said anything that refutes what I originally said. If you're going to argue, have an argument.

No, you keep IGNORING the points made because you have no valid answer. You're clearly ignorant of the subject, but try to step around the argument by repeating the same thing over and over. It doesn't matter how many times you state the instrument is the music - it doesn't make it true. Try again after you've studied a little more on the subject. Then maybe you'll be able to make a coherent defense.

[TmEE]

so from what I understand here, basically all sound done one N64 is software generated since there's no dedicated mixing or waveform generation in hardware other than the playback buffer and that DMA channel to transfer sound data. The CPU reads some sample, messes with it, mixes it with the buffer, repeat for one more channel.... the more you want the more CPU you got to use. Things go like on PC most of the time where the sound card can only play single channel, you got to mix and do all kinds of other fun in expense of CPU power to get what you want....

[j_factor]

But pigments are not art, and waveforms are not music.

I didn't say the word "music". I said audio. There is a difference.

No, you keep IGNORING the points made because you have no valid answer.

I haven't ignored anything. You've made no points. I said "N64 had no audio hardware with which to make chiptunes." You have not said anything that refutes this in any way. "You need to study the subject more" isn't making a valid point, it's just being smarmy.

You're clearly ignorant of the subject, but try to step around the argument by repeating the same thing over and over. It doesn't matter how many times you state the instrument is the music - it doesn't make it true.

What the hell are you even talking about? I never once said that. You're just making up completely random things.

Try again after you've studied a little more on the subject. Then maybe you'll be able to make a coherent defense.

There's no need to take such an arrogant attitude. If you have an argument, argue it, instead of telling the other person to study. That's not an argument.

And for what it's worth, I've been into the chiptune scene for years. I know damn well what they are.

[Guntz]

I haven't ignored anything. You've made no points. I said "N64 had no audio hardware with which to make chiptunes." You have not said anything that refutes this in any way. "You need to study the subject more" isn't making a valid point, it's just being smarmy.

You just did ignore an argument:

But pigments are not art, and waveforms are not music.

It doesn't matter how many times you state the instrument is the music - it doesn't make it true. Try again after you've studied a little more on the subject. Then maybe you'll be able to make a coherent defense.

To repeat what Chilly was trying to say which you oh so conveniently avoided, the instrument only makes sounds. The artist arranges the sounds into music.

EDIT: *sees that j_factor just edited his post to include the arguments he missed*