|
|
Post by spenoza on Apr 21, 2022 18:36:29 GMT
I don't think the Hu6280 is at a particular disadvantage when it comes to game logic, even managing the extra sprite and background tasks, compared to the Genesis or the SNES. The SNES struggled early on with sprite management and the SNES also had to do more meta sprite handling due to the restrictive sprite size limits. The Genesis typically didn't struggle much, but it also didn't really move many more sprites than the PC Engine (80 vs 64). If anything, the main drawback to the Hu6280 is the fact that it has to juggle audio management with game code and has a very restrictive RAM pool. Now, I don't know what additional complications came from how the SuperGrafx paired GPUs above and beyond simply managing twice the tiles and sprites, so I can't speak to that, but if the SNES could reasonably manage 128 sprites and up to 4 background tile layers I feel like 128 sprites and 2 background tile layers should be hamstringing for the PC Engine unless there's just a lot of cumbersome glue logic involved in talking to the extra GPU. So if the SuperGrafx CPU was overtaxed then wouldn't also the SNES CPU be? I also think HuC performance is not relevant to the question of commercial capability since the Hu6280 is not C-friendly and it's basically a hobbyist-maintained environment.
|
|
|
|
Post by dshadoff on Apr 21, 2022 20:33:04 GMT
I was talking about sprite management and bandwidth to VRAM primarily.
That’s s lot of RAM shuffling to take advantage of any extra sprites or background data the SGX might provide.
And seriously, you’ve never seen slowdown on The Super Famicom ?
That was literally the only thing that stood out to me around its introduction. At least for action games that I wanted.
Granted, mode7 brought something to the table, and they concentrated on things it was more capable with as time went on.
|
|
dogen
Deep Blooper
Posts: 31
|
Post by dogen on Apr 21, 2022 20:42:27 GMT
So here's something to ponder: what is the SuperGrafx design had been sat on a bit longer until memory prices came down a bit and it was released later in the console's life? Would there have been a market for it once it was a little cheaper to manufacture? It's important to remember that the Supergrafx had no boost in processing power. I've had slowdown issues with HuC. Bloody Wolf had a ton of lag issues. It's got the graphical chops to do things with, but no additional palettes or processing power. So, at best, you've got a PCE game with a few extra layers of parallax and maybe a few extra sprites. Those aren't going to massively change your gameplay experience, not worth buying a whole new console for. Granted, I own a supergrafx and all 5 games, but ya know, collectors gonna collect. Idk, in another thread (and on a discord) touko said his supergrafx game can handle more than enough collisions to use the extra sprites. "I was talking about sprite management and bandwidth to VRAM primarily. That’s s lot of RAM shuffling to take advantage of any extra sprites or background data the SGX might provide." Not necessarily, if you don't need a bunch of unique sprites |
|
|
|
Post by spenoza on Apr 21, 2022 22:13:25 GMT
I am certain that in order to really stand out SGX games needed to be better programmed, otherwise slowdown was going to be a possible problem. The SNES did indeed stuffer a lot from slowdown, especially early on, though once the system was a couple years in most competent developers could manage much better. I think the SGX really needed to be introduced as part of a CD expansion to really be allowed to fly, because then you can free up some CPU time by using CD audio in most places. I agree that if the Super CD and Duo had integrated SGX functions (sadly eliminating the option of a Super System Card) it would have had the potential to increase the reach of the SGX design, though it would have constrained the spread of Super CD.
|
|
dire51
Deep Blooper
Posts: 19
Fave PCE Shooter: Soldier Blade
Fave PCE Platformer: Bonk's Adventure
Fave PCE Game Overall: Splatterhouse
Fave PCE RPG: Ys Book I & II
Currently Playing: Mr. Heli
|
Post by dire51 on Apr 21, 2022 22:28:03 GMT
My only lament about the SuperGrafx is that I never personally got to play one. All my experience with it is via emulation.
That, and I wish the port of Strider had been released for it, instead of what we got.
|
|
|
|
Post by dshadoff on Apr 22, 2022 0:57:13 GMT
"I was talking about sprite management and bandwidth to VRAM primarily. That’s s lot of RAM shuffling to take advantage of any extra sprites or background data the SGX might provide." Not necessarily, if you don't need a bunch of unique sprites True... but then, it's a PC Engine game, not a SuperGrafx game... |
|
|
|
Post by DarkKobold on Apr 22, 2022 1:20:14 GMT
I don't think the Hu6280 is at a particular disadvantage when it comes to game logic, even managing the extra sprite and background tasks, compared to the Genesis or the SNES. The SNES struggled early on with sprite management and the SNES also had to do more meta sprite handling due to the restrictive sprite size limits. The Genesis typically didn't struggle much, but it also didn't really move many more sprites than the PC Engine (80 vs 64). If anything, the main drawback to the Hu6280 is the fact that it has to juggle audio management with game code and has a very restrictive RAM pool. Now, I don't know what additional complications came from how the SuperGrafx paired GPUs above and beyond simply managing twice the tiles and sprites, so I can't speak to that, but if the SNES could reasonably manage 128 sprites and up to 4 background tile layers I feel like 128 sprites and 2 background tile layers should be hamstringing for the PC Engine unless there's just a lot of cumbersome glue logic involved in talking to the extra GPU. So if the SuperGrafx CPU was overtaxed then wouldn't also the SNES CPU be? I also think HuC performance is not relevant to the question of commercial capability since the Hu6280 is not C-friendly and it's basically a hobbyist-maintained environment. Honesty, the # of sprites held by the system has never been the limiting factor for me. Regarding sprites, the biggest issue for me has always been the number of sprites per scanline, which in 256x224 mode is the same for every one of the big 3 consoles. There's no point in using 128 sprites if 60 of them drop out... Sure, you could space them on the screen so they don't, but how often do things space perfectly so you don't get sprite drop? And really, extra background layers are pretty much always just icing on the cake, they never really make or break the gameplay experience. And yes, HuC wasn't available back then, but it's just my personal experience with the hardware in question. Also, I actually don't know how sprite/background priority and sprite drop work on the Supergrafx. I've never been that interested in programming for it, because it's just not a widely available system, and I have no nostalgia for it. |
|
dogen
Deep Blooper
Posts: 31
|
Post by dogen on Apr 22, 2022 2:04:30 GMT
"I was talking about sprite management and bandwidth to VRAM primarily. That’s s lot of RAM shuffling to take advantage of any extra sprites or background data the SGX might provide." Not necessarily, if you don't need a bunch of unique sprites True... but then, it's a PC Engine game, not a SuperGrafx game... I mean sprites with unique patterns. For example, a shooter with only a few kinds of bullets on screen but still over 64. And even if you do no more VRAM uploads than a PC engine game, you still have an extra 64KB of VRAM. |
|
|
|
Post by turboxray on Apr 26, 2022 23:27:58 GMT
From a standard development point of view; there's no real juggling of extra tiles and sprites cells on the SGX. If you look at PCE games, they just load everything in vram and leave it there (for the area/stage/whatever). SGX game dev approach was no different - you're not streaming in graphic data. The SGX already gives you twice the allotted vram, so that already scales directly with the extra BG layer and extra sprite capability.
Splitting the sprite bandwidth between the two VDCs is generally pretty simple too. I mean, you could get really fancy with it.. but most of the time you dedicate certain sprites/objects to one VDC and some to the other VDC. It's not rocket science. I think the only time the object handling code between both VDCs gets more complicated, is when you're doing something like a beat'em up and dynamic Z priority is important.
The SGX isn't about throwing around 128 sprites on screen (because that's crazy regardless of the system. Specifically, Genesis games don't throw 80 sprites on screen for every game) - it's about throwing a little more on screen without hitting a major scanline limit - larger enemies made up of more sectional moving parts, etc. The PCE's already doing plenty with sprites, so only 30-35% increase in sprites and/or sizes on screen will make a noticeable visual difference. Think about having two giant rock guys from Dracula-X on screen instead of one - that's not pushing '128 sprites on screen' but already it's more impressive than just a single one because you won't have lots of sprite dropout. And Something like that isn't going to cause slowdown, unless you have some poor handling code (which exists - just checkout the recernt MegaMan 2 video by Displaced Gamers. And I thought MegaMan 1 game code was bad hahah).
The extra 24k of ram gives hucards a lot more breathing room, that's for sure. You could even decompress map layouts instead of doing it on the fly. That saves CPU resource right there (i.e. instead of decompressing on the fly). Super Famicom got it right with 128k work ram.
Collision detection on the PCE is already pretty fast (if written in assembly) - it's on par and even faster than on the Genesis (with some optimization handling 8bit coords). Super famicom has games that slowdown with almost nothing on screen, and definitely a lot less than even normal PCE games. Most of the slowdown from that generation, including SGX games, is from meta-sprites and poorly optimized meta handling routines (decoding).
I dunno. Music engines back in the day for PCE games typically aren't resource hogs unless you're doing something with samples (and they are compressed samples too; decompression on the fly isn't cheap. Airzonk can take up to 25% cpu resource when it's playing those compressed samples). I think most of those sound engines are in the 3-5% cpu resource range on the PCE. I mean, it only takes like 1 cpu cycle to cause slowdown, so I guess theoretically if a game is right on the edge then using CD audio could keep the slowdown at bay. The SGX can play samples with much less cpu resouce if you use the channel as small refill buffer. No SGX does this, but also AFAIK no SGX game uses samples either. Just an FYI - sound FX through the PSG player on the CD system card aren't free either. SFX tends to be 'mini songs' per se, and you're playing a few of them at a time. So if a game used 5% cpu resource to play a chip tune on a hucard game, the CD version doesn't automatically get that whole 5% back.
If you want to throw some numbers at the collision code and SGX via a shump: you can make the assumption that fetching a box and comparing it against a list of other boxes (enemies/whatever) - so estimate that it takes a full ~115 cycles to process (start to finish for a positive match). That means you confirmed a collision detection between two objects/boxes. It's not going to be the case where all objects collide with the player, or player bullet, all at once so you could make an educated guess that you'll probably go through about half the checks (bounding box collision is a 4 part check). So let's assume 65 cycles for half the checks (just to make it simple). Let's say you have 1 player, 50 enemies, 20 player bullets, and 20 enemy bullets. Player bullets, generally, don't interact with enemy bullets. Enemy bullets don't interact with other enemies or player bullets (generally). So your collision routine is; player against enemies, player against enemy bullets, all player bullets against all enemies. So 1x50, 1x20, and 20x50 for the 91 total objects. That's 1070 collision checks. An early opt out is 40 cycles, half way is 65 cycles, 3/4th way is 90 cycles, and full collision detected is 115 cycles. Setting the average to 65 cycles is on the high side because probably gonna have more early opt outs than halfway through opt outs, but we'll leave it at that for a conservative estimate. so 1070 x 65 = 69550 cycles or 58% cpu resource. So that's all collision checks.. whether objects are close to each other or not. So 91 sprites, 1070 collision checks, 58% cpu resource. Let's also assume that all 20 player bullets hit 20 different enemies, because there's still the cost of processing the detected collision. Let's say it takes like 250 cycles per object to change the state from 'alive' to 'dead' (i.e. explosion, or damage, etc) phase. That's 20 x 250= 5000 cycles or 4% cpu resource. So now we're up to 62% cpu resource total for our imaginary frame. That's still really good for a brute force unoptimized method! Of course with that many objects, you'd probably want to use a grid base system to reduce the 1070 collision down somewhat. like half that number of collisions or even less. Grid base systems do have overhead, so net gain is probably a savings of like 25-40% on your collision check cost (and even more). Of course there are other tricks and optimizations too, so easily get it down to like 30-35% cpu resource.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jun 24, 2022 18:25:26 GMT
Hi, my collision routine takes 72 cycles if collision, i really doubt that the 68k do better, or even reach that score .  So turboxray is right with his estimation of an average of 115 cycles if we take in account the objects list to treat. |
|
|
|
Post by elmer on Jun 27, 2022 14:18:42 GMT
Basically, I agree with everything turboxray and touko are saying ... from my POV, the HuC6280 CPU is perfectly capable of running the extra background/sprite capability of the SuperGraxf at full speed in the hands of a competant assembly-language programmer, and the extra work-RAM, VRAM, and sprites-per-line are *HUGE* steps up from the base PC Engine, and easily put the hardware above the Genesis, and make it more competitive with, and sometimes above, the power of the SNES's graphics chip. The SuperGrafx would never have been able to compete with the SNES's use of MODE-7, or of its 256-color mode used in some later games, but it should have been able to keep up with most kinds of games, and do so without the SNES's notorious slowdown. BUT ... the SuperGrafx would always have been more-expensive to both manufacture and sell, and so I still can't see any real scenario in which it could have been a commercial success in the 1989-1991 time period. IMHO the PC Engine's "super-power" was always the CD unit, and the introduction of full CD-Audio music, real human voice-over acting, and the ability to put huge amounts of data on a CD-ROM in comparison to cartridge games. Those were never-before-seen capabilites in home consoles, whereas the SuperGrafx's 2nd background layer was just a 2nd background layer, and an increment rather than a revolution. Plugging a SuperCD-ROM2 unit into the back of a SuperGrafx just makes my head spin from the awesome possibilities of what I personally consider to be the most-powerful home-console hardware of its generation, but it's really just a case of dreaming of possibilities of "what-could-have-been", if the market had been different.  |
|
|
|
Post by turboxray on Jun 27, 2022 15:43:33 GMT
Basically, I agree with everything turboxray and touko are saying ... from my POV, the HuC6280 CPU is perfectly capable of running the extra background/sprite capability of the SuperGraxf at full speed in the hands of a competant assembly-language programmer, and the extra work-RAM, VRAM, and sprites-per-line are *HUGE* steps up from the base PC Engine, and easily put the hardware above the Genesis, and make it more competitive with, and sometimes above, the power of the SNES's graphics chip. The SuperGrafx would never have been able to compete with the SNES's use of MODE-7, or of its 256-color mode used in some later games, but it should have been able to keep up with most kinds of games, and do so without the SNES's notorious slowdown. BUT ... the SuperGrafx would always have been more-expensive to both manufacture and sell, and so I still can't see any real scenario in which it could have been a commercial success in the 1989-1991 time period. IMHO the PC Engine's "super-power" was always the CD unit, and the introduction of full CD-Audio music, real human voice-over acting, and the ability to put huge amounts of data on a CD-ROM in comparison to cartridge games. Those were never-before-seen capabilites in home consoles, whereas the SuperGrafx's 2nd background layer was just a 2nd background layer, and an increment rather than a revolution. Plugging a SuperCD-ROM2 unit into the back of a SuperGrafx just makes my head spin from the awesome possibilities of what I personally consider to be the most-powerful home-console hardware of its generation, but it's really just a case of dreaming of possibilities of "what-could-have-been", if the market had been different.  Did you see that "Final Fight Ultimate" remake from scratch for the Megadrive??? Supergrafx + arcade card version would crush that!  I'm working on a beat'em up engine for the PCE. I'd definitely love to work on a z-depth sprite sorting algo for the two VDCs for an SGX version. I also think the 512px resolution mode is more practical on the SGX. So that's also a nice upgrade. I was also thinking about the SGX. I mean sure, extra system ram and extra vram, but the VDC was already in mass supply and had a manufacturing process. They could have continued forward with it (including adding it into the Duo design). Manufacturing was always going to get cheaper. I just think NEC was more "greedy" with their profit line than say Sega. But NEC also had to pay Hudson handsome royalties for each system manufactured, so that could have influenced the cost. Supposedly, Hudson had a nice "chunk of change" off the initial over production of TurboGrafx-16 systems at launch. They got their royalties regardless of sales. |
|
|
|
Post by elmer on Jun 29, 2022 17:10:44 GMT
Did you see that "Final Fight Ultimate" remake from scratch for the Megadrive??? Supergrafx + arcade card version would crush that! I just looked at a video on YouTube, and ... meh!  I'd definitely love to work on a z-depth sprite sorting algo for the two VDCs for an SGX version. At first glance, that *should* just involve a slot-based VRAM-allocation system for the two VDCs, with added extra logic to ensure that only one (or two max) entities switch between VDCs in any single frame. But yep, that's the *fun* of writing a beat-em-up!  I was also thinking about the SGX. I mean sure, extra system ram and extra vram, but the VDC was already in mass supply and had a manufacturing process. Ah, but I suspect that you'll find that the RAM *IS* part of the reason why the SuperGrafx could never have been sold cheaper than the Genesis/SNES. The SuperGrafx's use of 128KB+32KB of fast Static RAM would be a problem. Static RAM was (still is?) at-least double the cost per bit compared to Dynamic RAM, and then the need for fast adds another price-premium. There's a cost-to-manufacture reason why the SNES RAM is both Dynamic RAM and slow. I just think NEC was more "greedy" with their profit line than say Sega. I wouldn't say "greedy", I'd just say that their business-model was to make money selling hardware, and that's what they knew. The business-model of basically giving away the console for free (or even at a loss) for the first few years of manufacture, and then clawing back the money from the licensing-fees charged on every single cartridge/CD, was not something that I expect that NEC's management would have allowed for the PC Engine. |
|
|
|
Post by crisgenjin on Jul 10, 2022 14:39:53 GMT
I'd honestly kill to have visual novels on the SuperGrafx using the 512px mode, it would be more than capable of handling it and wouldn't need to sacrifice any colors (Unlike the SNES with its hi-res screen modes)
|
|
|
|
Post by turboxray on Jul 10, 2022 15:11:49 GMT
I'd honestly kill to have visual novels on the SuperGrafx using the 512px mode, it would be more than capable of handling it and wouldn't need to sacrifice any colors (Unlike the SNES with its hi-res screen modes) Plus, SNES hi-res screens are only for BGs. Sprites are still low res. SGX doesn't have that problem. I was actually looking at Kirby 3 for SNES, and doing captures with retrotink-5x, and thinking.. SGX has no problem doing this as well. |
|
I'm working on a beat'em up engine for the PCE. I'd definitely love to work on a z-depth sprite sorting algo for the two VDCs for an SGX version.
