Still though, the 32x's current software doesn't really show most of its potential (not just graphics, but sound to a huge degree), and marketing/management has a lot more to do with such things than technical limitations. (tech cost/performance/programmability are all significant issues, but generally take a back seat to actual PR/funding/market/business/management descicions as far as software support quality/quantity, sales, etc, etc go -good hardware can help to counter negative areas, but it takes really bad hardware to totally ruin a company with good funding/marketing/management/PR -the PCFX is probably one of the closest examples to that except that NEC had already been making some major mistakes in their management end as well, both in Japan and obviously to a massive extent with their failure in managing their western markets -the Saturn obviously wasn't THAT bad at least, neither was the 32x, but Sega had many other problems that caused the real trouble -and exacerbated the issues that the 32x and Saturn did inherently exhibit)
In any case still more potential than it demonstrated at the time. (the lack of PWM DMA documentation hindered high quality sampled sound considerably -and likewise hindered potential for efficient SH2 use, be it dedicating the slave for a 32 channel sample music/sound engine or something like a simpler 4-8 channel player with a lot more coprocessing for graphics handled by the slave -like 3D math or ray-casting computation)
There's the limits of ROM speed of the time, efficiently allocating resource of both CPUs, software rendering limits in general, pracitcal limits of ROM sizes, limits of on the fly decompression, limited RAM to decompress into ahead of time, etc.
The bigger limit of RAM would perhaps be difficulty of porting PC or newer console games that demand far more RAM. (similar games or remakes using custom engines could be possible, but direct ports for many games would be impractical or impossible -Doom barely managed to be hacked down to 32x compatible levels similar for GBA, but the SNES version required a custom engine in part because of RAM and in part because of very tight resource limitations -the SNES version of wolf3D may have been a custom engine too, but I'm not sure)
More 2D in the short run would have been nice (ie before the market really declined for that ~1996), and Ray Man is one of those holy grail canceled games for the 32x. (and one that Chilly Willy mentioned being personally disappointed with)To be honest though, what I'd love to see, along with more elaborate polygonal 3D games, is more 2D games. Still very disappointing to see that Chilly is probably the only homebrewer making stuff for the 32X. How is Wolf32X coming along anyway?
Actually, with my recent observation of Mortal Kombat II's use of 32x graphics (and several other games that used 32x for sprites but not much BG), using the 32x for the main BG with MD graphics for foreground and sprites probably should have been more common (especially for games with a huge chunk of solid BG -definitely the case in MK), or games doing sprites and main foreground (with the foreground taking a major chunk of the BG) and leave MD for the far BG only (which is what Kolibri does).
Using the 32x just for sprites may have been simpler, but generally barely made a noticeable difference for the color (MK II's MD sprites look almost the same as MKII 32x -Primal Rage isn't much better either) and thus ends up quite wasteful.
Plus, if ROM space is the main issue, the 32x portion of the BG graphics could be mainly compressed and indexed (namely using 16 color indexed textures with compression on top of that) and unpack them to 32x work RAM (maybe cram a little into unused framebuffer space too) maybe with a limited amount of uncompressed animation used on the fly, or using simple/fast compression schemes like RLE. (in better cases, you could actually save a significant amount of ROM space over an equivalently detailed/animated MD version due to the increased amount of RAM available to decompress into -32x RAM on top of MD RAM)
For fighting type games, you'd probably end up decompressing as much as you can and resorting to uncompressed (or simply compressed) streamed graphics if necessary (doing 4-bit to 8-bit look-up or advanced lossless decompression would probably be impractical for on the fly loaded stuff -unless maybe if the slave SH2 had a lot of resource left that could be dedicated to such tasks)
However, for sidescrollers (especially rather linear ones) or similar games, more extensive periodic updates using more heavily compressed/packed memory might be realistic (though you might end up with some slowdown if large chunks were updated at once -more gradual updates could possibly be buffered with minimal hit to game performance), this would be rather comparable to CD based games doing on the fly updates (though with fewer headaches in some respects -lack of low CD bitrates but with more overhead for data decoding). For that matter, some existing MD games may do some rather heavy decompression on the fly. (not sure if any actually do that though)