|
Post by crisgenjin on Jul 11, 2022 0:06:46 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. Yeah, I think it can do almost everything as good, if not even better than the SNES...aside from Mode 7, obviously. I would tackle some SNES-to-SuperGrafx tech demos if I actually knew how programming works lmao
|
|
|
Post by turboxray on Jul 11, 2022 0:19:57 GMT
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. Yeah, I think it can do almost everything as good, if not even better than the SNES...aside from Mode 7, obviously. I would tackle some SNES-to-SuperGrafx tech demos if I actually knew how programming works lmao Well, you don't need to necessarily need to know how to code to come up with clever tricks. I know a few people that have come up with clever tricks for the PCE, and don't code at all! Just takes a little bit of understanding (okay.. quite a bit) and thinking outside the box. That last part is the most important part. If you come up with something clever, maybe someone can code the effect to see how it looks. For instance this effect: Is totally doable on the PCE! If you look at the tiles for the BG, they're pretty much just 4 colors per tile (technically 5, but you could reduce them to 4 without any visual difference). Tiles on the PCE are planar. This means that if your tile data existed in the first 2bits of a 4bit tile, you could place other graphics in the upper 2bits of the tile data. If you setup the palettes correctly, you get instant translucency. There's actually a PCE game that does this, sort of, but it doesn't do it for translucency (palettes are setup like that). It's sort of a "hardware assist" effect. Amiga demos did some effects like this as well.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jul 17, 2022 10:37:37 GMT
The snes's problem was mainly his hardware sprites.they were totaly messed up in all every possible way,at a point that it was impressive. Only two sizes in the same frame, only square sizes,OAM is horrible, and ice on the cake you can't put the sprite data were you want in VRAM, because you're limited to only two pages of 8ko each .
|
|
|
Post by turboxray on Jul 18, 2022 0:02:33 GMT
The snes's problem was mainly his hardware sprites.they were totaly messed up in all every possible way,at a point that it was impressive. Only two sizes in the same frame, only square sizes,OAM is horrible, and ice on the cake you can't put the sprite data were you want in VRAM, because you're limited to only two pages of 8ko each . Shhhhhh!!!!! Or that inceptional guy will come over here
|
|
gilbot
Punkic Cyborg
Posts: 137
|
Post by gilbot on Jul 18, 2022 5:28:39 GMT
Doubt that though, as this is not a primary Nintendo-related (or its "rival" blast-processing Sega) forum. If we succeed in luring him to visit here, that means he's acknowledging a system that he knew nothing of showed no interest as a worthy rival of his favourite POWAFULULU system. Isn't that "great"?
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jul 19, 2022 14:44:00 GMT
The snes's problem was mainly his hardware sprites.they were totaly messed up in all every possible way,at a point that it was impressive. Only two sizes in the same frame, only square sizes,OAM is horrible, and ice on the cake you can't put the sprite data were you want in VRAM, because you're limited to only two pages of 8ko each . Shhhhhh!!!!! Or that inceptional guy will come over here Ahaha, even a snes's fan like me must recognize that.A simple reading of the technical doc, and the first thing that make you wahou(but not in the good way), is that . How could they leave it like this for a sprite based system ?? it smell a bit like the old nes compatibility .
|
|
|
Post by crisgenjin on Jul 20, 2022 8:10:12 GMT
Shhhhhh!!!!! Or that inceptional guy will come over here Ahaha, even a snes's fan like me must recognize that.A simple reading of the technical doc, and the first thing that make you wahou(but not in the good way), is that . How could they leave it like this for a sprite based system ?? it smell a bit like the old nes compatibility . If those dumbnuts at Nintendo dropped backwards compatibility from the start and made the CPU a fair bit faster the SNES would've been near unstoppable...I wish
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jul 20, 2022 10:33:22 GMT
This is not a simple question of CPU, with a proper sprites engine a faster CPU is not really required, i think actual CPU is enought with a good coder . A faster CPU makes only the use of 8x8 and 16x16 sprite size for meta sprites more easy, you compensate the bad hardware sprites system, with the use of more sprites to gain more flexibility. Nintendo could have done like nec did, so eliminate the two CPU's clock phase and doubling the frequency without any change in RAM requirements.
|
|
|
Post by SignOfZeta on Jul 20, 2022 10:41:50 GMT
I think someone at Nintendo saw an early demo of F Zero or something similar and just said “yes” and didn’t ask too many questions after that.
Imagine if they had sprung for a 68000. The SNES would have been a monster.
|
|
|
Post by turboxray on Jul 20, 2022 15:59:25 GMT
I think someone at Nintendo saw an early demo of F Zero or something similar and just said “yes” and didn’t ask too many questions after that. Imagine if they had sprung for a 68000. The SNES would have been a monster. The 68000 wouldn't have done anything for the sprite issues. But you do know the SA-1 processor in later games kills even as 12+mhz 68k right? That thing is a beast. The problem is, that unlike the PCE and MD, the SNES can only have 2 sprite sizes on screen at a time. 128 sounds like a lot but when you have 8x8 & 16x16 as the sizes, then you don't get the screen coverage that PCE and MD get. And if you choose 16x16 & 32x32, then 128 sprites is pretty much useless because while you get the screen coverage, you now can't show maybe half that because the large cells hits that sprite scanline limit. On top of that, only having access to 16k of vram for sprites is also limiting (for general games, maybe not so much but fighting or beat'em up it presents an issue). The SNES didn't need a 68k. It needed 32k more vram to compensate for the extra BG layer, needed like 5 or 6 sprite sizes on screen at once, and needed at least 32k of vram for sprite access. For speed, all they needed to do was have "work ram" fun at full 3.58mhz instead of 2.68mhz. That would have given it a 15% boost when running full speed roms, while also making the vDMA faster which also means more time back for the cpu. I agree with touko.. smells like famicom compatibility.
|
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Jul 22, 2022 16:54:08 GMT
Yeah I think the 65816 is considered faster than the 68000 in general, and many of the advantages with the 68000 apparently doesn't apply to a ROM-cartridge-based system where code isn't normally uploaded to RAM, meaning it's typically more advantageous in a computer like the Amiga or Sharp X68000 that uses floppies.
I guess Nintendo clocked the CPU so slowly because of things like propagation delay of parts and circuit design which, as already said, probably were chosen for Famicom backwards-compatibility. The SFC controller reading is done at the exact same clock speed as the Famicom is doing it in (and SFC controllers are just expanded versions of the Famicom controllers using the exact same parts).
The SA1 is a co-processor and isn't as integrated with the rest of the system as the CPU is, so I guess they had more freedom in choosing its clock speed. Plus it was released many years later when the 65816 probably had been improved to support 10 times higher clock speeds than the SFC CPU.
To be fair, the PC-Engine's sprites can't be 8x8 dot in size which means a lot of SG VRAM is wasted for small things like bullets.
|
|
|
Post by dshadoff on Jul 22, 2022 17:42:40 GMT
I think turboxray's point about famicom compatibility was talking about the video processing capabilities, not the CPU. In other words, perhaps they had some developer tools that modelled Famicom video subsystem, and were scared of rewriting those sections for a different video subsystem (rather than just tweaking them).
I disagree with pokun's assertion about the 65816 being faster than the 68000 - these are really not comparable chips on several levels, especially when considering that the processors' clock rates would have been significantly different at all times during their lifetimes. (Although performance-per-cycle may be debated, you'd have to bring in many other factors to have a reasonable discussion about throughput).
Nintendo clocked the 65816 so slowly because that was effectively the speed of the chip that was available at that time. Compare the Apple IIGS (2.8MHz 65816 in 1986) versus PC Engine (7.16MHz 6502-derivative in 1987), and it isn't hard to see that the 65816 wasn't able to be clocked at comparable rates to the 68000 (which was in the Amiga at ~7MHz in 1985).
|
|
|
Post by turboxray on Jul 22, 2022 20:35:53 GMT
To be fair, the PC-Engine's sprites can't be 8x8 dot in size which means a lot of SG VRAM is wasted for small things like bullets.
What do you mean by "SG" VRAM? Are you saying SuperGrafx or "Sprite Graphics".. because there is not sprite graphics vram. It's just vram. And at 128k of vram for SGX.. I wouldn't worry about it. I mean, instead of wasting the space.. use it hahaha. More seriously, it's actually not "a lot" of vram wasted. It can be some minor vram loss, to almost negligible - how many individual small bullets are you going to have in vram? I guess. But it's still so much less of an issue than the SNES sprite setup (even compared to vanilla PCE). Especially considering SNES 16k sprite vram limitation. PCE is built/influenced from arcade systems of the time - a lot of them used 16x16 as the smallest sized cell. Even the Capcom's CPS1 doesn't have sprite cells smaller than 16x16. One early interview for PCE design says they had planned to use all 128k for vram, but cut it back to 64k last minute. Anyway, I'm not saying the 8x8 + 16x6 mode @ 128 entries doesn't have a use-case on the SNES; it does, but it's a very edge use case IMO. From a lot of digging into SNES games, and converting them to PCE sprite layout - I found it to be disadvantageous much more often than not. VRAM aside, I would argue that 8x8 is nice for sprite scanline limit tho. Too bad on the SNES you literally are eating through the SAT/OAM when using that mode before something like that becomes applicable. I guess that SNES sprite mode would be good for something like Cannon Fodder or Syndicate. Otherwise SNES best general case use for sprites is the 16x16 + 32x32 mode, which puts it worse than PCE. Part of the issue of why you don't see "stock" 65816s at higher clock speed is that it multiplexes the data bus with the address but to form the 24bit address; it needs ram/rom at twice the clock speed. Clock for clock though, it's much faster than a 68k on so many things. But I mean in the end, what you get is what you get - efficiency or otherwise becomes irrelevant.
|
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Jul 23, 2022 19:20:22 GMT
SG = Sprite Generator, in other words the Character Generator (CG) for sprites, the part of VRAM that holds pattern pixel data of the sprites' shapes. Well you are probably right, I was mainly pointing out what I think is the main weakness of the PC-Engine's spriting subsystem, the lack of the 8x8 dot size. For example in a danmaku you need a lot of small bullets and lasers. Yeah the 68K has many slow instructions but usually also does many things for each instruction (I guess you can consider it being more CISCy that way). I thought the PC-Engine with it's 65xx family CPU is considered faster than the Megadrive despite they having very similar clock speeds and the PC-Engine being 8-bit. I don't get why MOS/WDC just didn't increase the number of pins on the 65816 so that they wouldn't have to multiplex the buses. I think turboxray's point about famicom compatibility was talking about the video processing capabilities, not the CPU. In other words, perhaps they had some developer tools that modelled Famicom video subsystem, and were scared of rewriting those sections for a different video subsystem (rather than just tweaking them). What do you mean? The video processing is one of the things the Super Famicom does very differently from the Famicom and probably mainly why they had to scrap backwards-compatibility.
|
|
|
Post by dshadoff on Jul 23, 2022 20:31:42 GMT
Yeah the 68K has many slow instructions but usually also does many things for each instruction (I guess you can consider it being more CISCy that way). I thought the PC-Engine with it's 65xx family CPU is considered faster than the Megadrive despite they having very similar clock speeds and the PC-Engine being 8-bit. I once wondered why a 6502 at 1MHz was similar to a Z-80 at 2MHz; it turns out that 6502's are based on a quadrature clock - in other words, 2 separate clocks, offset by a quarter cycle (the second clock identifies a time when address or bus data should be considered "ready"). This actually means that a 6502 at 1MHz is functionally running at 2MHz, due to the fact that it needs two functioning clocks. It seems that the HuC6280 was quite an achievement - it internally generates the second clock, but I don't think that many 6502 type CPUs were running at 7MHz (i.e. 14 equivalent MHz) at that time. Thanks to the overall simplicity of the 6502 though, it was probably easy to clock higher with a die shrink. The 68000, however, running at under 8MHz in 1988 was comparable to a 1985 Amiga, and I think they went for a slower clock to limit costs rather than to go for speed. I think turboxray's point about famicom compatibility was talking about the video processing capabilities, not the CPU. In other words, perhaps they had some developer tools that modelled Famicom video subsystem, and were scared of rewriting those sections for a different video subsystem (rather than just tweaking them). What do you mean? The video processing is one of the things the Super Famicom does very differently from the Famicom and probably mainly why they had to scrap backwards-compatibility. All of the limitations turboxray spoke about are related to the video-processing: sprite memory being separate; limits on video RAM, limits on sprite sizes. They could have redesigned these aspects, but didn't. If they aren't in any way compatible with Famicom (including for tools with which to design/generate content), then it was a totally wasted opportunity.
|
|