PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
NEC PC-Engine/SuperGrafx => PC Engine/SuperGrafx Discussion => Topic started by: c0ldb33r on September 03, 2013, 02:21:15 PM
Title: what was the supergrafx actually capable of? do we really know?
Post by: c0ldb33r on September 03, 2013, 02:21:15 PM
There were only 5 actual releases. Unfortunately these early releases look like normal PCE games. Given the short lifespan, game designers never got a chance to push the system.
What was the system actually capable of? Do we know?
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Tatsujin on September 03, 2013, 02:39:14 PM
But I'll let the more versed peeps speak for me :mrgreen:
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: SignOfZeta on September 03, 2013, 02:47:11 PM
I predict a riot.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Black Tiger on September 03, 2013, 03:26:26 PM
The only perceivable difference from a player's perspective, is that it has one extra tile and one extra sprite layer. So It can do backgrounds like the Genesis for the most part. Having twice as many sprites means that you'd never see any flicker/break up. There's more ram to make it easier to make full use of the extra hardware, but the PCE already did great with a small amount of ram.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: spenoza on September 03, 2013, 03:28:18 PM
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Joe Redifer on September 03, 2013, 08:56:45 PM
God damn I wanna see R-Type on the SuperGrafx. Proper dual layer scrolling, no flicker, TG-16 tunes. Hell yeah! That would be better than the arcade in every conceivable way. I mean I already like the TG-16 version better.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: c0ldb33r on September 03, 2013, 11:48:47 PM
God damn I wanna see R-Type on the SuperGrafx. Proper dual layer scrolling, no flicker, TG-16 tunes. Hell yeah! That would be better than the arcade in every conceivable way. I mean I already like the TG-16 version better.
Amen. SGX R-Type would be epic.
I found a tech demo done for demo days in 2012 done on SGX hardware, it looks pretty good. The number of sprites that its pushing at the 1:02 mark is impressive.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: ccovell on September 04, 2013, 03:34:45 AM
:-" :-" :-"
and
(http://www.chrismcovell.com/images/Frac08.png)
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: PunkicCyborg on September 04, 2013, 03:46:45 AM
Are any of the sgx tech demos playable on an actual system using an everdrive?
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Black Tiger on September 04, 2013, 05:28:32 AM
Are any of the sgx tech demos playable on an actual system using an everdrive?
All the legit ones worked on other flashcards.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Mathius on September 05, 2013, 02:39:55 AM
This has always interested me too. Not to beat a dead horse but it's so sad that Strider never materialized for the system. I think that could have really raised the bar as far as the SGX's power is concerned. I mean, we could be here comparing screenshots between the MD, arcade and SGX! Damn. I just typed my way into a deep depression.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: nodtveidt on September 05, 2013, 04:25:44 AM
There are only three major differences (that I know about) between the SGX and the PCE:
-Two HuC6270As as opposed to a single HuC6270 (this also doubled its VRAM, giving it 128KB in total) -The addition of a HuC6202 (video priority chip) -The work RAM was increased from 8KB to 32KB
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Arkhan on September 05, 2013, 04:34:01 AM
take the PC Engine
now double it.
thats what the SGX can do. If you see 10 layers in a game, IT COULD HAVE HAD TWENTY.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: VenomMacbeth on September 05, 2013, 02:37:24 PM
I weep for Galaxy Force (or rather, the lack thereof.) Would have blown the Genesis version out of the water for sure.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Tatsujin on September 05, 2013, 06:34:53 PM
Imagine a SFX with playing a cd-rom game that takes advantage on the arcade card too. Would be great.
Imagine how great those SNK fighters would have turned out if they were designed for SFX not PCE.
Very few people have this kind of setup. The only ones I can think of off the top of my head are ParanoiaDragon and probably ccovell... maybe BlueBMW.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Joe Redifer on September 06, 2013, 06:10:18 PM
What is that Axelay stretchy effect called? Obviously it's not Mode 7. I assume it's pretty easy for the system to do. Hell, Chris' SuperGrafx demo does it BETTER than the Super Nintendo does it. On the SNES version, one of the layers always "flattens out" about 3/4ths from the bottom of the screen and doesn't "curve" any more. Chris' demo curves all the way from top to bottom on BOTH layers. AND it has a full screen boss on top of that.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: ccovell on September 06, 2013, 08:37:35 PM
scanline v-scroll adjustment
or
raster-based stretching
etc. It's easy enough to do, but the CPU still has a fair amount of its cycles stolen each scanline due to the H-Sync interrupts needed.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Bonknuts on September 07, 2013, 01:30:47 AM
Each demo is doing a different type of effect (second demo uses the window function with an hsync effect to animation; much like some early window effects on the SNES).
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: seieienbu on September 07, 2013, 06:07:41 PM
So, this 6202 chip, I take it that's what controls all of the supergrafx's new video functions? What all can it do?
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Tatsujin on September 07, 2013, 06:17:20 PM
it probably just brings the two HuC6270A together? Like a mixer.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Bonknuts on September 07, 2013, 07:48:16 PM
So, this 6202 chip, I take it that's what controls all of the supergrafx's new video functions? What all can it do?
It has two functions. The first function is obviously to mix the two video outputs together. There are two chips in the PC-Engine; the VDC (draws the sprites and background) and the VCE (holds the colors and palette ram, outputs RGB and composite signals). There's a digital 'pixel' bus between the VDC (video display controller) and VCE (video color encoder?). It's 9bits wide. All back ground pixels are output on the lower 8bits (0-255, thus 256 colors for BG layer). When a sprite pixel is output, the upper bit is set on the bus - thus allowing sprites to access the upper 256 color block.
Since the VDC pixel bus is digital, adding another chip to mix that pixel data is pretty easy. The VDC has a function where when no active pixel is being displayed (background or sprite), the very first sprite color pixel 0 is output instead. This normally never shows up because you need transparent parts of a sprite (otherwise they would looks like blocks). So you can always known when the VDC is output pixel data or not. The VPC (nick names 'Patty') looks for this. The VPC also looks at back ground color #0 (it doesn't know the real color for it, it just knows the pixel #) and uses that to show 'through' layers. Thus BG2/vdc2 can show underneath parts of BG1/vdc1.
The second function of the VPC, is that it provides some additional support in how to mix these layers. The backgrounds remain fixed as far as priorities go, but the sprites from each VDC can be setup in particular display orders. Not only that, but you can define 'how' the priority works on a pixel/scanline basis. What I mean be this, is that there are four windows registers. There are two windows (vdc 1 and vdc 2). There are a total of four window options that can happen between the two VDCs outputting pixels; windows 1 by itself, window 2 by itself, window 1 and 2 overlap, no window present. So you can set sprite priorities for each window logic. You also define the window. Well, you only control the width size of the window - starting from the left side (you can turn it off with a value lower than $40). These regs can be changed on a scanline basis. One option of the VPC is that sprite from VDC 1 are cut and put behind all layers (including both BG layers). But if the sprite priority inside the VDC itself is set to appear above the BG layer, the VPC will cut a hole in place of it. Some pretty weird and unique stuff that you can do with it.
There's also a function that makes the cpu ST0/ST1/ST2 opcodes store the immediate values directly to VDC #2 instead of VDC #1. That's pretty cool too. Both VDCs and the VPC are tied to the clock out of the VCE, so any horizontal resolution setting effects all the chips, so they're in sync with each other (VCE controls the dot clock of all these chips).
Two things they really missed out on; 8bit pixel mode by simply taking the upper 4bit of VDC1 and lower 4bits of VDC2, for a non sub-paletted display (and tile/sprite display of 8bit instead of 4bit). Charles Macdonald actually did a quick hard mod to his SGX and wrote a demo to show it off, for this effect. The other thing they could have done is limited transparency. Basically forcing the output of one VDC to use an alt subpalette (the upper 4bits of the 8bit pixel bus) on a per pixel basis. You would have to manually setup the alt subpalettes in cram, but that's easy to do (it would also split in half your subpalettes - but the PCE has way more than it really needs in that department).
The SGX also has the newer 6280a, which means it can stream high frequency samples on a single channel - much higher than 7khz. And with lower cpu resource too. Win/win.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Tatsujin on September 07, 2013, 07:58:26 PM
SGFX is a beast!!
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: seieienbu on September 07, 2013, 08:56:15 PM
Trying to think of a few places graphic affects like these were used. First that I thought of, I take it you could use these window functions to do something like this water effect from Secret of Mana?
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Black Tiger on September 08, 2013, 03:02:15 AM
Trying to think of a few places graphic affects like these were used. First that I thought of, I take it you could use these window functions to do something like this water effect from Secret of Mana?
All of the water in that video used different colored tiles and not any kind of technical effect. Many PCE games already do that, even with a moving section of translucency.
The Metroid super bomb/Contra 3/Alien Soldier scaling transparency circle (seen in that video) might be possible on SuperGrafx.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Mathius on September 08, 2013, 03:15:48 AM
Trying to think of a few places graphic affects like these were used. First that I thought of, I take it you could use these window functions to do something like this water effect from Secret of Mana?
All of the water in that video used different colored tiles and not any kind of technical effect. Many PCE games already do that, even with a moving section of translucency.
The Metroid super bomb/Contra 3/Alien Soldier scaling transparency circle (seen in that video) might be possible on SuperGrafx.
That's it. Someone needs to port Super Metroid to the SuperGrafx. Get to it!
...actually that would probably take decades. Nevermind. We do need some full scale SGX homebrew though.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Black Tiger on September 08, 2013, 04:17:44 AM
It would be cool if some homebrew games had optional SuperGrafx stages that are unlocked after finishing the game. That way they could recycle assets and gameplay from existing stages and make as few SuperGrafx enhanced versions of existing stages as they want to, while still reaching the maximum audience overall with their game.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: spenoza on September 08, 2013, 07:23:37 AM
The SGX also has the newer 6280a, which means it can stream high frequency samples on a single channel - much higher than 7khz. And with lower cpu resource too. Win/win.
Did any hardware other than the SGX and the Core I use this chip revision, and why not?
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Tatsujin on September 08, 2013, 01:14:49 PM
It would be cool if some homebrew games had optional SuperGrafx stages that are unlocked after finishing the game. That way they could recycle assets and gameplay from existing stages and make as few SuperGrafx enhanced versions of existing stages as they want to, while still reaching the maximum audience overall with their game.
yeah, Darius Plus/Alpha style :)
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: touko on September 19, 2013, 06:35:03 AM
is it possible to change background priority like md/snes ??? for exemple to change priority mid-frame, bg2 came in front of bg1 .. or to change spr1 priority over bg1 in front or behind in mid frame ??
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Arkhan on September 19, 2013, 10:56:03 AM
is it possible to change background priority like md/snes ??? for exemple to change priority mid-frame, bg2 came in front of bg1 .. or to change spr1 priority over bg1 in front or behind in mid frame ??
IIRC, sprite/bg priority on the MD is per BG tile, and on the SNES, stored in each sprite entry. They can't have their priorities changed with a single register write mid-frame, can they?
The PCE is similar, with priority determined for each sprite.
Here's Charles Macdonald's summary of SGX priority:
The 2-bit priority field affects the layer ordering. The above default priority setting is selected for values of 00b and 11b.
For 01b, VDC #1 sprites are shown behind the VDC #2 background. However, the VDC #1 background has missing sprite-shaped areas where it's sprites are, even though they are hidden behind both background layers.
For 10b, VDC #2 sprites are shown in front of the VDC #1 background and behind VDC #1 sprites. However, low priority VDC #2 sprites are still shown behind VDC #2 background tiles. Layer priority and windowing can be changed for each scanline as intended.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: touko on September 19, 2013, 08:16:04 PM
yes i know for md, and you can change (not by changing a registry of course) BG priority easily . TF4 water stage uses extensively this feature . Some snes games do the same .
I did some tests with charle's doc, and i found VPC not very useful(in common use), because the only serviceable sprites priority is SPR2 in front of BG1 & BG2 .. You have only 4 values, two are default VPC parameters, one is cool but usable in some restricted case, and the last for SPR2 in front of BG1 & BG2, the only useful .
It seems impossible to do SPR1(with high priority) in front of BG2, but behind BG1 in mid frame .. :(
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: SignOfZeta on September 20, 2013, 06:22:12 PM
Imagine a SFX with playing a cd-rom game that takes advantage on the arcade card too. Would be great.
Imagine how great those SNK fighters would have turned out if they were designed for SFX not PCE.
I'm pretty sure those SNK games would have turned out exactly the same. The ACD versions they did make we're pretty damned good, Fatal Fury Special in particular. When you port a Neo game you're probably not going to do much that the Neo didn't do, and the PCE does pretty much everything the Neo version did.
Art of Fighting could be better, but I'm not sure the SGX would have helped. Maybe?
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: esteban on October 06, 2013, 02:17:24 AM
I know it might sound silly, but I would have loved a MAGICIAN LORD REDUX for the ACD PCE.
Just thinking about SNK's stable of games (I know SNK was merely publisher and not developer for Magiciane Lorde).
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: spenoza on October 06, 2013, 03:00:11 AM
I know it might sound silly, but I would have loved a MAGICIAN LORD REDUX for the ACD PCE.
Just thinking about SNK's stable of games (I know SNK was merely publisher and not developer for Magiciane Lorde).
ADK actually developed Magician Lord, but ADK also developed the World Heroes games and the PCE got one of those, so having ADK as a developer shouldn't have been an issue for licensing. Probably demand was a bigger issue.
Title: Re: what was the supergrafx actually capable of? do we really know?
Post by: Tatsujin on October 06, 2013, 03:34:41 AM
it would have been the one and only magian lord port outside the SNK world.