Capabilities of various VDPs at parallax effects

[iNCEPTIONAL]

I created this thread as per the suggestion of someone in another thread, just so I'm not necromancing or necromorphing it or whatever people call it.

There was some talk in a previous thread that one system could do parallax scrolling better than others, so I just thought I'd post some examples from each system to show what they are capable of, and then each person can see and decide for themselves how well each system can do row scrolling, line scrolling, column scrolling and overlapping layer-based scrolling, or indeed not, if that's that case:

Here are some example from Genesis:

https://youtu.be/2RGsqR70kes?t=2

https://youtu.be/to6YikO4FPc?t=53

https://youtu.be/kTjqg3ztZoA?t=55

https://youtu.be/GoGg69TdaGA?t=107

https://youtu.be/EDaIlrfxRnE?t=1245

https://youtu.be/h8kSwhVgNFk?t=194

https://youtu.be/8fjTHAd2wYs

https://youtu.be/kDoac4j2E2g?t=748

https://youtu.be/JhExIWa0R-4?t=3055

https://youtu.be/JhExIWa0R-4?t=3239

https://youtu.be/RCYVlmbe2qY?t=270

https://youtu.be/aiVg4YShx5g?t=1649

https://youtu.be/xK1bFfY-RrE?t=312

https://youtu.be/13P_ANpeYns

Here are some from SNES:

https://youtu.be/_CO66ioB-ZE?t=998

https://youtu.be/_CO66ioB-ZE?t=500

https://youtu.be/7sfrauP3LNI?t=106

https://youtu.be/7sfrauP3LNI?t=449

https://youtu.be/7sfrauP3LNI?t=1720

https://youtu.be/F59TiwrECLo?t=334

https://youtu.be/F59TiwrECLo?t=387

https://youtu.be/VgTt5fceVTE?t=625

https://youtu.be/dJIz29bmA34?t=15

https://youtu.be/dJIz29bmA34?t=4944

https://youtu.be/Rv6XkVXE13w?t=2598

https://youtu.be/IyrOCNQc_rs?t=29

https://youtu.be/oCiSEChgjC4

https://youtu.be/SpmEaffVnQI?t=2342

https://youtu.be/G9m2gAuWkOY?t=2259

https://youtu.be/1AGMEZvU14g?t=1535 (three layers of parallax in SNES' high-res 512x448i Mode 5)

https://inceptionalnews.files.wordpress ... 10/a-1.gif (don't know it's this counts, but it's more than just flat Mode 7)

And here are some from PC Engine:

https://youtu.be/3qdIxCQRo54

https://youtu.be/8Cv92j7R9K8

https://youtu.be/RSgEUh-u4-c

https://youtu.be/frAiBw9odW4?t=44

https://youtu.be/KomoRs6t6kY?t=38

https://youtu.be/a5CBklt1wSk

https://youtu.be/fI2Vho8AFYI?t=19

https://youtu.be/hToclCtLN1k?t=493

Feel free to add your own examples for each system.

PS. I won't go into specific technical details in this post, but there is in fact one system that is technically capable of just as good row scrolling and line scrolling plus actually better column scrolling and overlapping layer-based scrolling than the others. Maybe you can work it out from looking at all these examples and any others you can find online.

[ob1]

Thank you.
It is an actually much better way of posting this - still very interesting - piece of information.

Cheers,
Olivier

[iNCEPTIONAL]

Thank you.
It is an actually much better way of posting this - still very interesting - piece of information.

Cheers,
Olivier

No problem.

[iNCEPTIONAL]

Also, side note from the other thread too: I recently discovered this about the VDPs of the PC Engine, Genesis and SNES, which I found very interesting too:

https://youtu.be/r7Jh_izIc8Q

It's a nice partner video to the normal comparison of CPU speeds that we usually see:

https://youtu.be/2k_jP73Ly7A

I'd actually like to see more videos like this in the future but with all the parts in one so it gives a more complete and balanced view of all three consoles in the one place. And it just shows that there's a lot more to these systems than a few on-paper numbers and select game examples can cover.

[Stef]

Unfortunately the comparison video is completely off, i already saw it and was surprised about the title as benchmarking and compare VDP performance of the different system sound like a rather difficult task. And here what he did is basically just trying to compare the VRAM write speed from CPU for the different systems which is not really relevant of the performance of the chip.
And even here, the code he used to do that is both wrong and not optimal in any way...
On MegaDrive for instance, he forgot to disable display so it can write the VDP at full speed during the whole frame (he mentioned it in the video but forgot to do it in the code). On SNES you cannot even write the VDP when display is enable so writes are likely to be ignored, on MD write is still possible but it's very slow so here it definitely make the transfer slower while it just get ignored on SNES. And for both machine, you have a DMA unit which is able to write the VRAM twice as fast than the CPU on MD (and probably even more on SNES as the CPU is slower to transfer data). So really the benchmark presented here is completely off.. And to be honest, we already know the VRAM write speed for the 3 systems so there is no real interest in doing a benchmark to measure it.
A better indicator of the VDP performance would be the number of displayable layer pixels + sprite pixels per frame for instance. And again we have these numbers, no need to make benchmarks to know the result

[iNCEPTIONAL]

Unfortunately the comparison video is completely off, i already saw it and was surprised about the title as benchmarking and compare VDP performance of the different system sound like a rather difficult task. And here what he did is basically just trying to compare the VRAM write speed from CPU for the different systems which is not really relevant of the performance of the chip.
And even here, the code he used to do that is both wrong and not optimal in any way...
On MegaDrive for instance, he forgot to disable display so it can write the VDP at full speed during the whole frame (he mentioned it in the video but forgot to do it in the code). On SNES you cannot even write the VDP when display is enable so writes are likely to be ignored, on MD write is still possible but it's very slow so here it definitely make the transfer slower while it just get ignored on SNES. And for both machine, you have a DMA unit which is able to write the VRAM twice as fast than the CPU on MD (and probably even more on SNES as the CPU is slower to transfer data). So really the benchmark presented here is completely off.. And to be honest, we already know the VRAM write speed for the 3 systems so there is no real interest in doing a benchmark to measure it.
A better indicator of the VDP performance would be the number of displayable layer pixels + sprite pixels per frame for instance. And again we have these numbers, no need to make benchmarks to know the result

Yeah, that may be the case, and I'm sure lots of tweaks could be made here and there. It's the same for all the consoles, I have no doubt. On the CPU comparison for example, he didn't run the SNES in FastRoM mode, so those results are from the SNES running at 2.68 MHz mode as it would be when using a SlowROM cartridge, which is artificially throttled to around 75% of the full 3.58 MHz CPU speed. But, a least he's consistent in not doing things quite perfectly but good enough for most people. And he still did the same test across all three consoles each time regardless. So, until someone posts a completely same condition test across all three systems, with no system given an obviously unfair disadvantage, or he creates completely optimized tests for all three systems similarly where you're seeing all three of them at their absolute peak, it's a couple of half decent examples that simply show things aren't quite as clear-cut as they might seem based on a couple of raw numbers on paper alone. And, importantly, it's not deliberately being biased towards any one system and coming from an obvious bad actor, I think, which is a nice change of pace.

[iNCEPTIONAL]

"A better indicator of the VDP performance would be the number of displayable layer pixels + sprite pixels per frame for instance."

Wouldn't that just be how many pixels you can see on the screen, which would be the same if all three consoles are running in 256x224 mode as per the test above, so 57,344 pixels on-screen per frame?

And, if not, and it's taking all available background layers plus basically a full sprite layer into account, wouldn't the SNES too easily walk away with that one, since it can show four full-screen background layers plus a full screen worth of sprites in Mode 0?

I mean, if that's what you mean, for Genesis it would basically be 256x224x3 = 172,032, for PC Engine it would be 256x224x2 = 114,688, and for SNES it would be 256x224x5 = 286,720, no?

Of, if we use the max viewable standard resolution for each system, for Genesis it would be 320x224x3 = 215,040, for PC Engine it would be 320x224x2 = 143,360, and for SNES it would still be 256x224x5 = 286,720, no?

I didn't cover the likes of 320x448 mode for Genesis, 512x224 for PC Engine, or 512x448 mode for SNES, as I'm not sure how much of the screen can be covered with sprites in those modes.

Or, did I not interpret what you were talking about properly?

Also, you mention "On SNES you cannot even write the VDP when display is enable so writes are likely to be ignored, on MD write is still possible but it's very slow so here it definitely make the transfer slower while it just get ignored on SNES. And for both machine, you have a DMA unit which is able to write the VRAM twice as fast than the CPU on MD"

So, wouldn't something like HDMA be useful on SNES there then too, because, as far as I'm aware, you can write to that during every HBlank, so 224 times per second, and, while it's not a lot that can be written in that time per blank, it could probably amount to a decent bit on top of the normal writing you can do during VBlank, no? And, as far as I'm aware, unlike normal DMA, it doesn't stall the CPU at all, or something along those lines.

I'm not that versed of the low-level stuff like this on each system, so just checking, as I might be completely wrong there. But, I do know some developers recently used HDMA to start thinking about increasing the frame rate of SNES Doom from 12 fps to 25 fps, which is a huge increase--and I'm talking about the original programmer who actually coded the SNES version of Doom in the first place--which means it can obviously be used to do things that people didn't even think of until recent times:

https://youtu.be/BIauSQ_hIgo?t=937

I guess it comes back to the same point for me: We either get results from a test that is set exactly the same on each system equally, without any obvious mistakes, and see how they all fare. Or we do a test that allows each system to be pushed to its absolute limits in the relevant areas and then see what each one is truly capable of under those conditions. But, obviously, we're still discovering stuff about the full capabilities of all three consoles even now, so that second scenario is gonna be real hard to measure imo. But, for sure, what we shouldn't do is assume we already know the full potential of each system based on what we've seen to date from them, or based on any bias and either incomplete or false information that's being spread around about any of them by bad actors, as then we just end up making some premature judgement about which is the fastest or best at whatever thing before someone even pushes them all equally to the their true max potential.

So, for now, despite these tests clearly not being perfect, what they did show me was that the CPU results were roughly around what people usually say, with the main caveat being that the guy accidently ran the SNES in the SlowROM mode at 75% of its actual CPU speed (the biggest blunder of any of the tests so far imo), and that the VDP results were very surprising and showed that while some of the stuff we commonly hear about these systems isn't particularly shocking, there's obviously a lot more to all of them than just one hardware component and its on-paper numbers.

It's all still interesting stuff though. And I'd like to see a bunch more tests like this, plus more that don't just obsess with comparing under-the-hood technical specs, but that actually compare the results you see on the other end of the process and how these systems fare there, like with the examples of the parallax scrolling above. Because, what we see, hear and play on each of these beloved consoles from the perspective of the end consumer and gamer actually interests me personally a lot more.

[Chilly Willy]

Those "benchmark" videos just demonstrate that while the person knows how to program, he knows very little about hardware. Understanding the processors and related chips at a hardware level is necessary to get the most out of a system. Many games don't need the most, so you don't need to understand the hardware to write those games. It's totally necessary to benchmark the systems. I also totally disagree with the use of emulators for benchmarking. The vast majority of emulators are written to play commercial games at full speed. As a result, they take many shortcuts to improve the speed of the emulation, even if it means not operating exactly like the target hardware. Common emulation optimizations include not emulating the limits of bus bandwidth. That would totally invalidate his VDP benchmark. Benchmarking MUST be done on the real hardware.

There are some emulators that strive to be cycle perfect, but those are rare and will specify in their description when they are. Such an emulator could be used for benchmarking, but I'd still only accept real hardware scores. It's easy to get real hardware and some kind of flash cart to run custom code. Do so. Just picking a handful of emulators and calling it good is lazy and ignorant. I down-voted both videos, and rightly so.

As to how layers contribute to the performance of a VDP, you not only need to consider the number of layers, but also the number of colors available to the layers. For example, while the SNES can have up to four tile layers, they cannot all have the maximum number of colors. Each layer added comes at the expense of the number of colors the layers can have. This indicates a fixed bandwidth for fetching the data during an active line. There are only so many bytes you can fetch, and then you divide those bytes between the layers that are active.

In general, sprite data is not fetched during the active part of the line, so it doesn't contribute to this limit in layers vs colors. The amount of data that can be fetched between active lines tends to be the limit for sprites, so the number of sprites you can have per line tells you about how much bandwidth you have in inactive areas of the display line.

[iNCEPTIONAL]

Those "benchmark" videos just demonstrate that while the person knows how to program, he knows very little about hardware. Understanding the processors and related chips at a hardware level is necessary to get the most out of a system. Many games don't need the most, so you don't need to understand the hardware to write those games. It's totally necessary to benchmark the systems. I also totally disagree with the use of emulators for benchmarking. The vast majority of emulators are written to play commercial games at full speed. As a result, they take many shortcuts to improve the speed of the emulation, even if it means not operating exactly like the target hardware. Common emulation optimizations include not emulating the limits of bus bandwidth. That would totally invalidate his VDP benchmark. Benchmarking MUST be done on the real hardware.

There are some emulators that strive to be cycle perfect, but those are rare and will specify in their description when they are. Such an emulator could be used for benchmarking, but I'd still only accept real hardware scores. It's easy to get real hardware and some kind of flash cart to run custom code. Do so. Just picking a handful of emulators and calling it good is lazy and ignorant. I down-voted both videos, and rightly so.

As to how layers contribute to the performance of a VDP, you not only need to consider the number of layers, but also the number of colors available to the layers. For example, while the SNES can have up to four tile layers, they cannot all have the maximum number of colors. Each layer added comes at the expense of the number of colors the layers can have. This indicates a fixed bandwidth for fetching the data during an active line. There are only so many bytes you can fetch, and then you divide those bytes between the layers that are active.

In general, sprite data is not fetched during the active part of the line, so it doesn't contribute to this limit in layers vs colors. The amount of data that can be fetched between active lines tends to be the limit for sprites, so the number of sprites you can have per line tells you about how much bandwidth you have in inactive areas of the display line.

Hey, I agree that the tests should be totally legit. But I've not seen any better from anyone else showing which console is the fastest at whatever things when either all are tested under the exact same conditions or all are tested in conditions that are absolutely optimal for each system respectively.

So, I think for these kinds of tests to be fair and equal, I guess we can't just assert our system of choice is the best at this or that until one of the two criteria are fully met, unless it's so beyond clear in some area that it doesn't need to be debated. Like, for example, we can say the Genesis CPU has a raw clock speed that's around 2 times faster than SNES and just a little faster than PC Engine, and the SNES can display four times as many colours on-screen as Genesis' and a little over half as many on-screen as PC Engine, from a palette that's 64 times bigger than both Genesis' and PC Engine's, and those kinds of set things. This is not accounting for any special coding tricks and the like that are unique to each system, which can affect and increase those numbers under various conditions, but that many people aren't even fully aware of and usually don't even know the true limits possible on each of the other consoles half the time either way.

And, I guess it comes back to a tech-spec number vs end result thing when it comes to those pixels on-screen then, because there's people talking about display pixels per frame and fetching bytes from VRAM and stuff like that, and then just something that's a lot more evident to most people such as having four full backgrounds plus sprites drawn to the screen vs one or two full backgrounds plus sprites drawn to the screen. I mean, even if we ignore the SNES' ability to draw more layers in its lower colour mode, it can just end up drawing either one background layer with more capability for whatever in that layer than PC Engine's one layer is capable of, or drawing two layers with pretty much exactly the same as Genesis can do with two layers similarly, give or take a little, such as a bit more versatility with how to use the tiles between the two layers on Genesis vs say having higher fidelity column scrolling on SNES for example.

So, maybe the real question here should be, what's more important in that case then, the tech-specs and various often misguided/misinformed claims by people online of one system's capabilities over the others, or the actual end results?

I guess, again, it goes back to why I made the original post in the first place: Because, what you can see, hear, and play is what ultimately matters at the end of the day, and those clips clearly show what each console is actually capable of relative to the others in real output games when it comes to parallax scrolling in this particular case.

[turboxray]

Those "benchmark" videos just demonstrate that while the person knows how to program, he knows very little about hardware. Understanding the processors and related chips at a hardware level is necessary to get the most out of a system. Many games don't need the most, so you don't need to understand the hardware to write those games. It's totally necessary to benchmark the systems. I also totally disagree with the use of emulators for benchmarking. The vast majority of emulators are written to play commercial games at full speed. As a result, they take many shortcuts to improve the speed of the emulation, even if it means not operating exactly like the target hardware. Common emulation optimizations include not emulating the limits of bus bandwidth. That would totally invalidate his VDP benchmark. Benchmarking MUST be done on the real hardware.

There are some emulators that strive to be cycle perfect, but those are rare and will specify in their description when they are. Such an emulator could be used for benchmarking, but I'd still only accept real hardware scores. It's easy to get real hardware and some kind of flash cart to run custom code. Do so. Just picking a handful of emulators and calling it good is lazy and ignorant. I down-voted both videos, and rightly so.

As to how layers contribute to the performance of a VDP, you not only need to consider the number of layers, but also the number of colors available to the layers. For example, while the SNES can have up to four tile layers, they cannot all have the maximum number of colors. Each layer added comes at the expense of the number of colors the layers can have. This indicates a fixed bandwidth for fetching the data during an active line. There are only so many bytes you can fetch, and then you divide those bytes between the layers that are active.

In general, sprite data is not fetched during the active part of the line, so it doesn't contribute to this limit in layers vs colors. The amount of data that can be fetched between active lines tends to be the limit for sprites, so the number of sprites you can have per line tells you about how much bandwidth you have in inactive areas of the display line.

That whole test setup is soooo cringe. It's pretty obvious the guy doesn't know what he's doing. There's soo many things wrong in that video, but one of the most glaring things wrong, is he's trying to write to SNES vram during active display!! NOT gonna happen on the real system hahah. SNES9x is an old and inaccurate emulator. You would have to restrict the SNES example to only write during vblank to get the correct timings/length. Why is he avoiding the video DMA?

I mean, the benchmark itself is just so pointless - it literally doesn't show anything. His pseudo C code isn't even written correctly on the ASM side.. there's no indirection (pointer/array + offset of "tile[n]" written to the display port).. it's literally just a counter he's writing to vram in all three systems.

The PCE version is about 58% slower than it needs to be, for no reason. I'm not even sure how this is supposed to test the "video processor" performance, especially the point when all the examples on each system are tightly cpu bound. The fact that he doesn't understand why the MD one would take longer (stalling the cpu from filling the FIFO too fast during active display) - means he doesn't even understand the video hardware he's trying to test - yet his video presentation and tone is one of authority and experience.

[Chilly Willy]

You can't compare clock rates directly. While the Genesis has a faster clock rate, it take multiple cycles to do instructions. The quickest instructions take four cycles, and you can quickly run over a dozen cycles by working on longs and using certain addressing modes. In contrast, the 6502/65816 tends to do most instructions in one or two cycles. When operating on bytes in the zero page, the 6502 to whip the 68000's butt. However, working on words in larger arrays in memory, and doing more complex operations, the 68000 can win handily. You can tailor tests to favor either processor. I think the TG16 is actually the fastest processor of the bunch since it's clocked nearly as fast as the Genny, but being a 6502 derivative, it's doing operations in very few clocks. Where it loses out is that it lacks DMA to transfer data to vram. The block move commands in the TG16 processor aren't really that efficient, either. I think many games use custom routines to set vram for best speed. The other major lack on the TG16 is there is only one background layer. Most games are programmed around using at least two layers, so it's harder to make a port to the TG16 that still looks good on some games. The good thing about the TG16 is the number of palettes. You don't need to redo graphics to use a limited number of colors.

[iNCEPTIONAL]

You can't compare clock rates directly. While the Genesis has a faster clock rate, it take multiple cycles to do instructions. The quickest instructions take four cycles, and you can quickly run over a dozen cycles by working on longs and using certain addressing modes. In contrast, the 6502/65816 tends to do most instructions in one or two cycles. When operating on bytes in the zero page, the 6502 to whip the 68000's butt. However, working on words in larger arrays in memory, and doing more complex operations, the 68000 can win handily. You can tailor tests to favor either processor. I think the TG16 is actually the fastest processor of the bunch since it's clocked nearly as fast as the Genny, but being a 6502 derivative, it's doing operations in very few clocks. Where it loses out is that it lacks DMA to transfer data to vram. The block move commands in the TG16 processor aren't really that efficient, either. I think many games use custom routines to set vram for best speed. The other major lack on the TG16 is there is only one background layer. Most games are programmed around using at least two layers, so it's harder to make a port to the TG16 that still looks good on some games. The good thing about the TG16 is the number of palettes. You don't need to redo graphics to use a limited number of colors.

Yeah, that sounds fair enough to me.

I guess it all comes down to how you do the best you can with the specific console's advantages and disadvantages.

And, like you kinda said, the extra layers and/or colours can sometimes allow for things that pure grunt can't quite fake, while pure grunt also has its own advantages in certain uses too, so I guess you choose what it is you want to convey to the player ultimately.

I'm still regularly impressed with how great a job the little PC Engine does so much of the time, especially in overcoming the single background layer limitation to create some lovely parallax and the like.

It's strange though, that in a comparison like this, it doesn't easily have the most colours on-screen (not sure why not): https://youtu.be/s4pOvvUVIlI

I presume it really should though, and maybe Capcom just didn't take full advantage of its capabilities there, which is a shame. But, either way, Street Fighter II still impresses me greatly on the PC Engine. It looks very nice, sounds pretty good too, and plays great (if you have a 6-button controller).

And I always come back to what we see and hear on the TV and what we feel when we control and play the games ultimately.

[Chilly Willy]

I'm still regularly impressed with how great a job the little PC Engine does so much of the time, especially in overcoming the single background layer limitation to create some lovely parallax and the like.

Yeah, they did a great job on many of the games. They learned to eek every little bit out of that console.

It's strange though, that in a comparison like this, it doesn't easily have the most colours on-screen (not sure why not): https://youtu.be/s4pOvvUVIlI

I presume it really should though, and maybe Capcom just didn't take full advantage of its capabilities there, which is a shame. But, either way, Street Fighter II still impresses me greatly on the PC Engine. It looks very nice, sounds pretty good too, and plays great (if you have a 6-button controller).

I presume it's because the Genesis and PCE are similar in how they do their graphics: they have a 16 color playfield (two for the Genny) and 16 color sprites. They just have lots of palettes to allow different sets of 16 colors for different sprites compared to the layers. In the SNES 256 color mode, the primary layer can be 256 colors, so they probably blended some of the background assets to look a bit smoother, resulting in more colors.

This is a pretty good summary of the SNES graphics modes: https://www.youtube.com/watch?v=5SBEAZIfDAg

That channel has a number of videos discussing old console hardware.

[turboxray]

I presume it's because the Genesis and PCE are similar in how they do their graphics: they have a 16 color playfield (two for the Genny) and 16 color sprites. They just have lots of palettes to allow different sets of 16 colors for different sprites compared to the layers. In the SNES 256 color mode, the primary layer can be 256 colors, so they probably blended some of the background assets to look a bit smoother, resulting in more colors.

The SNES version, in that video, is not using 256 color tile mode. It's using 4bit tiles just like the PCE and Genesis. If you tried to use 8bit tiles on the SNES version, disregarding rom space, you wouldn't have enough room in vram for everything (yes, I verified this). It doesn't make sense to use that mode in a game like this. If you tried, you'd have to seriously restrict the number of tiles in vram.

It's strange though, that in a comparison like this, it doesn't easily have the most colours on-screen (not sure why not): https://youtu.be/s4pOvvUVIlI

The problem with that comparison video, is that it's trying to derive color fidelity and detail by simply looking at unique color counts. Unfortunately, these are not just plain bitmap systems. That total color count number is just but one part of the picture (pun intended).

For why the PCE version doesn't have a high color count.. is that you can only have so many 'shades' of a color in a 512 color palette compared to 32768 colors. You're going to have the same whites, greys, reds, etc on the PCE - even though they ARE their own color. They are not 'shared' colors, per se, but since they are the same value - the total count is going to be lower. So the total unique color count isn't going to show the color freedom you're getting with 16 BG palettes and 16 sprite palettes on the PCE. It doesn't show you the full scope of the color freedom/fidelity/detail. Which is why that video is a failure.


For example; I have the SNES rip of Blanka's level. Removing the sprites and HUD, it's 88 colors on the SNES. I converted it to PCE.. down to 73 colors. I could artificially increase that count on the PCE by going in and adding more unique colors here and there, but it's not going to mean anything other than a higher color count.

Yeah, they did a great job on many of the games. They learned to eek every little bit out of that console.

I disagree. The vast majority of games don't push the PCE hardware at all. And I have yet to see any crazy optimized code (everything that I've seen, debugging games - it just your basic average code). There is a LOT of untapped potential in the PCE that devs left on the floor. A large number of developers just treated it as a "Famicom with extra knobs".


https://www.youtube.com/watch?v=1iq8nQ2Bd80
^ This was dead simple to do. There's no crazy code or optimizations. It's just a simple concept and execution. Lot of cpu resource left over too in the frame.

https://www.youtube.com/watch?v=uF6EzZ59Ga8
https://www.youtube.com/watch?v=peApmQFnn24
^ Nothing special. Just simple tilemap graphics in high res mode.

There's a lot more than this..

[iNCEPTIONAL]

I disagree. The vast majority of games don't push the PCE hardware at all. And I have yet to see any crazy optimized code (everything that I've seen, debugging games - it just your basic average code). There is a LOT of untapped potential in the PCE that devs left on the floor. A large number of developers just treated it as a "Famicom with extra knobs".


https://www.youtube.com/watch?v=1iq8nQ2Bd80
^ This was dead simple to do. There's no crazy code or optimizations. It's just a simple concept and execution. Lot of cpu resource left over too in the frame.

https://www.youtube.com/watch?v=uF6EzZ59Ga8
https://www.youtube.com/watch?v=peApmQFnn24
^ Nothing special. Just simple tilemap graphics in high res mode.

There's a lot more than this..

Yeah, the same is true of SNES.

I've seen a lot of amazing stuff pushing the Genesis to its limits in recent times, and you've shown some examples of the PC Engine doing some cool things there too, but the SNES community really isn't showing off the SNES' full potential for the most part.

I mean, it's so bad on SNES that I honestly can't even link you to a decent demo showing a bunch of gorgeous high-colour images. And, with an 8bpp 256-colour mode as standard (two of them actually), before any advanced DMA and raster tricks and the like are used, or even just basic use of the SNES' direct colour mode for BG1 or standard HDMA and colour math capabilities, I think it's clear the SNES could produce some beautiful results there alone.

Here as some of my own SNES 8bpp 256-colour 256x224 examples (using other people's art):

1.png (51.56 KiB) Viewed 115538 times

2.png (48.08 KiB) Viewed 115538 times

3.png (34.7 KiB) Viewed 115538 times

Note: Any black bars/borders are just me being lazy and not finding images that fit the SNES' aspect ratio properly, or even just cropping them to fit exactly.

Kinda curious what could be achieved with images in SNES' 512x448 mode now too, especially after seeing your lovely PC Engine examples in 512x224 resolution. These would be limited to 4bpp and 128 colours as standard on SNES before any tricks are employed, which is apparently around the same you're using in your examples on PC Engine at 4bpp and around 100-150 colours (although the SNES palettes would also be made from that 32,768 master palette), but it would definitely be something worth experimenting with imo.

And then there's all the other background modes that go largely ignored on SNES. I mean, I've seen a single example of Mode 6's 512x448 column scrolling in use, ever, and it's about as uninspired as you could get:

https://youtu.be/V0geBZzwe1U

I'm not a SNES programmer, so I can't go out and directly create amazing demos to show what the system is really capable of, but I have tried to highlight some cool stuff on it at least, hopefully as a bit of inspiration for those who can program for it:

https://inceptionalnews.wordpress.com/2 ... -graphics/

And two of those were my own proof of concepts created in Game Maker 8.1 (which have since been coded by a couple of talented SNES programmers and tested to make sure they'd work on the actual console as intended):

https://youtu.be/IyrOCNQc_rs

https://youtu.be/oCiSEChgjC4

Here's a few more of my proof of concepts for SNES too:

https://www.youtube.com/watch?v=-WO-sr04GY8

https://www.youtube.com/watch?v=z9Cd4lnOfI4

https://www.youtube.com/watch?v=UFj94lVOmqI

https://www.youtube.com/watch?v=XxWyYVBYCFc

https://www.youtube.com/watch?v=0ezX39kdzwY

https://www.youtube.com/watch?v=Mj0cP24ThPM

I guess and indeed hope there's a lot more to come from all three consoles. . . .

PS. You're doing some great work there on PC Engine to prove just how far it can be pushed to both show off its full capabilities and overcome its inherent limits, Turboxray. Kudos on the effort.

PPS. Your parallax demo made me think of this, as it's also using the sprites to fake an extra foreground scenery layer on top of the SNES' single Mode 7 background:

https://youtu.be/spVwBD6NOVI