Printable View
Well I imagine that sharing palettes is a pretty good convenience.
If the Genesis had 8 palettes, then the biggest weak spot in the Genesis would be gone.
But I can't help but be curious, if you're from California then why do you call it a Mega Drive?
It might not be the color count per se, that's making the difference. But rather the color choice freedom of having more subpalettes. A tile (8x8 image/pixel block) can use one of four subpalettes on the Genesis. Each one of those subpalettes holds 15 colors. A tile cannot use some colors from one subpalette and some colors from another subpalette. Once you pick a subpalette to associate to the tile, in the tilemap (that makes up the backgrounds), you limited to use only those 15 colors. The limitation of 15 colors isn't so bad. Many popular arcade systems had the very same limitation (including NeoGeo and Capcom CPS1 boards). Hell, the original Sega 16bit System16 arcade board had a limitation of only using 7 colors per tile (sprites were 14 colors, with one color reserved for horizontal length terminator). So, having more subpalettes to chose from means greater flexibility in color choices overall, not *just* higher color counts. The Genesis has 4 subpalettes. The back ground tiles can use any four of them, but sprites are must use any one of them. So you have to share that four palette group with both background graphics as well as sprites. The PC-Engine has 16 subpalettes for Background and another 16 subpalettes just for sprites; 32 subpalettes total. I bet you a dollar that you can easily improve upon the PCE graphics of Raiden (including increasing the color count). Many PCE games were pretty lazy with subpalette usage. Well, that is to say that they didn't max its effective usage out in every game.Quote:
Originally Posted by azonicrider
Even in PCE Street Fighter 2, a friend and I were able to create new BGs with better looking color as well as higher color counts.
The Genesis is a damn near perfect 16bit home console IMO, with just that one little draw back; subpalettes.
sheath: Those scroll types you are referring to (ala TF4 ocean level) don't need the priorities set on every frame. You set the tile priority on the map, which is almost always stored in the tilemap data in the rom (i.e. it's not dynamic). Doing 'paper' scrolls (non overlapping scrolls) VS doing overlapping parallax is exactly the same on the scroll routine. You divide the tilemap section into different speeds, the exact same way. No additional overhead and such, other than designing what and how they should look (but that's not 'realtime', that's design time).
On the SNES, it shouldn't be done any differently. Your tilemap already has the necessary priority settings for the tile associated entry. Scrolls aren't vectors since they don't have a direction (per se), they're just scalars. If you have ten 'scrolls' for a BG layer, than that's 10 'additions' you need to do. Even if you gave each scroll layer as 32bit value (16bit:16bit fixed point) for smoothness, that's just ten 32bit additions. The SNES cpu should have ~no~ problem doing that. For a high speed rom (3.58mhz, but round it down to 3.1mhz because of the ram wait states) there's something like ~51,000 cycles per 1/60 frame. Even if your routine was so wasteful that it took 1000 cpu cycles to do ten 32bit additions, that's still only like ~1.9% cpu resource. Quite a few SNES games do a lot more cpu heavy resource effects than just 2%.
Doesn't sound like much, but it would go a long way in relaxing color restrictions.Quote:
If the Genesis had 8 palettes, then the biggest weak spot in the Genesis would be gone.
Edit:
Sheath, also: Technically TF4 is doing more scrolls that you see on screen. If a game scrolls vertically up and down, like TF4, then the game must keep track of all the scroll positions off screen. That is, the player controllable areas. The transition from ocean to under ocean area with sinewave effects - those sinewave effects aren't processed until that transition part. If that makes sense.
Unfortunately, the developer couldn't be bothered to include much of any parallax.Quote:
Originally Posted by azonicrider
Yes I knew the whole 4-bit tiles/sprites. Thats probably the main reason why SMS games look so much better than NES games.Quote:
Originally Posted by tomaitheous
Didn't know the Genesis shared palettes though. That must be a good convenience.
Say you had a robot in a Sonic level, that was mostly orange. You could also use the same palette for the lava tiles in the background.
Another drawback, is the bass sound effects in the Genesis version. I love them.Quote:
Originally Posted by Black_Tiger
It's a lot better than being stuck with 2 pairs of 2 (2 sprite and 2 BG) at least. ;)Quote:
Originally Posted by azonicrider
That said, some games still end up treating it like that due to general design, especially fighting games due to the variable nature of the level+character combinations. (typically 1 palette dedicated to each fighter and 2 for the BG) In those situations on SNES, you'd have 8 for BG and up to 4 for each fighter, or on PCE 16 for BG and up to 8 for each fighter. Or on an "expanded" Genesis VDP, you could have 4 for BG and 2 for each sprite.
On a separate note, doubling the palettes wouldn't really help for Sega CD FMV quality though, since you'd still only have 4 palettes for the BG. Going to 12-bit RGB would probably help at least somewhat though, at least for some types of optimization. (you could get away with finer dithering in some cases though, particularly given several games already seem to convert from 15-bit RGB sources, and 12-bit would allow 64-136 pseudo colors per 16 color palette while only using checkerboard dithering -not coarser dithering seen in most Sega CD FMV . . . so more like what you see in Keio Flying Squadron's intro)
That and you could do 160x224 12 bit direct color using the DMA color "hack" Chilly Willy has made demos of. (in 9-bit RGB it's not so useful for FMV -especially as it's too low res to dither well- so even if some devs did consider doing that, there's real downsides to it)
MD is a much more convenient abbreviation . . . "Gen" isn't a good option IMO, and general force of habit. Same thing for MCD . . . "Sega CD" is more cumbersome (especially when using it a lot in discussion), and SCD isn't really used commonly. ;)Quote:
If the Genesis had 8 palettes, then the biggest weak spot in the Genesis would be gone.
But I can't help but be curious, if you're from California then why do you call it a Mega Drive?
Take a look at Sonic 2 again and you'll notice how much of the backgrounds and enemies are made up of the Sonic and Tails sprite colors.Quote:
Originally Posted by azonicrider
Okay, good to know. I would have assumed that a few transparent pixels here and there wouldn't tax anything. I don't know that VDP supported cell scrolling and priorities made up entirely for the lack of a third background layer either, but the more I look at the possibilities the more it makes sense especially if it saved in hardware cost.Quote:
Originally Posted by tomaitheous
I think I've seen you say that before but not in as much detail (or I just forgot the details like I did your instructions for using PS for sprite art). So that leaves what as possible reasons, for no SNES games having as many scroll layers or overlaps? Aesthetics still seems at the forefront, but that might have been part of Nintendo's documentation at the time as well. Either way I'd like a quote from a developer that references scrolls on the SNES at all, it just doesn't seem like it was a very big deal. I can't even recall any game magazine reviews commenting on parallax at all, they always emphasized colors on screen and sample quality.Quote:
Originally Posted by tomaitheous
Especially the more objects you want to have with distinct palettes.Quote:
Originally Posted by tomaitheous
Did I comment on TF4 in this thread? I think when I counted the layers in the spritesmind thread I scrolled all the way up and down and counted the water line scroll as one layer.Quote:
Originally Posted by tomaitheous
You are rightQuote:
Originally Posted by Black_Tiger
Tails probably shares the same orange/brown palette that these tiles use:
http://i.imgur.com/ay6d11u.png
two colours may not seem like much, but those tiles only have a few colours on them anyways.
Ugh, what is up with that screenshot?
I replaced the matching colours with pink and yellow. I figured those colours are easier to spot.
I didn't mention this before, but I started to:
I mentioned it's a shame that mode 3 is only usable as 8-bit-pixel tiles, which are nice (256 -or 241 rather- colors), but take too much memory to use effectively, and that a 5-bit tile mode would be really nice and useful on the SNES.
But thinking further, it would be even MORE significant to have multiple layers of higher than 4-bpp:
the highest combined color depth modes use 12 bitplanes (mode 3 uses 1 8-bit and 1 4-bit layer) with mode 1's 10 bits being second (same for mode 4). So the SNES should have enough bandwidth to handle two 5-bit scroll layers, or perhaps even 2 6-bit layers (I assume mode 1 couldn't do 3 4-bit layers due to the added bandwidth of using a 3rd tilemap).
5-bit layers would mean 31 colors per tile (using 8 palettes -sharing sprite/BG CRAM like in mode 3), while 6-bit layers would mean 63 colors per tile (using 4 palettes). Both of those should have been quite useful, but probably more so for 5-bits due to the lower memory usage.
A mode using 3 3-bit (7 color) layers might also have been really useful.
Edit: wait a minute . . . this just made me realize that the AGA Amiga chipset, using the same amount of bus time as OCS, it should be capable of significantly more than the 8-bitplanes it supports. Given both the 32-bit bus, that would mean double the bandwidth of OCS/ECS with the same RAM timing, and thus up to 12 bitplanes with the same bus time used as EHB on OCS, but beyond that the AGA chipset has limited support for FPM reads as well, which gives double the bandwidth again over OCS (4x net bandwidth) iirc, or at least in the case of interleaved bus mode (ie timing such that a 7.16 MHz 68000 has no waits) it would allow 4x of THAT bandwidth compared to OCS (1 slow and 1 fast read for the chipset followed by 1 CPU access slot every 560 ns), which should mean it could allow 16 bitplanes in that more and possibly more if allowed to steal CPU bus cycles (as in 5/6-bit modes on OCS).
And in turn, that would mean enough bandwidth for dual 8-bit playfields (2 256 color BG layers), or variable color depth options as in OCS.
That would also mean that if CBM had invested in an earlier "slow" (ie 7.16 MHz) 32-bit Amiga chipset, it should still have had enough bandwidth for 12 bitplanes using similar timing to the 6-bitplanes of OCS, or 8 bitplanes similar to the fully interleaved 4-bit modes on the Amiga. (of course, it would have been even better if the blitter got extended to 32-bits too . . . unlike in AGA -Paula didn't get 32-bit enhancements either)
Ah, okay I see. I've been doing the same thing to figure out where photoshop is sticking colors.Quote:
Originally Posted by azonicrider
This picture also made me realize something else.Quote:
Originally Posted by azonicrider
Mesh bushes. Haha. Its just as good as transparency.
Something else to consider, which practically makes Sonic 2 and 3 a work of art in my mind, is that Sonic and Tails and other characters appear in various well colored backgrounds without changing their own palette.Quote:
Originally Posted by azonicrider
I don't think they were attempting to do dithered mesh style translucent blending there. Take a look, it's all 2x2 pixel blocks for that mesh, so it's pretty obviously just intended to be normal gaps between leaves in the bushes. ;)Quote:
Originally Posted by azonicrider
And yeah, quite a lot of Sonic 1's (and at least some of Sonic 2's) BG graphics use 1/4 res pixels scaled up 4x (2x2) like that, presumably as a primitive form of compression (with art done in a stylized manner suited to that). Still, it should have been pretty simple to code it such that you'd decode those low res objects with full res dithered mesh (still blocky 2x2 pixels, but with every other pixel missing), so again, definitely leaf holes.
Looks good though. ;)
In Sonic 3 & Knuckles, there's quite a few things that get recolored if you play as Knuckles or Sonic. The sprites stay the same, but various BG objects take on the different palette of the sprite. Really obvious for things like the bubble shield when played as Knuckles (water drop is red instead of blue), and even weirder if you manage to get into places you're not supposed to be with the character.Quote:
Originally Posted by sheath
This doesn't happen for Tails as his palette is separate and constant, while Sonic's palette is swapped when Knuckles is present. (I'm pretty sure Tail's colors are also much more heavily used in the BG for that reason . . . and the sandy brown/yellow/orange/white/red/black color scheme in general is more useful than Sonic's)
I think, in Sonic 1 and 2 for the MD/Gens, Sonic and Tails are the constants in the subpalette (even if they don't use all 15 color slots for each character), so it would be more of the level shares their subpalette data rather than the other way round. But for regular enemies, yeah I'm sure some of them are tailored specifically for the zone's palettes. And the more generic ones probably reuse Sonic and Tails colors.
I use SCD all the time, and have never used MCD. :DQuote:
Originally Posted by kool kitty89
I switch between MD and GEN about half the time. I use MD when I know I'm talking to an evenly mixed multi-national group where most are used to MD instead of GEN. I use GEN when addressing a primarily American group.
It's a valid question to ask. Before I started coding for the PCE, I didn't know much about it spec wise. I remember reading all the specs for colors on screen, yet a LOT of early to mid gen titles didn't boost lots of colors (or appeared to). Even some later gen games were lacking... per se. I always though something just didn't add up. It wasn't until that I started coding that I realized.. nothing was up. Subpalettes take up such a tiny amount of data and have nothing to do with cpu resource. It just a matter of design choice. I honestly think PCE had that early 16bit look that gave it, its charm. And I think they kind of stretched that as far as it would go. There were titles that were the exception, but most weren't. It wasn't until near '94-96 that you started seeing more mature looking PCE titles in the visual departments (aka less 'block/tile-ish' and more 'SNES' like. Legend of Xanadu 2 and A Near Earth Story/Seiya Monogatari come to mind. Even Ys 4).Quote:
Originally Posted by sheath
But to be honest, I don't remember scrolls being any sort of issue on the SNES. It just felt like that was the main effect on the Genesis (and lots of sprite particles/fancy explosions), so that's what they did. Like what has been stated before, many-many arcade systems could easily do the parallax that Genesis games are known for, yet didn't. I think it's akin Euro game developers using arpeggios for almost all audio chips in EU/UK, yet the NES rarely ever got it. Even though it was fully capable of doing it. It just didn't need it since it had more channels and varying timbres to select from to get more distinct sounds. Scaling and rotation were the 'in thing', as so was transparency. I would bet that's where developers were concerned with during game development on the SNES. These new effects that made it standout, not replicate older effects that have been around for a while.
On the PCE and scrolls, it's a different issue. On the PCE, the cpu is doing a hell of a lot more heavy lifting that either the SNES or Genesis cpu is doing. It's driving the sound engine. It's streaming the samples. It's doing the linescroll updates or segmented scroll updates. It's updating vram with dynamic tiles. Unoptimized code can really put a damper on things, once they all add up. Not to mention it required more effort AND more design time (layout limitations and such). More times than not, developers take the easier path IMO. It's not until near the end of the system's life, that new life/effects/etc are needed more than ever - since the machines are starting to show their age. I don't think it takes 5 years for a developer to 'learn' a system per se, at least not with these old 2D systems. It has more to do with incentive or push the system at that point in its life, due to what I already stated previously. Bar of what's acceptable, what's expected, and what's new (for whatever that means), just keeps increasing. Does form give rise to function or function give rise to form? Does that even apply to this? Did you know that Texas abolished small claims court? Dude, that sucks :/
I don't like using "SCD" for Sega-CD and usually either spell it out or stick to MD/MCD in discussions, since SCD has been used for the most popular PC Engine format since before the Sega-CD existed.
I stopped using SCD, mainly because of this board. SegaCD was always SegaCD. This 'SCD' is fairly new for naming SegaCD. To avoid confusion, I tend to use MCD, SuperCD, and SegaCD. I've used TurboCD before, but that doesn't always mean CD 3.0, IIRC.Quote:
Originally Posted by Black_Tiger
I never did find a PCE game that did much more than 100 colors simultaneously, granted that could be all 16 x2 palettes at any given time just not every color in each at any given time. Xanadu 2 looks great for certain though. I haven't played the others.Quote:
Originally Posted by tomaitheous
Yes, I can definitely see attempts at incorporating Mode 7 probably took up more development mind share than attempting to match Genesis background effects. If I were designing a SNES game I would really want to use three backgrounds and 256 colors more than Mode 7. I suppose a more pressing question would be why Genesis devs didn't pull out all of the stops to optimize their art for four palettes plus palette swaps and shadow/highlight in ever screen. I would suppose that had more to do with them thinking their game looked good enough without all of that extra effort.Quote:
Originally Posted by tomaitheous
If more PCE games looked like Ninja Spirit I would be delighted, just using dynamic tiles for a second layer makes a huge difference and the color usage in some of the objects makes them really "pop".Quote:
Originally Posted by tomaitheous
I do think it is a chicken or egg type of discussion. I wouldn't know if small claims court even existed or how to use it even. I usually just shoot people at high noon when they double cross me.Quote:
Originally Posted by tomaitheous
Yeah, except most Euro developed NES games are FULL of arps. :p (they also tended to make fairly heavy use of square waves over variable pulse, and rather heavy use of envelopes as well)Quote:
Originally Posted by tomaitheous
Actually I could have sworn I watched a video of a Genesis game recently with pretty significant use of arpeggio . . . might have been SNES, I just remember it seeming a bit out of place for the platform, so to speak . . . more so since it was a Japanese developed game. (damn, not this going to bother me)
Also, listening to your PCE 7 kHz MOD examples again after poking around some GBA games made me realize that those actually sounded better than a good deal of MOD players on the GBA . . . and not just in CPU taxing 3D games either. Hell, not just MOD players either, but it doesn't too much weaker than some games with limited use of MOD for a few instruments backed up by GB chip synth stuff. (and PCE MOD+chip synth would be more powerful than that too, and you could more easily afford better than 7 kHz if just doing a couple channels)
Kool Kitty: Check this out...
And here on the real console (more pronounced) @ 2:24:
Is PCM just used for percussion there, or also some of the melody? Is that FM-guitar-like instrument a streaming sample or just a normal 32x5-bit sample with envelope applied? (given the debug readout seems to be for that channel specifically, I assume that's a CPU played/scaled sample)
Not that you couldn't apply envelopes to CPU driven samples as well.
Yeah, just PCM/DDA channel for percussion. The higher pitched FM type sound, you mean? It's not a sample stream. The channel starts out with a specific waveform, then over a 60hz or slower rate, they keep writing a specific byte from a 32byte waveform (looping on 32 bytes). Depending on the rate of the channel playback and the rate of the write update, you get different 'corruption' sounds. But regardless, the timbre changes over time. And yeah, you can apply both portamento, vibrato, and volume envelopes on top of that effect. Like any other normal channel.
So much knowledge on this thread and, at the same time, some crazy bullshit along the way.
That's why i like this place.
So I put together something.
People always mock the PC Engine for having an 8-bit CPU, when it is clearly a generation ahead of other 8-bit systems.
Looking at the specs, does having an 8-bit CPU really mean sh*t all?
I will keep this picture handy, while venturing other forums:
http://i.imgur.com/VXOy1GZ.png
The CPU specs were just an easy point to market against Nintendo's near-absolute monopoly. Both NEC and Sega did it, along with promising Arcade perfect ports even though neither aspect would always absolutely be true in library. The NES and Master System should never be compared directly with the PCE/TG16. The later is clearly far and away part of the next generation of hardware. The only reason we are even discussing this is because game magazines, which were themselves extensions of corporate marketing teams, went nuts with the "8-bit vs 16-bit" thing for a couple of years.
You might want to add the release date & price to your table .. puts things in perspective ;)
NES ( July 15, 1983 ) 14,800 yen
SMS ( October 20, 1985 ) 15,000 yen
PCE ( October 30, 1987 ) 24,800 yen
Also isn't it an issue to get that many sprites out of a NES? Wouldn't 64 sprites just make things flicker and slow down?
Even specs are misleading as they are only a small part of the big picture. Many of the more important specs and features never make it on comparison charts, because you can't directly compare them like that.
In the end, when someone sees Fatal Fury Special running on PC Engine and says that it's part of the same generation/class as the SMS and NES, no amount of reasoning will change their mind.
This is why specs aren't directly comparable. 16-bt gen consoles don't max out all of their sprite limits at once either. Usually everything is designed around the one limit which will be met first.Quote:
Originally Posted by evilevoix
There are still people with a view like that.Quote:
Originally Posted by sheath
I hear people calling the 2600 a 4-bit console, because it was released before the NES.
Quote:
Originally Posted by azonicrider
It goes both ways, with people calling the Neo Geo "24-bit". What's crazy is when people use both extremes at once:
Quote:
Now imagine an arcade perfect port. Fatal Fury Special is, amazingly, unbelieveably, an arcade perfect port of a 128 meg game running off a 24-bit arcade system to what is essencially an 8 bit console. No, I'm not speaking in hyperbole.
It's ridiculous, because it's selectively using the "bit" term both to describe the comparative class for Neo Geo (superior to Genesis/SNES), yet still listing the PC Engine in the same class as NES, because of the type of cpu. The hyperbole comment is just hypocritical gravy. :p
"24-bit Neo Geo" is just brain deadly stupid. Because it was actually marketed that way.
64 sprites could be possible, but I don't think it happens much because you can only have 8 sprites per scanline.
Revised:
http://i.imgur.com/oKrAXcW.png
I know a few released games took full advantage of all 64 sprites (and then some). Summer Carnival '92 - Recca was one of them. And the flickering and 8 sprites per scanline issues were well untruly present.
Which's a bit of an issue when it's almost a bullet hell SHMUP. :p
OK, i like azonicrider comparison pic, but what about their background handling capabilities?, we all know that the 3 systems only have hardware support for one background layer, but what makes the PCE have more detailed backgrounds than SMS, and what allows the SMS to display more detailed backgrounds than the NES?. I think it would be a nice adition to azonicrider specs image.
Also it would be cool to have the sound specs in your image, azonicrider.
OK, here i go with what could be a pretty retarded question:
I always see on the PCE specs that it can display 482 out of 512 colors. That would be 241 colors out of 256 for sprites, and 241 out of 256 for the background. But arent both 256 color master pallettes identical?, and thus, not 512 diferent colors in total? WHAT AM I MISSING!?
(Darn maybe i should have posted under a fake account to save face, hehe)
The PCE has 16 palettes for sprites, 16 palettes for tiles. Every palette can hold 16 colours.Quote:
Originally Posted by saturndual32
So it could technically display 512 colours on-screen, but...
out of the 16 tile palettes, one colour must be the same throughout all the palettes. So that equals 16 palettes of 15, plus 1 colour shared among all those palettes. 16x15+1=241.
out of the 16 sprite palettes, one colour must be transparency. So that equals 16 palettes of 15, plus 1 transparency colour shared among all those palettes. 16x15+1=241.
241+241=482.
The master palette for the PC Engine and Mega Drive, from which all colors are chosen from, is 512 colors. The 16 color palettes used for sprites and tiles can use any combination from the 512.Quote:
Originally Posted by saturndual32
Ah, for some reason i had always tought the PCE and MD master palette was 256 colors. Thanks Black_Tiger.