Color counts per screen

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Exophase
Newbie
Posts: 6
Joined: Tue Feb 10, 2009 10:08 pm

Post by Exophase » Thu Feb 12, 2009 7:52 pm

Snake wrote:Well, my reply was in response to you saying that "4 times as many instructions executed" needed backup. I could have used a loop in my example, but I didn't, because although it would have looked shorter on paper, it would have been more instructions executed. I also pointed out that the 65816 version might be smaller cycle-count wise. Sorry, I thought that was pretty clear.
Number of instructions executed, number of instructions in the code, and cycle times are all different variables. You can easily have fewer instructions that take more cycles, which is what I'm sure you were trying to demonstrate.

For reference on the cycles per instruction matter: Genesis games tend to achieve about 700,000 instructions per second and PC-Engine games about 1.5-1.8 million instructions per second (as I said earlier, PC-Engine is clocked slightly below Genesis). These numbers were obtained by profiling several games; I profiled PC-Engine and Lordus profiled Genesis. The numbers are a little biased given that they're sucking in the idle loops as well (done w/o any kind of idle loop detection/elimination of course) so they have a bit of a BogoMIPS quality to them, but they do include games that are genuinely pushing the CPUs pretty hard on both platforms.

PC-Engine isn't SNES and 65c816 isn't 6280, but the cycle timings should at least be in the same ballpark - 6280 has additional penalties for its memory translation, 65c816 will have 16bit instructions that cost more going over its 8bit bus.

I'm in no way trying to argue that 68k instructions aren't much more efficient than 65c816 ones, I just think that 4x is an exaggeration, I'd expect something closer to 2-3x for well optimized games written with the architecture in mind. But I'm not going to stand by that number because it's so difficult to actually verify. This is for instructions executed and not written, it's obviously worse for written because 65xx demands more inlining and unrolling, and has far less in the way of "macro instructions" that 68k does.
Snake wrote:In a 16 bit game? Most games I've seen scroll 2 pixels per frame or faster. 1 pixel looks very slow. It takes no time at all to scroll 4096 pixels...
What kind of game are you talking about here? If there's a need to store the coordinates for anywhere on the level it means that you have to be able to traverse the level at any given point. If the game is automatically scrolling like a shooter then you don't have this requirement. You also don't have it if the enemies have a limited active/spawn range like many games do (Mega Man games for instance). For a sidescroller, 16 screens for a level, no, for an AREA is plenty. When you reach the edge you can stop scrolling and go to a new region (which many sidescrollers do). You'll also often only be scrolling heavily in one area, although it varies. In most games that actually let you persistently go back and forth between the entire area you aren't going to be constantly scrolling through it, in both directions no less. Of course there are going to be exceptions.
Snake wrote:No, of course I don't, do you have a reference that says they don't? ;)
Just doesn't seem to be something that's necessary based on how typical games seem to be modeled.
Snake wrote:But I know that some do, and I'm sure a LOT do, because contrary to what you might think, it makes perfect sense to do so. However, that doesn't really matter. If you were to look, you'll find a significant number of SNES games use 32 bit addition *somewhere*, even if not for coordinates. I can say that with a lot of confidence. The SNES hardware multiply is insanely quick, and returns a 24 bit result. Games are definitely going to use it, and are definitely going to want to add results - and as I already mentioned, 24 bit adds are more work than 32 bit ones.
I have no doubt that some use 32bit for coordinates, the question is whether or not they really have to. I'm sure that many games do things they don't really have to do.

Yeah, there might be a 32bit addition somewhere, but at least I'm talking about critical code and not just needing the instructions for it at some point. Saying that games are liable to use the 24bit results of a multiplication are like saying that they often use 64bit results for 64bit adds when 32x32->64 multiplies are available - generally speaking, they don't. I mean, they do sometimes, but much less than they don't (games, that is).
Snake wrote:It *IS* a simple add. It's not like it's hideously slow or anything, far from it, and definitely isn't something any SNES programmer would consider a 'bad approach'. It's neccessary, and it's good code. If 16 bit is good enough, you'd do 16 bit on the 68000 too, and it would be faster, and still be less instructions than the 65816 version.

I really wasn't trying to force the issue, but since you don't seem to be convinced, and this isn't a good enough example, I'll give you this one:

Code: Select all

asr.w #4,d0
There, that's deliberately limited to only 16 bit, and something that will almost certainly appear in a lot of games. How many 65816 instructions is that going to take? If someone can do it in 4 or less, and without cheating by using a huge table, I'll be impressed.
I had a feeling you'd get around to using something like this - which is of course a fair argument for the strength of the 68k. However, the problem I have with it is that it's an instruction that doesn't have a constant execution time but scales with the number of shifts - the way I've generally been looking at this (or, the reason why I've been saying anything) is to ascertain an average number of instructions necessary vs an average number of cycles per instruction. When you start using instructions like this it throws off the latter.

Let me reiterate this a little bit. Would your argue that 68k games typically will need less than 1/4th the MIPS to execute an SNES/Genesis era game than a 65c816 game will?
Snake wrote:What if you wanted to fire a missile from any point on the screen to any other point on the screen? To get a missile to move from just off the left of the screen, to just off the right of the screen one scanline lower, you'd need at least 9 bit fractions. You'd definitely want more accuracy than that if you wanted these things moving at different speeds, or changing speeds.

Now you may think that that extreme example of moving just one scanline isn't going to happen often. But you still need way more than 4 bits to get any sort of accuracy here, and do you really want to limit what your game engine can do just to save a few cycles? Please say no.
I didn't realize that a high percentage of SNES/Genesis era games actually let you fire projectiles at such small angles, with many being limited to 8 directions (which don't need any fractional portion at all). Not wanting to limit your game engine is a pretty open ended argument, where exactly do you draw the line? Maybe some engines are just overengineered, but I'm sure that at least back then most of them weren't meant to be extremely versatile and reusable and I think what you're describing isn't a necessity for at least a large number of games (ignoring ones that don't require any kind of precision motion in the first place).
Last edited by Exophase on Thu Feb 12, 2009 8:41 pm, edited 1 time in total.

Snake
Very interested
Posts: 203
Joined: Sat Sep 13, 2008 1:01 am

Post by Snake » Thu Feb 12, 2009 7:57 pm

Exophase wrote:PC-Engine isn't SNES and 65c816 isn't 6280, but the cycle timings should at least be in the same ballpark
Agreed, and is kinda the point. The SNES CPU runs at under half that of the Genesis CPU, at best. It also tends to beat it simply because there *are* lots of very useful instructions that do things that aren't so easy on the 65816, and they're going to get used.
Exophase wrote:it's obviously worse for written because 65xx demands more inlining and unrolling
Again, this speaks for the 68K, and maybe in some instances you simply don't have the room to unroll.
Exophase wrote:Of course there are going to be exceptions.
I would think there are NES games that have areas that large.
Exophase wrote:I have no doubt that some use 32bit for coordinates, the question is whether or not they really have to.
Well no, they don't have to, but it isn't a big deal to do so, it simplifies other areas, and you can get much better results. So why not? As we've already seen, it can be done faster than on the 68K, where nobody would even think twice about doing it.
Exophase wrote:Would your argue that 68k games typically will need less than 1/4th the MIPS to execute an SNES/Genesis era game than a 65c816 game will?
As you've said, this is very difficult to quantify. I can't actually answer that because I've never thought about either system in terms of MIPS. I'm thinking it's at least 1/3rd, though, and could definitely be quite a bit more depending on what the game needs to do.
Exophase wrote:I didn't realize that a high percentage of SNES/Genesis era games actually let you fire projectiles at such small angles
There are plenty of games in which an enemy will fire things directly at the player, and either can be anywhere on the screen. But again that was a very simple example. Most games have things that move in nice smooth curves. 4 bit fractions will make this look pretty nasty, except at very specific, fixed speeds.

Plus, when you have 4 bit fractions, you've got to implement that 'nasty' shift that I mentioned earlier. It really, really isn't worth limiting yourself when the code is no faster.
tomaitheous wrote:I was just saying that unless he's expects the whole part to roll over
Yep, as soon as you move left, or up, i.e. as soon as you're adding a negative number. It will roll every time. Not only expected, but neccessary, for the code to do what it's designed for.
tomaitheous wrote:4bit float gives you a 16 subpixel precision
Yeah, and I've already given you an example that needed >256 subpixels ;) As I said before, there are plenty of games that actually do this.
tomaitheous wrote:I do use 8bit float part - but it's way overkill. It's done for speed reasons.
Well, same with the 32 bit stuff. It is probably more than you will need. But when you can't fit in 16 bits, this too is done for speed reasons. I think you'll find the 8 bit float is way more useful than you realise.
tomaitheous wrote:But my point was, is that you don't need 24+24->24. 24bit is your object position, but do you really need to have an object to move at a rate higher than 256 pixels per frame?
No but you DO need to be able to move -1 pixel. You seem to keep forgetting this. You cannot add a smaller precision value and have negative numbers working. It's just much faster and simpler to do it properly.
tomaitheous wrote:I've always thought that putting a 68k at the same clock speed in the SNES wasn't going to solve the slowdown problems
Oh, hell, no. But I think it's implied that they mean 'a 68K running at 8mhz'. If that would actually work without completely redesigning most of the hardware, that probably would ;)

A 65816 @ 7mhz would have rocked, though.
tomaitheous wrote:It's funny in that you can see the programmer just simulated the 68k registers
:D There may well have been some auto-generated source in there. But I've seen the same thing done in C. Eeep.

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Thu Feb 12, 2009 8:09 pm

Crazy discussion!

Exophase
Newbie
Posts: 6
Joined: Tue Feb 10, 2009 10:08 pm

Post by Exophase » Thu Feb 12, 2009 8:54 pm

Snake wrote:Plus, when you have 4 bit fractions, you've got to implement that 'nasty' shift that I mentioned earlier. It really, really isn't worth limiting yourself when the code is no faster.
In fairness though, you wouldn't convert the number to its integer portion until you display the sprite on the screen (well after the coordinates may have been used several times for other things, for ones even on the screen), and you'd use logical shifts which aren't as slow as arithmetic ones on 65xx (except the ones with ASR instructions).

(sorry about my posts being weird and broken in funny ways, something about this message board hates Google Chrome which I'm using here :/)

HardWareMan
Very interested
Posts: 727
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Fri Feb 13, 2009 3:56 am

Huge wrote:Crazy discussion!
In a dispute born the truth. Let's they go on. ;)

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Sat Feb 06, 2010 9:34 pm

I have been mulling around with this thread since the original discussion and I thought I'd revisit it. I apologize if everybody else would rather keep working on coding projects. I have finally gotten Gamepilgrimage up to the capabilities I was looking for last year and am about to upload about 100 16-bit comparison videos. As I am doing that, and subsequently assigning my new comparison icons http://www.gamepilgrimage.com/content/w ... comparison, I would like to express some of my misgivings with the assertions in this topic.
tomaitheous wrote:
sheath wrote:Couldn't that be said of any system's strengths? [SNES developers] focused on Mode 7 effects and used more simultaneous colors on screen on the SNES. But the fact remains that they didn't use as many frames of animations or background layers in most games.
Sorry if I wasn't clear. That was point :D The fact that they didn't do it meant they felt it hadn't as much value as other visual aesthetics. Having experience with coding on these consoles, I can tell you that setting up raster effects for multiple parallax (like the far BG of green hill zone) is dead simple and not cpu resource intensive. I would put it under 5% of cpu resource per frame for a change on every scanline. On the PCE, it's a little different story. Line scrolls for part or all of the screen and such as just as easy, but overlapping BG layers are not as easy. Since there is only a single BG layer, doing overlapping BG layers requires dynamic tiles and sprites. It can be done, but with all tricks comes limitations. Lords of Thunder on the PCE CD does a good job of hiding that fact.
This is actually a case of a developer going *way* out of their way to develop a game with more scrolling background layers than the system could "technically" do. This would mean that they had a technically challenging task of making Lords of Thunder look technically impressive in the year it was released, and turned primarily to faking parallax to do so.
tomaitheous wrote:
sheath wrote: I would agree with your assessment if I could find any examples of SNES games with backgrounds like Sonic 2, or the number of enemies with constant animation as the SOR games.
Sonic 2 isn't very impressive on a technical level. It's just a line update on one of the BG layers. No different than the fire level of TF3. Nothing the SNES couldn't do just as easily. Space Megaforce is doing the same thing, just looks different - but on every scanline. As far as animation, the CPU isn't 'drawing' the frames into memory. On both systems(SNES & GENs), the video processor has a DMA that handles super fast transfers to VRAM. This is all done during off screen. So the slower CPU speed of the snes has no relation to the rate of animation in that respect. It's just a matter of cartridge space. I can't think of any good examples at the moment. Check out Anomie's doc. Mode 1 has a 3rd BG layer. The SNES could do the Ocean side level of TF4 and even add to it. The Ocean side level is still just two BG layers, but updated X scroll register at key points to give the illusion. Notice the clouds are static in position to each other as the screen scrolls. If you look closely, you can see the 'line' (not literally) were the layers don't overlap into 3 different ones. Matter of fact, the boss ship requires the game to strip one of the layers because it itself is using a BG layer.
It seems like you have a definition of "technical" that is different than the one I am using. People, including editorialists, are impressed when a system demonstrates some effect that they hadn't seen before. This is exactly what Sonic 2 did, and does for the entirety of the 16-bit generation. Nothing on the SNES even approaches the level of background layers in Sonic 2, Sonic 3, Thunder Force IV, Ranger X, or their others. The same statement could be reversed to say that nothing on the Genesis/Megadrive displayed Mode 7 style effects to the same effect.

A unique effect is simply that in regard to measurement. None of the popular comparisons are trying to say that one effect took less CPU cycles and was therefore less impressive. Similarly, none of the comparisons are attempting to compare amounts of code to see which was more "technically" impressive. In fact, editorialists and system fans are merely expressing their own opinion of what they felt was more impressive at the time.

I, in turn, am trying to take said references to impressiveness and record them.
tomaitheous wrote:
sheath wrote: I suspect that displaying more simultaneous colors on screen hogged more system resources than if the games ran at Genesis color counts.
That's a common misconception. That the additional colors of the SNES or PCE or whatever system take up more 'resource' or processing power. That's just a myth. Because the tiles/sprites are all 16 color objects with sub palettes, having more sub palettes takes no additional storage or processing power. The PCE has 16 sub palettes for tiles and another 16 sub palettes for sprites. A total of 32 sub palettes or 482 unique colors on screen. It's simple multiplication. The object pixel * the palette number. You have to use a palette # regardless and it takes no extra cpu or video processing power to multiply a 1-4 or 1-8 or 1-16. The PCE graphic style of most games are simplistic because of the appeal. The PCE beat out the FC(NES) in Japan and lived on that simplistic design for quite a bit of its life. Minus a few exceptions, it was mostly later games that started to get away from that trend. A Genesis artist/developer would "hardly squander" the chance to show as many colors on screen as the PCE, and yet PCE developers did just that ;)
The PCE has 32 total sub palettes, or 482 colors, and yet no PCE title displays more than 96 colors simultaneously, even in a static screen. So at best the PCE actually displayed only two more sub palettes on screen simultaneously. That is very interesting considering the average ROM sizes of PCE ROMs in comparison to early Megadrive/Genesis ROMs. This is especially interesting given that the first time I heard the term parallax was from a set of TG16/Amiga fans who insisted this was "proof" of their preferred systems superiority.
tomaitheous wrote:
sheath wrote:Anecdotal evidence that I'm right would be arcade versions of Genesis titles that lack parallax levels like Altered Beast. I'm not going to assert that this argument must be true until better evidence surfaces. But the fact remains that systems that use 90-150 colors, short of NEO GEO, just don't have as many animations or background layers/details as Genesis games do.
Like I said, it's just a matter of style. You really think other systems (including arcades) couldn't handle the same type of scrolling effects? If you don't have experience with console coding, you'd probably think so(I've seen this mentioned on youtube by sega fans). To me, a lot of Genesis/Megadrive games abuse/overuse parallax scrolling.
My issue at this point is with your assertion that the lack of parallax on other 16-bit systems is an aesthetic choice. This simply cannot be correct.

From an artistic perspective, real life and cinema display "line scrolling" and "parallax" when watching scenery from a moving side view. From a gaming perspective, 2D games maxed out in the NEO GEO, Saturn and Dreamcast, all of which use heavy amounts of background layers to increase the "technical impressiveness" of their titles. Finally, even current gen 2D games like Castle Crashers and Muramasa: The Demon Blade use background layers to increase the impressiveness of the title. (http://www.gametrailers.com/video/revie ... 8?type=flv. That's not even considering the heavy use of 2.5D games in arcade remixes such as Turtles in Time and R-Type, which again feature more background depth than their originals.

So, regardless of whether the "excessive use" of background layers in Genesis titles was "technically" impressive from a coder's standpoint, it was, and is, most definitely impressive from an artistic or gaming standpoint.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Tue Feb 09, 2010 3:59 am

The PCE has 32 total sub palettes, or 482 colors, and yet no PCE title displays more than 96 colors simultaneously, even in a static screen. So at best the PCE actually displayed only two more sub palettes on screen simultaneously.
Than what? The Genesis? You obviously don't understand limitations of a subpalette system. Subpaletted systems have redundant colors, and on the Genesis this is even more so. While you can get 61 unique colors from the Genesis subpalette - that's hardly applicable. You get more into the 30-40 range because of redundant colors. If you have 8 subpalettes for the Genesis, then you'd get into the 60-80 range on a realistic level. You see, just because you can show more colors doesn't mean you want to. I can tell you from an artistic point of view, the smaller your master palette is (512 colors), the more limited range of groups of colors you have - that don't clash. The perception of colors, or more accurantely hues and luminance, are relative. Colors subtract from each other (be it their perception of hue or luminance). So it's more limiting of the "bands" of colors you can put onscreen on a setting.

While I understand it and work with it, it's hard to explain but I'll try my best. Take the color brown for example. There are many types of brown. There are many types of brown, warm brown, cool brown, red brown, green brown. The colors next to such browns (as pixels), will either pronounce the contrast or pronounce the tone of the color. You can effectively use greenish browns as normal browns, without the perception of them being as such, as long as you use other colors with tones that don't bring the green out. When you have 16 million colors to chose from, this really isn't a problem. When you only have 512 colors to choose from, this tends to limit you. So thus, while you might have a whole subpalette of 15 colors (ignoring the single common one or transparent one) to use on a tile for brown - it's highly unlikely that you'll be able to produce that many usable tones of the same color in such a tile. With 4096 colors, it's much less restrictive and with a 32k master palette - the problem is almost non existent.

So master palette is one restriction in real world application. I mean, you have a certain range of color temperature you want to use for the game, or even just for a level, or what not. I could easily draw out a "to spec" mock up showing more than 96 colors without regard to this. And there are games that have more than 96 colors onscreen. I don't have access to my cache of screen shots at the moment, but I do have these few:

http://img684.imageshack.us/img684/3354/38111181.png (124 colors)

http://img268.imageshack.us/img268/5497/68988695.png (111 colors in that shot)

http://img269.imageshack.us/img269/3738/66ext.png (114 colors, same image as above - but this is it not scrolling. The image expanded).

While those might be static images, and that might seem like an advantage - it's actually not. There's no tricks going to display those shots (no dual BGs overlapping either to improve color usage efficiency. Just a single BG layer/tiles) and you could easily add sprites with their own 16 subpalettes ontop of those images to increase the color counts - if they have felt the need to do so.

http://img192.imageshack.us/img192/9314/40624737.png (107 <- this one actually uses one 15 color subpalette for the sprite "game title" overlay)

Anyway, even if a game only uses 40-50 color count range on the PCE. It doesn't mean the same thing on the Genesis. Subpalettes have more limitations than just the screen color count. Having a small amount of subpalettes on a system means reducing the number of colors an object can have. And thus, less detail. 40 colors on 32 subpalettes is not the samething as 40 colors on 4 subpalettes. And you also have to take into account such things as color/palette cycling for animation or color/hue/lumi flashing on specific target enemies. Something I have to remove from my Bonk project I was doing for the Genesis ( there was just no room for that from the original game, left over for the current level+sprites - unless I wasted vram by replicating the same frame but with hardcoded pixels and that would still be limiting). A simple game like Bonk and the very first level, I had to cut colors and combine colors because even that limited looking style of the original Bonk game wouldn't fit as is.

So in other words, two more subpalettes isn't going to get the Genesis to "96" colors. It's soo much more complex than that. And you can't just say, "Oh, that's only 40 colors or so. So it's no problem on the Genesis" or such. Like in the example of your old website where you take a snap shot and reduce it to 64 colors to simulate with it would look like on the Genesis. That's just completely incorrect.



That is very interesting considering the average ROM sizes of PCE ROMs in comparison to early Megadrive/Genesis ROMs.
I'm not sure what the rom size has to do with subpalettes. The small amount of default ram on the original system had something to do with compression types they used (that's for sure) - and thus did result in quite a bit of 7-8 colors tiles/sprites in early hucard games - instead of 15/16 color tile/sprite cells. Though, that was their own fault. I was easily able to make a circular buffer for LZSS on that 8k of ram by just using 512bytes - with significant increase of compression over there stuff. Most tiles stay in vram during a level, so there's no need for a cache in main ram. Even quite a bit of sprite frames can be kept in vram for a level, or dynamically change/swapped out as you progress. Gate of Thunder does just this for the enemy sprites - decompresses LZSS files as a back ground process as the game is running (all on the same CPU though) - then updates vram in between. But then again, that's an optimized game. Most pce games are minimal effort, especially early on. Couple that with most hucards being in the 512k range because of the early jump to CD. The handful of later 8megabit hucards seem appropriate for their size though. Raiden comes to mind.
My issue at this point is with your assertion that the lack of parallax on other 16-bit systems is an aesthetic choice. This simply cannot be correct.
I'm sorry, but it is. Is either that or they were just lazy. And that's bullshit, because there are many high production value games on the snes - no to mention higher competition between companies on that platform. While scrolls might look great to you and impress you, they AREN'T impressive technically. Matter of fact, I personally think the SNES HMDA is a more efficient method than the Genesis linescroll table. At least on the SNES, you don't waste time updated EVERY entry for every scanline - on BOTH BG layers. If you don't want to take my word for it, then learn to code for yourself. Learn the system specs. Write test demos, etc. Until then, all you have is inaccurate speculation. Not trying to be an ass, just calling it like I see it. You're the one that's trying make accurate comparisons between the systems. It's up to you to dig deep, get dirty, and really learn these systems on a programmer's low level of understanding. Else, it's little more than speculation by observation with a false authoritative tone in presentation. Something we've seen across the 'net for ages. Well, you've got to at least learn some of the overlaying fundamentals of how the graphics work :)

This is actually a case of a developer going *way* out of their way to develop a game with more scrolling background layers than the system could "technically" do. This would mean that they had a technically challenging task of making Lords of Thunder look technically impressive in the year it was released, and turned primarily to faking parallax to do so.
Correct. Given what the target audience on the system finds acceptable and balance that with the other competitive companies developing for the system, then you have an idea of how much "work" is considered reasonable (time/cost/etc) across that platform. You find quite a bit low production value games, or just minimal effort (relative, more like "average") on the low level design - for the PCE. The PCE wasn't competing with the Megadrive in Japan (which was a distant third of the three at the time). It was competing with the Famicom. And then, the Super Famicom when it came out. When the SFC came out, that's when you started to see a trend of developers moving away from the simplistic design similar to that of the famicom (i.e. treating the PCE as a famicom with graphic/sound extensions), to a more up to date game design. It's not as back and white as that, but you can pretty much see the trend. Still, while Hudson had some AA titles late in the PCECD's life - they still never really approached the high production value of game design that quite a few SFC developers achieved. But, that starts to get into a different topic than just technical capabilities. :D
It seems like you have a definition of "technical" that is different than the one I am using. People, including editorialists, are impressed when a system demonstrates some effect that they hadn't seen before. This is exactly what Sonic 2 did, and does for the entirety of the 16-bit generation. Nothing on the SNES even approaches the level of background layers in Sonic 2, Sonic 3, Thunder Force IV, Ranger X, or their others. The same statement could be reversed to say that nothing on the Genesis/Megadrive displayed Mode 7 style effects to the same effect.
Ok, assuming you know what I know and on that low of understand.. how would you explain it? I know for a fact that the SNES can do more such "scroll" effects because it has an additional BG layer in mode one (even if it has only 3/4 colors per tile and 8 subpalette - it's significant when it comes to the overlapping layers possible). I also know for a fact that the SNES can do exactly the *same* scroll effects as the Genesis as well (this should be apparent, if it can *more*). I mean, just ignoring all the other features of the sPPU regs (and some less apparent than just mode 7 or color math/transparency) - which out number the Genesis in features, it can at minimum do that same scroll effects as the Genesis. The SNES has ~60,000 cpu cycles per frame. Scrolls are nothing more than adding an incrementing/decrementing value to a base value per *one* scroll width. If you have 10 divisions on one BG layer and 10 divisions on another BG layer, that's a total of 20 adds you have to do. If you made some absurd case scenario saying that it took atleast 100 cycles per add function (which is overkill), that would only be 2000 cycles or 3% cpu resource for that frame. I think in one of my posts, I suggested 5% or less - so that's even more room for whatever. In real world, you'd optimized a routine to remove redundant steps. So tell me, *why* do you think a developer wouldn't "push" as much scroll on the SFC developed game than on the Genesis? The answer is really obvious to me. Given SFX (and color) differences between the two system, with the Genesis having significantly less, you'd expect it to push or show would it could to stand out. It developers would put importance/focus on what they had to work with hardware wise. SNES capable SFX are *very* distinguishable from Genesis capabilities. I've already explained PCE's reasons. So given the information of what I said is correct and true (I know you doubt me, go along on this), what logical conclusion would you come to? It's not like SNES games are devoid of scrolls. On the contrary, they have scrolls. They just don't take it to the extremely, but they *do* take other effects to the extreme. Many games do. It's just so obvious for me to see. So please excuse any frustration that comes across in my points ;)

From an artistic perspective, real life and cinema display "line scrolling" and "parallax" when watching scenery from a moving side view. From a gaming perspective, 2D games maxed out in the NEO GEO, Saturn and Dreamcast, all of which use heavy amounts of background layers to increase the "technical impressiveness" of their titles. Finally, even current gen 2D games like Castle Crashers and Muramasa: The Demon Blade use background layers to increase the impressiveness of the title. (http://www.gametrailers.com/video/revie ... 8?type=flv. That's not even considering the heavy use of 2.5D games in arcade remixes such as Turtles in Time and R-Type, which again feature more background depth than their originals.
Modern 2D games have a whole different focal point. They look beautiful in some instances *and* overly distracting in others and even maybe a bit unnecessary other situations - but they have something to compete with... 3D. It *has* to stand out. If it's 2D in this day and age, it better be flashy or it fails. In the most incredible way possible. If not, it plays off the exact opposite along with something addictive yet simple for gameplay mechanics.

On a side note; you really thought that the SNES couldn't handle the far BG layer of Sonic!? While I wasn't a console coder back then, I never thought that for an instant. Never crossed my mind. If anything, as the SNES grew in age - it seemed like it could show more unique BG detail than the Genesis. The Genesis was starting to show it's age in that respect (I just remember the detail in FF6 was incredible at the time and the other systems didn't come anywhere near that. Some other games too at the time).

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Tue Feb 09, 2010 3:24 pm

The PCE has 32 total sub palettes, or 482 colors, and yet no PCE title displays more than 96 colors simultaneously, even in a static screen. So at best the PCE actually displayed only two more sub palettes on screen simultaneously.
Than what? The Genesis? You obviously don't understand limitations of a subpalette system. Subpaletted systems have redundant colors, and on the Genesis this is even more so. While you can get 61 unique colors from the Genesis subpalette - that's hardly applicable. You get more into the 30-40 range because of redundant colors. If you have 8 subpalettes for the Genesis, then you'd get into the 60-80 range on a realistic level. You see, just because you can show more colors doesn't mean you want to. I can tell you from an artistic point of view, the smaller your master palette is (512 colors), the more limited range of groups of colors you have - that don't clash. The perception of colors, or more accurantely hues and luminance, are relative. Colors subtract from each other (be it their perception of hue or luminance). So it's more limiting of the "bands" of colors you can put onscreen on a setting.
Right, I have noticed that most Genesis screens, even in the more colorful ones are in the 50-55 range, and I was already aware of the transparent color and four palette limitation per screen (barring mid screen palette swaps of course). What you're saying is that it was relatively difficult for developers of Genesis titles to even get 55 colors because on the PCE/TG16 they had 32 palettes "available".

I am, in turn, saying that if there are only 96 colors on screen simultaneously that is only 16x6, but you are correct that I oversimplified. Not only are their 32 more colors, but all 96 colors could be pulling simultaneously from 482 colors (though each object can technically only pull from one 16 color palette). The only way I could represent this fact is to simply point out that their are more unique colors on screen. Does that merit it's own point when simply awarding the PCE game the "more colors" award is still true? If we were talking about a painted canvas, wouldn't you think I was getting into the minutia if I told you how many colors the artist had in the room while he was painting it?

It is interesting, I agree, and if I could document exactly how many palettes were being pulled from in every game, easily, I probably would.

On a side note, I have never used that animated gif of lowering color counts to demonstrate what a cross platform port would look like. I only used this as an example of how even software sees more colors in Genesis titles when the shots are taken from the AV Composite out. I intend to expand on this in my comparisons, using Irfanview to show what the actual output color comparison is versus the emulation/chip output.
(snip for citation purposes, I read it all)

Anyway, even if a game only uses 40-50 color count range on the PCE. It doesn't mean the same thing on the Genesis. Subpalettes have more limitations than just the screen color count. Having a small amount of subpalettes on a system means reducing the number of colors an object can have. And thus, less detail. 40 colors on 32 subpalettes is not the samething as 40 colors on 4 subpalettes. And you also have to take into account such things as color/palette cycling for animation or color/hue/lumi flashing on specific target enemies. Something I have to remove from my Bonk project I was doing for the Genesis ( there was just no room for that from the original game, left over for the current level+sprites - unless I wasted vram by replicating the same frame but with hardcoded pixels and that would still be limiting). A simple game like Bonk and the very first level, I had to cut colors and combine colors because even that limited looking style of the original Bonk game wouldn't fit as is.

So in other words, two more subpalettes isn't going to get the Genesis to "96" colors. It's soo much more complex than that. And you can't just say, "Oh, that's only 40 colors or so. So it's no problem on the Genesis" or such. Like in the example of your old website where you take a snap shot and reduce it to 64 colors to simulate with it would look like on the Genesis. That's just completely incorrect.
Okay so, now you're saying that achieving 50 colors on the Genesis is technically incomparable to the PCE displaying the same amount of colors. If I were arguing from a perspective of "which system/game was pushing the system harder" I'd see your point. I am not arguing from that perspective. If I were to open the games up in an emulator and each emulator were to show me which colors were being used, what would I see (in the 50 MD to 96 PCE comparison I mean)? Even if the PCE is "pulling from" 16 palettes in the background, it's still only displaying 96, or up to 128 as you seem to be asserting.

That is very interesting considering the average ROM sizes of PCE ROMs in comparison to early Megadrive/Genesis ROMs.
I'm not sure what the rom size has to do with subpalettes. The small amount of default ram on the original system had something to do with compression types they used (that's for sure) - and thus did result in quite a bit of 7-8 colors tiles/sprites in early hucard games - instead of 15/16 color tile/sprite cells. Though, that was their own fault. I was easily able to make a circular buffer for LZSS on that 8k of ram by just using 512bytes - with significant increase of compression over there stuff. Most tiles stay in vram during a level, so there's no need for a cache in main ram. Even quite a bit of sprite frames can be kept in vram for a level, or dynamically change/swapped out as you progress. Gate of Thunder does just this for the enemy sprites - decompresses LZSS files as a back ground process as the game is running (all on the same CPU though) - then updates vram in between. But then again, that's an optimized game. Most pce games are minimal effort, especially early on. Couple that with most hucards being in the 512k range because of the early jump to CD. The handful of later 8megabit hucards seem appropriate for their size though. Raiden comes to mind.
They were probably also porting/adapting from the Famicom source with the early stuff, this kind of thing happens every generational switch. Nonetheless, even though developers had 32 palettes to choose from, they never tried to display them all. In order for a PCE game to do so we'd have 32 sprites or background elements using entirely different palettes. This could have been done in game sprites, creating greater diversity in enemy character colors, or in background elements, creating different color trees. But they didn't and the only correlation I can find is ROM size. Are you saying that one object with one palette and another object with another palette wouldn't require their own space in ROM?

I'm only a web coder, but I honestly cannot see how a system could display two objects with two entirely different palettes and use the same block of code. I know this could be done on the same palette, but two entirely different ones meant to be on screen at once?
My issue at this point is with your assertion that the lack of parallax on other 16-bit systems is an aesthetic choice. This simply cannot be correct.
I'm sorry, but it is. Is either that or they were just lazy. And that's bullshit, because there are many high production value games on the snes - no to mention higher competition between companies on that platform. While scrolls might look great to you and impress you, they AREN'T impressive technically. Matter of fact, I personally think the SNES HMDA is a more efficient method than the Genesis linescroll table. At least on the SNES, you don't waste time updated EVERY entry for every scanline - on BOTH BG layers. If you don't want to take my word for it, then learn to code for yourself. Learn the system specs. Write test demos, etc. Until then, all you have is inaccurate speculation. Not trying to be an ass, just calling it like I see it. You're the one that's trying make accurate comparisons between the systems. It's up to you to dig deep, get dirty, and really learn these systems on a programmer's low level of understanding. Else, it's little more than speculation by observation with a false authoritative tone in presentation. Something we've seen across the 'net for ages. Well, you've got to at least learn some of the overlaying fundamentals of how the graphics work :)
I don't see the need for the extreme comparison of either "it isn't aesthetically pleasing", or "SNES devs were lazy". I think it makes plenty of sense that they would be focusing on more colorful games, especially since SNES devs were transitioning primarily from NES development. When you jump from NES to SNES, and see all of the possibilities of the hardware, plus Mode 7 effects, I can see the focus shifting away from "traditional" 2D effects.
It seems like you have a definition of "technical" that is different than the one I am using
Ok, assuming you know what I know and on that low of understand.. how would you explain it? I know for a fact that the SNES can do more such "scroll" effects because it has an additional BG layer in mode one (even if it has only 3/4 colors per tile and 8 subpalette - it's significant when it comes to the overlapping layers possible). I also know for a fact that the SNES can do exactly the *same* scroll effects as the Genesis as well

(snip)

So tell me, *why* do you think a developer wouldn't "push" as much scroll on the SFC developed game than on the Genesis? The answer is really obvious to me. Given SFX (and color) differences between the two system, with the Genesis having significantly less, you'd expect it to push or show would it could to stand out. It developers would put importance/focus on what they had to work with hardware wise. SNES capable SFX are *very* distinguishable from Genesis capabilities. I've already explained PCE's reasons. So given the information of what I said is correct and true (I know you doubt me, go along on this), what logical conclusion would you come to? It's not like SNES games are devoid of scrolls. On the contrary, they have scrolls. They just don't take it to the extremely, but they *do* take other effects to the extreme. Many games do. It's just so obvious for me to see. So please excuse any frustration that comes across in my points ;)
Your assertion was that parallax (especially excessive) is aesthetically unpleasing, this cannot be correct. I am not challenging your assertion that the SNES could have done line scrolls to simulate excessive parallax, nor your implication that production level SNES games had 4-5% CPU freely floating in technical space. I am saying that the SNES has not one example in game of doing so, which is a fact. I can speculate that the reason SNES devs *never* did it is because they couldn't. But then I could only say I don't know why they couldn't. You have speculated instead that SNES devs thought excessive parallax was ugly or distracting. More below...

From an artistic perspective, real life and cinema display "line scrolling" and "parallax" when watching scenery from a moving side view...
Modern 2D games have a whole different focal point. They look beautiful in some instances *and* overly distracting in others and even maybe a bit unnecessary other situations - but they have something to compete with... 3D. It *has* to stand out. If it's 2D in this day and age, it better be flashy or it fails. In the most incredible way possible. If not, it plays off the exact opposite along with something addictive yet simple for gameplay mechanics.

On a side note; you really thought that the SNES couldn't handle the far BG layer of Sonic!? While I wasn't a console coder back then, I never thought that for an instant. Never crossed my mind. If anything, as the SNES grew in age - it seemed like it could show more unique BG detail than the Genesis. The Genesis was starting to show it's age in that respect (I just remember the detail in FF6 was incredible at the time and the other systems didn't come anywhere near that. Some other games too at the time).
I'm not just talking about simple stuff like Sonic 1's water scrolling, I'm talking about specific levels in Sonic 2 or Thunder Force IV that show 8+ independently scrolling overlapping layers (in some games/levels they even react to player movement). In Thunder Force IV it's all force scrolling, but there are so many layers they are hard to count. This is what the SNES never did in game, regardless of whether it would have been easy to do so.

Now, you've given a couple of examples that actually contradict your point on parallax not appealing to aesthetics. Later gen PCE CD games, Genesis games, and modern 2D games all turned to parallax to compete visually with something perceived as technically superior. Be it the wondrous SNES or the shift to 3D. I am not contesting the fact that both the SNES and 3D are seen as superior to these effects. The fact that "excessive scroll" was and is used for this purpose disproves your point on aesthetics. If most people see the backgrounds move in more than four layers and get jolted out of the experience, as you appear to be, then 2D wouldn't have progressed in this way.

Furthermore, the SNES saw full scale development past the transition to 3D, and still didn't follow this trend. I could assert that it must be because it couldn't while maintaining the devs other artistic focus (like "excessive" colors). That would just be speculation on my part. If your assertion were correct, and more colors on screen was tantamount, Genesis, and especially PCE, developers would have likewise focused on every artistic approach possible to increase the perceived color limit.

The Weoponlord comparison I cited is how I am approaching comparisons. I simply want to document which games did what, and leave the observations up to the reader. If somebody looks at After Burner II on Genesis and After Burner on PCE and thinks one looks better than the other, or sounds better than the other, it's just an opinion. If I document that one had 50 colors on screen and the other 65, and that's the only measurable difference I can come up with, that's the only thing I will document in that comparison.

When I read SNES biased articles, or "classic gaming" articles about the TG16, they claim that the "technical limitation" was actually what the games used. Ignorant readers in turn take it as fact and lose all objectivity in regard to these systems. I have observed that the actual limitation of SNES and TG16 games is less than 1/4th of their "technical limitation", which is only two to three times the colors of Genesis/MD software per screen.

When a consumer looks at a SNES/Genesis comparison and says one looks more colorful, they aren't staring through the code at sub palettes. They might be noticing that different objects look more distinct from the background, or that one has more diverse background elements, but that's as far as it goes. It is indisputable that more colors = better, I am disputing that there were as many more colors as people commonly think between 16-bit systems. I am also disputing that various graphical effects really had a visual edge in this generation, but that is probably a different rabbit hole.

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Tue Feb 09, 2010 10:56 pm

Or to sum it up in a single sentence:

Good graphics are not about what the hardware can do, but what programmers are willing to make the hardware do.

MottZilla
Interested
Posts: 40
Joined: Mon Feb 08, 2010 9:54 pm

Post by MottZilla » Thu Feb 11, 2010 1:54 am

It's still related to what the hardware can do. Certainly if you put the effort into whatever you are doing you can get better results within your hardware limitations than if you are lazy. But eventually it will come down to what the hardware can do.

I'm not sure who said it but it was probably tomaitheous. If Sega had just given BG and Sprites their own four 16-color palettes, it could have had a dramatic improvement in color depth in games. And I can't imagine such a change would have impacted cost at all or atleast not anything significant. Even if it did it would have been well worth it to expand that capability. I imagine if they had you wouldn't see people today comparing Genesis and SNES color usage in the negative way they do against the Genesis.

But I suppose to be fair the system was designed long enough ago that perhaps they couldn't grasp needing that much color yet.

Do you suppose it would be possible someone could clone the VDP and add in that change to make a drop-in replacement VDP with extended palette ability? That would be pretty cool, so long as there was some sort of backward compatability assurance so the same Genesis console could run existing software as well as hacks or new software with twice the available palette colors at once.

TmEE co.(TM)
Very interested
Posts: 2370
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Thu Feb 11, 2010 3:34 am

The VDP supports different paletes for sprites and BGs, but you need external CRAM and RAMDAC for it like some arcade HW got that uses exact same VDP that MD uses.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Thu Feb 11, 2010 3:36 am

I look at that discussion like this. I just performed my first mod to a system for the purpose of including the YM 2413 in my 1986 model Sega Master System. I was happy with my Master System already, now I can play it two ways with a great many games.

Similarly, back in the day I bought a Sega CD to accompany my Genesis 1. I also bought a 32X the month it launched. Both of these add-ons enhance my Genesis, which I am already happy with on its own because of the great games I can play.

If I could change history (and reality) by having Sega release a System 16 home console with scaling and rotation and the same color limitations for the same price I would. The $700 NEO GEO (three years after the Megadrive) tells me that wasn't possible from an engineering or marketing standpoint.

Furthermore, I bought my Genesis 1, Sega CD 1 and a 32X at launch and they still cost less than a NEO GEO did, and consumers still rejected both add-ons. So, I suppose there must have been intelligent reasons behind the final Genesis/Megadrive hardware selections, and I appreciate the pains developers went to keeping it competitive for seven to eight years.

MottZilla
Interested
Posts: 40
Joined: Mon Feb 08, 2010 9:54 pm

Post by MottZilla » Thu Feb 11, 2010 5:12 am

TmEE co.(TM) wrote:The VDP supports different paletes for sprites and BGs, but you need external CRAM and RAMDAC for it like some arcade HW got that uses exact same VDP that MD uses.
Well you know what I mean in that having more sets of colors to use for sprites and tiles could have gone a long way. Afterall the NES has 8 sets of 4 colors (counting 0). The Genesis only having 4 sets of 16 colors seems inexcusable to me. I really would love to know why they let this be. I can let the relatively limited global palette pass but the palette sets you apply to BG and Sprite tiles should certainly have been more than that. It sounds like PC-Engine went overboard, Genesis didn't go far enough, and SNES seemed to get into a good sweet spot for number of color sets. 4 more sets of palettes, just half of what the SNES had, would have been plenty.

I know it's easy to be critical of them now knowing how history went but I think even back then Sega should have known better than to let that detail pass by.

Plenty of games make you not even think about limited color. Honestly games like Sonic and Streets of Rage never made me think they were having trouble with color limits. But other games made it painfully obvious like Mortal Kombat. It was made worse when compared to the SNES. Although Genesis will always have a point in even with inferior graphics and sound in MK1, the gameplay was spot on and the SNES port had seriously bad gameplay and the better graphics and sound couldn't make up for that.

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Thu Feb 11, 2010 6:01 am

Inexcusable is a very strong word when we have no facts to add to the discussion. The consensus in this group seems to be that both the PCE/TG16 and SFC/SNES could do all of the effects, and scroll speed, seen in numerous MD/Genesis games. In my experience, no PCE or SNES games display more than 32 more colors on screen while displaying similar effects to "technically inferior" Megadrive titles.

By similar effects I mean the "excessive parallax" mentioned in this thread and other 2D software effects which clearly reached their peak in MD software.

This is what we need to know to make the MD hardware configuration "inexcusable". Did Sega turn down an alternative that would have done what we want without increasing the manufacturing costs? Are there any games for the TG16 or SNES that demonstrate the effects shown in Sonic 2-3&K, Streets or Rage 2, Thunder Force IV, Ranger X or others? If there are, do these games display over 100 colors simultaneously?

Provided my experience in this matter is complete, I say no such evidence exists to pronounce the Genesis/MD hardware "inexcusable".

Eke
Very interested
Posts: 856
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Feb 11, 2010 8:24 am

MottZilla wrote:The Genesis only having 4 sets of 16 colors seems inexcusable to me. I really would love to know why they let this be. .
The answer is memory size: Color RAM has room for only 64 colors, that's it.
Bigger embedded memory probably would have been too expensive or not doable at this time. This was probably a design choice, all is about compromise between features/cost, same as todays.

It's very easy to look now and say "it should have been like this or like that" especially when you don't really know about the technology or the restrictions they had when designing a videogame system. :wink:

Post Reply