Comparison of 5th generation ("32/64-bit") game console hardware

[sheath]

Yeah, I don't know why the VDP2 wouldn't easily be able to lock a scaling floor to a non-scaling 2D background better than Virtua Fighter 2 did. Also, I think Last Bronx's backgrounds are all VDP2, though there isn't any reason why VDP1 couldn't have contributed some of the 2D scrolling layers. In Fighters Megamix and Fighting Vipers I think VDP1 only does the characters, lighting, dithered transparency and 3D cages.

If VDP2 is doing the floors in VF2 I bet it is also doing them in Virtual On.

[kool kitty89]

I suppose if the resolution was high enough for the texture these could be 4-bit too. I guess I was errantly assuming I could see individual pixels if it was 4-bit color.

Actually, it would be the opposite: 4-bit textures would (due to low memory usage per pixel) tend to be significantly higher resolution than higher color (uncompressed) textures.
Color can be an issue too, but since you're working with a large CLUT (or many sub-palettes to use), there's still a lot of flexibility there too. (potentially more so than using a fixed 256 color palette too -in the same way that Neo Geo games can have better color than fixed 256 color palette games -there's also some potential flexibility of palette swapping facilitated by numerous 16 color palettes vs a global palette, and some other trade-offs too)

It's definitely NOT a case like PS2 vs Dreamcast where the DC has texture compression (effective 1 bit per pixel textures) and the PS2 uses simple color look-up by default -software decompression aside. (so nominally lower quality, more RAM -even for 4-bit- and more bandwidth needed to read/fetch textures)
The Xbox and GC also have advantages of texture compression, though I think both of those comply with the defacto-standard S3 style compression (licensed by MS for directX) which actually isn't as good as PowerVR's scheme in some respects. (still much better than look-up/no compression or simple RLE compression, and the S3 compression scheme is still the foundation for modern texture compression algorithms)

Also, I'm not sure the rings in VF2 can be VDP2 Floors (2D) because they have sides, I suppose it could be a raised specific size layer with polygons under it and attached to it. If they could do that, I would expect to see a lot more Saturn games with multi-tiered VDP2 floors though.

I believe quite a few Saturn games (especially Sega developed/co-developed ones) tend to use VDP2 flat ground/floor/ceiling sections where applicable, and also use polygons on the ground/etc to complement that.

[sheath]

I finally got around to testing some 3D games in MAME with my new (to me) Athlon X2 6400+. The Tekken games now run flawlessly, with the exception of some music stuttering and a little bit of frame droppage in Tekken 3. Tekken 3 Arcade is interesting graphically. The floors are like the previous Tekken games, easily replicated as 2D floors, but the background is more like a combination of line scroll and flat polygonal 3D objects.

I know that Tekken 3 on the PS1 is just the flat scaling floor with a flat box of a textured background around it, the Arcade game goes a lot further to making that background look more 3D with simulated parallax. It is almost the same effect as Last Bronx or Dead or Alive on Saturn really. Except Tekken 3's floors warp badly as the camera moves around them of course.

Oddly, there doesn't seem to be a single good quality Youtube video of it. I might have to take care of that soon.

[kool kitty89]

I finally got around to testing some 3D games in MAME with my new (to me) Athlon X2 6400+. The Tekken games now run flawlessly, with the exception of some music stuttering and a little bit of frame droppage in Tekken 3. Tekken 3 Arcade is interesting graphically. The floors are like the previous Tekken games, easily replicated as 2D floors, but the background is more like a combination of line scroll and flat polygonal 3D objects.

I know that Tekken 3 on the PS1 is just the flat scaling floor with a flat box of a textured background around it, the Arcade game goes a lot further to making that background look more 3D with simulated parallax. It is almost the same effect as Last Bronx or Dead or Alive on Saturn really. Except Tekken 3's floors warp badly as the camera moves around them of course.

Oddly, there doesn't seem to be a single good quality Youtube video of it. I might have to take care of that soon.

Isn't the Arcade board used for Tekken 3 (System 12) just a tweaked version of the PSX hardware with double the VRAM? (looks like a minor upgrade to the older System 11 -which was even closer to the PSX hardware, though also with 2x the VRAM)

That said . . . I'm not sure whether those boards run purely from RAM+mass storage (HDD/optical disc) or if ROM is employed as well (more like the ST-V), and use of significant amounts of fast ROM could obviously be a major mitigating factor for performance. (on top of the added RAM)

[Team Andromeda]

Isn't the Arcade board used for Tekken 3 (System 12) just a tweaked version of the PSX hardware with double the VRAM? (looks like a minor upgrade to the older System 11 -which was even closer to the PSX hardware, though also with 2x the VRAM)

In the official Namco PR statement Namco said the CPU was 50% more powerful. BTW System 11 used a different sound set up to that of the PS

I'm not sure the rings in VF2 can be VDP2 Floors (2D) because they have sides

It's the VDP II and a dead give away is a lack of any polygons folding or any glitching, unlike the VDP I polygons sides

[kool kitty89]

I finally got around to responding to this. (I've been wanting to for a while, but hadn't given it the time )

The only things difficult with the PS2 compared to PC were the clipping of polygons, the management of video memory, and not having full colour blending. There were samples showing the first, and devs had been managing memory before, and the 3rd could be handling by bruteforce multipass, or clever hacks. Texture compression was supported in hardware via palletted textures, just like in the PS1.

Yes, but paletted textures are far more limited (in both visual quality and effect compression ratio) compared to techniques like what PVR and S3 were using (and subsequent cards).
Most PC accelerator cards were supporting more advanced texture compression by around 1999. (Rage 128 Pro, S3 Savage, PowerVR, and GeForce 256 all had such texture compression support -not sure about RIVA, Matrox G400, or Voodoo 3)

By supporting CD at the start there would be better profit margins on software, and less inventory risk. Regarding management/PR - do you really think Atari management really screwed things up that badly, or did they just make the most use of their low budgets for the Jaguar.

It think it was both (sustained) management problems and financial issues (and PR issues on top of that -due to limited market share and financial stability, among other things), and each of those problems exacerbated the other in a vicious cycle. (weak management = worse cashflow = worse management, etc -along with ever weakening internal staff and resources)

By 1993, Atari was more or less beyond the point of no return and would have needed a miracle (like a dramatic infusion of good management as well as heavy investment capital) to really pull off a mass market release. And that's exactly why I point out the much greater historical significance of Atari Corp in 1989-1990. (the time when they could have released a decent successor to the 7800 to compete on the mainstream console market -and/or, a proper followup to the ST for that matter -or, short of either of those, at least a moderately decent console to follow up the 7800, rather than nothing at all -which is what they ended up with)

That said, with Atari as they were in 1993, there was still a small chance for success with a product like the Jaguar (especially in Europe), and certain management and design decisions could have given the system much more potential, but it still would have been tight. (things like an even lower cost design -like stripped down to a single chip with no OPL or DSP- and CD-ROM standard, and -definitely- an emphasis on supporting the European market -PR was better there, effective advertising was far less costly, plenty of good software houses, etc -and if they managed to get a foothold in Europe, they'd have a better base to expand on with a niche market in North America too -if market distribution ended up somewhat like the ST, that would still have been far, far better than what the Jag ended up with historically)

There's no point supporting programmable CRY , or even a 256 colour pallette - like 24 bit support they are not core features. ( A minimal 16 entry look up table in the blitter would be enough to give 'sprite' expansion support )

I suppose so, and either saving that chip space from CRAM in general, or putting it towards other things (larger scratchpad, added buffers, etc -maybe even a small texture cache) could have been much more useful.

And yes, focusing on 16-bit color depth would probably be best for the time . . . 256 color would be limited (really useful only for saving framebuffer space on simple ports of VGA games and older console games -and better cases of those could be upgraded to higher color anyway), and 24/32-bit color would be too taxing on the system to be useful for most things aside from splash screens and some instances of FMV. (CRY could cater very well to FMV though)

OTOH, supporting a 4-4-4-4 RGBY/RGBI mode could be fairly useful for cases where added flexibility of color blending/shading would be needed and the lower luma resolution was acceptable. (and it meshes well with the CRY color scheme too -just bypass the ROM CLUT in favor of direct 4-4-4 RGB inputs and a 4-bit Y value rather than 8-bit -even simpler if they'd implemented CRY via 4 DACs rather than 3 multipliers and an external 24-bit DAC -since you could simply output those 4-bit values to the upper 4 bits of the DACs rather than having to interpolate luma via the multipliers; I wonder how much chip space 4 8-bit high-speed DACs would take compared to 3 fast 8-bit multipliers -you'd certainly save a bunch of pins and at least 1 more chip by handling DAC internally)

And that would also cater to the existing Jag blitter's 4 and 8-bit boundaries for pixel manipulation. (avoiding the problems with 15/16-bit RGB -which the blitter has no support for shading/blending) Plus, it would be somewhat more straightforward to convert RGB graphics to RGBI than CRY.

And the OP is only super fast for unscaled sprites, scaled sprites run more slowly - and rotated supported were only possible with blitter/gpu anyway.
The blitter already supports sizable source and destination buffers ( look at the docs ) , and you can copy textures to gpu ram to improve efficiency anyway.

The existing source and destination registers don't act as phrase buffers though, do they? (allowing reads and writes of groups of textels at a time, with proper transparency support for blits -rather than simple block writes/fills -and for handling scaled/rotated textels, not just plain pixel drawing modes)

The point was that scaled/rotated/texture mapping support could have been made much faster with a relatively modest amount of chip space (compared to OPL and CRAM -or the Z-buffer logic for that matter) by supporting source and destination phrase buffers or a small texture cache. (the latter would take more chip space -unless it was really small, in which case it would be less practical than phrase buffers -there's also the issue of organizing source textures such that each phrase defines an array of pixels rather than a line, especially for 4-bit indexed textures -have each 64-bit phrase map to a 4x4 array of pixels, very useful for rendering transformed textures, and have look-up/expansion done after the texture fetch -so source would hold 4-bit pixels and destination would hold 16-bit)

And, yes, if nothing else, a simple Jaguar-2 style phrase buffer (sans the texture cache) would be very helpful. (and copying to GPU RAM would certainly help too, especially for 2D games -where the hit to GPU performance would be less) -You'd definitely want a 16 color CLUT too, that's probably much more important than faster texture mapping. (keeping texture size down for both 2D and 3D games while avoiding the significant overhead of software texture expansion/decompression)

My argument is more about how the OP isn't really needed for any of the 2D games shown on Jaguar ( apart from SuperBurnOut ) as I think they would have been almost identical on a Jaguar with gpu+blitter + 320 pixel CRY mode only. Also most of the 3D games would also look similar.

I was thinking more in terms of what the Jaguar would have benefited from with proper software support at the time -and even so, there's still a massive argument in favor of using the blitter alone. (let alone a moderately beefed up blitter -namely better affine texture rendering support for scaling/rotating/texture mapping -far more useful for all sorts of games at the time than just plain scaling support)

( DOOM might take a hit but it could be modified to double up 160 to 320 in the gpu code to reduce that )

Why not just allow the VDC to natively support a variety of programmable resolutions down to 160 pixels wide? (if not even lower -and similar for vertical resolutions, perhaps via a line table like in the 32x's simple "Super VDP" -though that lacks programmable horizontal resolutions unfortunately, hence why Yeti 3D has to render pairs of pixels to do 1/2 res horizontal on a 320x112 display -low res support would be very useful, and an advantage over PCs too, since they had to rely on less effective pixel doubling or screen-shrinking to allow lower detail levels in games rather than allowing true lower resolution at full-screen)
Still much, much simpler than the OPL and no need for line buffers, but very useful. (and changing res on a per-line basis could allow for full-res status displays in the upper or lower boarder)
Doing low res also saves on framebuffer space, of course.

As I've said before, many existing 3D/pseudo 3D Jag games would probably be much better off if they'd used lower resolutions. (higher framerates, less RAM eaten by the framebuffer, etc -and, while lower res is certainly less attractive, it's much better looking than using a smaller screen window, very low polygon counts, lack of textures, or suffering stuttery framerates at full res -and games could vary from 1/2 res like doom to 1/4 res halving vertical as well)
It's just a guess, but it seems most likely that Carmak's Quake port to the Jaguar probably would have been running at something like 160x112, assuming it used anywhere near the polygon counts and textures as the PC game.

And even with no enhancement to the blitter's texture mapping ability, using low res would significantly reduce the disadvantage there too (the lower resolution used, the less advantageous added buffering/caching would be for textures, so the simple single-pixel texture mapping isn't at as big of a disadvantage -though it's still slower, and 16 color CLUT support would be very useful).
Rasterization overhead is significantly cut back at lower res too . . . and the advantage of fast, heavily buffered gouraud shading would also become less significant. (though not insignificant -for similar reasons as with the texture mapping)

Why? You would still need gpu assist anyway - as the modification would be to the DDA line algorithm. If you are talking about full warping then that's a lot more complex - and just adding trap. support and a phrase buffer would be better ( as done in Jag II )

So the Jaguar II's rasterization method is logically simpler than the warping used in the Saturn? (as well as avoiding the artifacts and inefficency of overdraw in warped quads)

....I think you're drifting back to the 'perfect hindsight' of adding everything you can think of to a Jaguar chipset. That's a nice topic , but I'm thinking more of something that could cost reduce the Jaguar as much as possible to make it possible to include a single speed CD mechanism. ( Not CD-ROM , just audio CD with all decoding done in software ) - so no design changes beyond the minimum needed, and entire sections removed ( Jerry + 68k )

Not so much perfect hindsight as drifting between the context of a 1993 Jaguar and a Jaguar developed as a successor to an intermediate console (in which case Atari would presumably have significantly better cash flow, PR, etc -especially in regards to North America where the ST wasn't very significant).
In which case, a later (ie late 1994 launch) and somewhat more advanced design would have been preferable and feasible.

However, from the 1993 perspective (as it was), what you suggest (stripped-down, streamlined, single-chip Jaguar-derivative) sounds very attractive for the time:
in addition to lower cost, the simpler design approach should have allowed for more focused trouble shooting and bug fixes as well as a generally easier to program architecture. (and, had they focused on no 68k at all, they obviously would have needed to design the GPU to be fully functional as a bug-free CPU)
And, as it is, the J-RISC architecture is very CPU like and is relatively easy to learn assembly for any experienced ASM programmer (it's relatively similar to the 68k instruction set too in some respects), and it's only the bugs that made it problematic. (and it's obviously quite fast too . . . no hardware cache, but a fast local and 64-bit DMA to DRAM, very fast ALU performance, very large set of registers, support for special high-speed/low-latency interrupts, etc)

And yes, a bare-bones CD drive and interface would obviously be preferable. (be it 1x or overcloked to 2x as in the actual Jag CD -albeit that was done in 1995 and with a licensed chipset, so maybe not practical for an off the shelf 1993 example)

I dont think it would affect the quality of the launch titles at all - Cybermorph would be almost identical, Raiden and TrevMcFur would also be identical. Even the top titles such as AVP, Rayman, and Tempest2000 would be as good on this cost reduced platform, but the cost of software manufacturing would be far less , and the cachet of a CD drive might help sales rise above the pitiful 125k that Jaguar actually managed in real life.

Yes, definitely, and software support almost certainly would have been better due to that lower risk. (Atari's PR would still limit things though, and management decisions would be an issue too -as it is, Atari missed out on major PC games that weren't tied to contracts with any other console platform . . . though it's unclear whether those games were attainable or not -they obviously worked with id fairly well, but companies like Sierra, Lucas Arts, Epic, or Apogee had very significant games for the time -and some lower profile stuff that also would have fit very well on the system- -There's EA/Origin too, but there'd have been the 3DO conflict at that point on top of EA's association with Sega; Infocom/Activision had some very interesting stuff that could have fit well on the Jaguar too, and a few others -having Commanche on the Jaguar early on would have been pretty significant as a graphical showcase if nothing else)

That said, there's still the issue of PR with retailers and the (at least initial) higher margins that would be applied to Atari products to cover the risk. (so the cost advantages of CD would be less obvious to the consumer early on, unless maybe Atari managed some special deals with retailers or got backing from major investors and boosted PR)
That would probably be less of a problem in Europe though . . . plus any releases from big-name 3rd party publishers would probably merit better retail PR too.

Some titles might actually run better - as even without a cache running GPU code from main memory would be at a minimum as good performance as the 68000 at best.
By 95 Atari could slide into the low price range under Saturn and PSX , and be profitable with a single custom chip design.

Not to mention the advantages of games designed around CD storage. (some limits over carts, obviously, but tons of advantages for designing levels with more unique graphics/animation -or loads mid-level to add even more detail/variety- in addition to multimedia capabilities -streaming music, speech, FMV, etc)

A streamlined, CD-based Jaguar like you propose should have been capable of handling most PC games up through ~1995 at reasonable quality. (some could be better overall, others mixed with trade-offs, and some 1995 games generally weaker than on a fast PC but with some potential advantages -like color/shading- and still probably decent performance -1996 onward would get more and more difficult to keep up though, same for contemporary console games . . . even so, such a Jag-derivative probably would have handled the likes of Quake, Tomb Raider, and Duke 3D decently well if optimized enough -probably running low resolutions)

[Crazyace]

Yes, but paletted textures are far more limited (in both visual quality and effect compression ratio) compared to techniques like what PVR and S3 were using (and subsequent cards).
Most PC accelerator cards were supporting more advanced texture compression by around 1999. (Rage 128 Pro, S3 Savage, PowerVR, and GeForce 256 all had such texture compression support -not sure about RIVA, Matrox G400, or Voodoo 3)

4 bit textures are generaly limited compared to DXT , but 8 bit textures are quite high quality - and in some cases 4 bits are still good enough. The fillrate ( especially for alphablending ) was a huge feature though

Why not just allow the VDC to natively support a variety of programmable resolutions down to 160 pixels wide? (if not even lower -and similar for vertical resolutions, perhaps via a line table like in the 32x's simple "Super VDP" -though that lacks programmable horizontal resolutions unfortunately, hence why Yeti 3D has to render pairs of pixels to do 1/2 res horizontal on a 320x112 display -low res support would be very useful, and an advantage over PCs too, since they had to rely on less effective pixel doubling or screen-shrinking to allow lower detail levels in games rather than allowing true lower resolution at full-screen)
Still much, much simpler than the OPL and no need for line buffers, but very useful. (and changing res on a per-line basis could allow for full-res status displays in the upper or lower boarder)
Doing low res also saves on framebuffer space, of course.

Why bother though - just have a simple 320x240 16bit CRY buffer and let the developers use it.

As I've said before, many existing 3D/pseudo 3D Jag games would probably be much better off if they'd used lower resolutions. (higher framerates, less RAM eaten by the framebuffer, etc -and, while lower res is certainly less attractive, it's much better looking than using a smaller screen window, very low polygon counts, lack of textures, or suffering stuttery framerates at full res -and games could vary from 1/2 res like doom to 1/4 res halving vertical as well)
It's just a guess, but it seems most likely that Carmak's Quake port to the Jaguar probably would have been running at something like 160x112, assuming it used anywhere near the polygon counts and textures as the PC game.

No idea about Quake - but I think lower res would be negative - more than reduced framerate. And there were as many Jaguar games that looked ok at 320x240 anyway as there were those with really poor framerates.

So the Jaguar II's rasterization method is logically simpler than the warping used in the Saturn? (as well as avoiding the artifacts and inefficency of overdraw in warped quads)

It's a very small step up from the method used in software on the first Jaguar - just look at how it is described in the midsummer doc.

However, from the 1993 perspective (as it was), what you suggest (stripped-down, streamlined, single-chip Jaguar-derivative) sounds very attractive for the time:
in addition to lower cost, the simpler design approach should have allowed for more focused trouble shooting and bug fixes as well as a generally easier to program architecture. (and, had they focused on no 68k at all, they obviously would have needed to design the GPU to be fully functional as a bug-free CPU)
And, as it is, the J-RISC architecture is very CPU like and is relatively easy to learn assembly for any experienced ASM programmer (it's relatively similar to the 68k instruction set too in some respects), and it's only the bugs that made it problematic. (and it's obviously quite fast too . . . no hardware cache, but a fast local and 64-bit DMA to DRAM, very fast ALU performance, very large set of registers, support for special high-speed/low-latency interrupts, etc)

And yes, a bare-bones CD drive and interface would obviously be preferable. (be it 1x or overcloked to 2x as in the actual Jag CD -albeit that was done in 1995 and with a licensed chipset, so maybe not practical for an off the shelf 1993 example)

Yes - that's the plus side, a cheaper Jaguar to make ( no Jerry and 68k offsets the addition of a single speed CD ) with no real difference in game performance

[kool kitty89]

4 bit textures are generaly limited compared to DXT , but 8 bit textures are quite high quality - and in some cases 4 bits are still good enough. The fillrate ( especially for alphablending ) was a huge feature though

Yes, but 4-bit indexed textures will take much more space than S3/PVR compressed textures of similar resolutions, not to mention the advantages for cache fill rates with highly compressed textures (decompressed at full speed)
8-bit textures would compare even less favorably in terms of memory restrictions.

Why bother though - just have a simple 320x240 16bit CRY buffer and let the developers use it.

It would make sense to at least include half res modes though (vertical and horizontal), and better if you could choose on a scanline basis. Having high res and RGB modes would be useful too, but not as significant. (mainly useful for high res static screens and menus, and maybe simpler ports of some RGB based games -though converting to CRY really shouldn't be an issue -using 24-bit RGB for high res still and FMV could be useful too, but CRY should cater relatively well to that too with custom derivatives of YUV based codecs adapted to CRY, and should be faster in CRY too)

No idea about Quake - but I think lower res would be negative - more than reduced framerate. And there were as many Jaguar games that looked ok at 320x240 anyway as there were those with really poor framerates.

It's a significant trade-off to make, but definitely one that could be worthwhile IMO. Look at Chilly Willy's 32x Yeti 3D demo . . . that would look terrible at higher resolutions due to the horrible framerate, but cutting it to 160x112 makes it far more playable. (and in that case, it's actually scaled to 320x112 since the 32x doesn't support lower horizontal res -it would be significantly faster still with a true 160 width mode)

Doom on the Jaguar wouldn't be anywhere near as good if it ran at 320x200, and AVP (among a few others) really should have made the sacrifice too due to the framerate issues. 3DO Doom definitely should have run at lower res too (even if using the Cel to scale it), instead it was stuck in high detail with variable screen size. (so you can opt for a postage stamp sized window to play more smoothly, but not a blockier full-screen display -especially significant for ray-casting engines since halving horizontal resolution will roughly double performance due to halving the numbers of columns to cast rays for -unlike polygon games where the 3D math overhead stays the same, but the rasterization overhead/bandwidth decreases)

It would, again, be especially important for texture mapped polygonal games on the Jaguar, at least if it still had similarly primitive/limited texture mapping capabilities. (or even with a phrase buffer like the Jag II -well short of heavier buffering and/or a texture cache)

It's a very small step up from the method used in software on the first Jaguar - just look at how it is described in the midsummer doc.

If they could make some trade-offs to include that in the Jaguar I, it would be extremely significant for reducing GPU overhead for polygonal games. (even more so if they'd managed to double buffer the blitter registers)

That would probably be a lot more important to include than improved texture mapping. (though a 16 entry CLUT would still be very significant and a simple 64-bit destination phrase buffer for texture mapping would be a relatively small use of chip space too -cutting out the OPL, line buffers, and CRAM would be huge savings, even with the UART and audio DACs added . . . and maybe the wavetable ROM -and yes, I know the actual Jaguar's PWM DACs ended up being unused, but I'm assuming they managed to get those working properly in this context)

Yes - that's the plus side, a cheaper Jaguar to make ( no Jerry and 68k offsets the addition of a single speed CD ) with no real difference in game performance

Yes, and maybe cost effective enough to actually give Atari a realistic chance to establish itself as an early next-gen 3D-capable multimedia console and later on an attractive budget niche console capable of cut-down versions of new gen games (vs other budget consoles being limited to last-gen hardware and virtually no new games).
And the multimedia aspect shouldn't be underestimated either: there's a ton of FMV/multimedia games on PCs/3DO/MCD/etc that were hot at the time, and the Jaguar (even limited to 320x240 CRY and 1x CD-ROM) should have managed in impressive quality for the time. (similar to some 3DO games and generally better than 256 color PC games, perhaps better than 3DO if a customized codec was developed to take advantage of the GPU's performance -not sure if its DCT abilities are fast enough for MJPEG style stuff, but at least something closer to TrueMotion, better than Cinepak)

Atari was in pretty bad shape all around at that point (1993), but with a streamlined system like that and the right management, they just might have carved a new niche for themselves. (or rekindling an old niche -since the 7800 filled a similar niche in the late 80s, though the Jag had potential for much better software support)
Establishing the system in Europe early on would have been very important regardless since they didn't have the reputation or resources to pull off a full US launch successfully (unless they managed to get more investment support), and Japan would be pointless to attempt unless they could license it to a major JP distributor. (Bandai might have been an option -given their interest in joining the console market- or perhaps NEC -since the jaguar would at least have been much more competitive than the heavily underpowered PCFX, and much cheaper to manufacture too)


That said, I still think they'd have been in a much better position had they released even a mediocre successor to the 7800 around 1989 (maybe 1991 if it was better than mediocre). The STe chipset, Panther, and maybe Slipstream designs (exactly as they are) were both pretty mediocre in practical performance and marketability, but either probably would have been better than nothing (which is what happened) and decent in the budget niche category. (and they wouldn't have to make the Jag backwards compatible with the older system either -so keep engineering and manufacturing cost/complexity down at the expense of no compatibility -which is of arguable marketing value for consoles anyway, and never a make or break issue -not so for computers, but that's another topic)

[Crazyace]

Yes, but 4-bit indexed textures will take much more space than S3/PVR compressed textures of similar resolutions, not to mention the advantages for cache fill rates with highly compressed textures (decompressed at full speed)
8-bit textures would compare even less favorably in terms of memory restrictions.

S3 textures are 4 bit ( PVR can go to 2 bit in the best cases ) - PVR died though, as it's really just a more lossy form of pallette texture ( each index mapping a 2x2 block of texels rather than just 1 ).

It would make sense to at least include half res modes though (vertical and horizontal), and better if you could choose on a scanline basis. Having high res and RGB modes would be useful too, but not as significant. (mainly useful for high res static screens and menus, and maybe simpler ports of some RGB based games -though converting to CRY really shouldn't be an issue -using 24-bit RGB for high res still and FMV could be useful too, but CRY should cater relatively well to that too with custom derivatives of YUV based codecs adapted to CRY, and should be faster in CRY too)

I disagree, having low res modes would be a step back - 320 was a minimum ( well 256 to 320 ) for computers and consoles for almost a decade already at the time of the jaguar launch.

Doom on the Jaguar wouldn't be anywhere near as good if it ran at 320x200, and AVP (among a few others) really should have made the sacrifice too due to the framerate issues. 3DO Doom definitely should have run at lower res too (even if using the Cel to scale it), instead it was stuck in high detail with variable screen size. (so you can opt for a postage stamp sized window to play more smoothly, but not a blockier full-screen display -especially significant for ray-casting engines since halving horizontal resolution will roughly double performance due to halving the numbers of columns to cast rays for -unlike polygon games where the 3D math overhead stays the same, but the rasterization overhead/bandwidth decreases)

I've no idea what framerate Doom would run at if it were 320x200 - ( I'll have to check what hor. res it uses ) but vertical scaling using the blitter isn't going to slow things down too much ( I'll test some code out for horizontal scaling ) and the important question would be 'would the framerate cause problems with reviews/sales at the time?'

Yes, and maybe cost effective enough to actually give Atari a realistic chance to establish itself as an early next-gen 3D-capable multimedia console and later on an attractive budget niche console capable of cut-down versions of new gen games (vs other budget consoles being limited to last-gen hardware and virtually no new games).
And the multimedia aspect shouldn't be underestimated either: there's a ton of FMV/multimedia games on PCs/3DO/MCD/etc that were hot at the time, and the Jaguar (even limited to 320x240 CRY and 1x CD-ROM) should have managed in impressive quality for the time. (similar to some 3DO games and generally better than 256 color PC games, perhaps better than 3DO if a customized codec was developed to take advantage of the GPU's performance -not sure if its DCT abilities are fast enough for MJPEG style stuff, but at least something closer to TrueMotion, better than Cinepak)

Atari had cinepak using GPU code - and it's FMV wasn't too bad.

That said, I still think they'd have been in a much better position had they released even a mediocre successor to the 7800 around 1989 (maybe 1991 if it was better than mediocre). The STe chipset, Panther, and maybe Slipstream designs (exactly as they are) were both pretty mediocre in practical performance and marketability, but either probably would have been better than nothing (which is what happened) and decent in the budget niche category. (and they wouldn't have to make the Jag backwards compatible with the older system either -so keep engineering and manufacturing cost/complexity down at the expense of no compatibility -which is of arguable marketing value for consoles anyway, and never a make or break issue -not so for computers, but that's another topic)

As you say, that's a different topic ( 4th gen I guess ), and I don't agree with you

[Crazyace]

I just played around with some blitter code - and it looks like using the blitter to double up from 100x320 to 200x320, or from 200x160 to 200x320 ( they both are almost the same time ) takes about 15% of a frame at 60Hz. This wouldn't have much effect on the framerate of a game like Doom on Jaguar - if the game runs at 20fps it's less than 5% of the frame time.

[kool kitty89]

I disagree, having low res modes would be a step back - 320 was a minimum ( well 256 to 320 ) for computers and consoles for almost a decade already at the time of the jaguar launch.

For 3D it could be very important though . . . on PC games it was very common to allow smaller screen sizes (or use large boarders by default -which was also fairly common on early console 3D stuff), so allowing similarly low resolutions without resorting to postage stamp screen sizes would be quite significant. (or allowing much more realistic framerates for existing higher res games)

You'd be crazy to try and play Doom on a 386 (even a DX40) at full detail, but you could get quite reasonable performance at 1/2 res and a step or 2 down from max screen size. (games like Tomb Radier on weak CPUs could only resort to smaller screen windows once you got to 320x200, I forget if Quake supported that -I know it didn't support variable perspective correction like TR or Descent, or non-FPU rendering modes for that matter, but I digress)

For detailed 2D games, using full res would be a given, bot for 3D/pseudo 3D it would be a more realistic trade-off. (especially for column renderers where cutting horizontal res is even more significant -cutting ray-casting computations on top of rasterization overhead)

Atari had cinepak using GPU code - and it's FMV wasn't too bad.

True, but that was (at least in some cases) using a 2x data rate (300~350 kB/s), and the GPU should definitely be capable of better than Cinepak in any case. (the 32x managed Duck Truemotion at highcolor 320x200 10 FPS -presumably without interframes, so just intraframe image compression)

As you say, that's a different topic ( 4th gen I guess ), and I don't agree with you

OK.

I just played around with some blitter code - and it looks like using the blitter to double up from 100x320 to 200x320, or from 200x160 to 200x320 ( they both are almost the same time ) takes about 15% of a frame at 60Hz. This wouldn't have much effect on the framerate of a game like Doom on Jaguar - if the game runs at 20fps it's less than 5% of the frame time.

I was thinking on this too: since you wouldn't be using line buffers, there's no VDC overhead saved by doubling scanlines (unless you skipped lines entirely -which is usually rather ugly), and copying lines of pixels is also pretty fast/efficient via the blitter too, so just supporting variable horizontal resolution would be more significant.

Allowing 160, 320, and 640 pixel widths would be nice, though 640 probably isn't that necessary. (especially if you're not going to support interlacing)
I'm also assuming they'd keep things simple with a fixed master clock with integer divisions thereof for the pixel clock.
So, assuming 26.6 MHz, you'd have 13.3 MHz for 640, 6.6 MHz for 320, and 3.3 MHz for 160. This dot clock is also somewhat convenient for being supported by the Saturn and MD/Genesis and, like those consoles, also provides a decent compromise between PAL and NTSC. (neither are perfectly square, but it's a decent middleground with NTSC pixels only being moderately too tall vs PAL moderately short, so games assuming square pixels will look fairly decent on both formats -many MD games demonstrate this)

You could also support programmable scanline resolutions (for overscan or narrower screen widths -the latter saving on VDC overhead and RAM space for framebuffers), but since those divisions of 26.6 MHz correspond nearly exactly to 160/320/640 pixels on TVs with average calibration, only the latter case would be useful. (if it was really trivial to add, it would be a decently useful feature -as would per-scanline resolution selection- but if it did add significantly to complexity, then it would make sense to omit -it really seems like something that would be simple enough to include though)

[Chilly Willy]

The rendering resolution for Doom on the Jaguar is 160x180 - that is, half resolution horizontally, and full resolution vertically. The object processor stretches the 160 wide display to 320 at display time. There's no reason to waste memory or bandwidth using the blitter to stretch the video since it can be done on the fly as the lines are built for display.

The 32X renders Doom at 128x144, and doubles it using the CPU to 256x144. Remember that the 32X version doesn't fill the screen. It probably could have also used 160x180 if the 32X had had a way to stretch the screen horizontally on the fly without using the CPU.

Actually, maybe there is... thinking about it, when I init the framebuffer, I preset the line table to point to the starts of the lines for both buffers. Well, I could assume the video mode was RLE and preset the line table, then preset all the lengths to two pixels. Then the game could just write a single byte pixel value, skipping over the length byte. That would use the RLE hardware to stretch the screen without the CPU having to double the pixels. Just double the width when calculating where the pixel should be drawn. I'll have to test that to see if it saves any time.

[Crazyace]

For 3D it could be very important though . . . on PC games it was very common to allow smaller screen sizes (or use large boarders by default -which was also fairly common on early console 3D stuff), so allowing similarly low resolutions without resorting to postage stamp screen sizes would be quite significant. (or allowing much more realistic framerates for existing higher res games)

PC's tended to have different issues due to VGA/EGA bandwidth from the CPU - software scaling has the advantage that HUD elements and overlays are still at full 320 res.

I was thinking on this too: since you wouldn't be using line buffers, there's no VDC overhead saved by doubling scanlines (unless you skipped lines entirely -which is usually rather ugly), and copying lines of pixels is also pretty fast/efficient via the blitter too, so just supporting variable horizontal resolution would be more significant.

Allowing 160, 320, and 640 pixel widths would be nice, though 640 probably isn't that necessary. (especially if you're not going to support interlacing)
I'm also assuming they'd keep things simple with a fixed master clock with integer divisions thereof for the pixel clock.
So, assuming 26.6 MHz, you'd have 13.3 MHz for 640, 6.6 MHz for 320, and 3.3 MHz for 160. This dot clock is also somewhat convenient for being supported by the Saturn and MD/Genesis and, like those consoles, also provides a decent compromise between PAL and NTSC. (neither are perfectly square, but it's a decent middleground with NTSC pixels only being moderately too tall vs PAL moderately short, so games assuming square pixels will look fairly decent on both formats -many MD games demonstrate this)

You could also support programmable scanline resolutions (for overscan or narrower screen widths -the latter saving on VDC overhead and RAM space for framebuffers), but since those divisions of 26.6 MHz correspond nearly exactly to 160/320/640 pixels on TVs with average calibration, only the latter case would be useful. (if it was really trivial to add, it would be a decently useful feature -as would per-scanline resolution selection- but if it did add significantly to complexity, then it would make sense to omit -it really seems like something that would be simple enough to include though)

Multiple resolutions would be nice, and I guess it's not worth quibbling about them as the initial idea was to strip out the expensive object processor parts to allow Audio etc to go into Tom ( and eliminate Jerry )

The rendering resolution for Doom on the Jaguar is 160x180 - that is, half resolution horizontally, and full resolution vertically. The object processor stretches the 160 wide display to 320 at display time. There's no reason to waste memory or bandwidth using the blitter to stretch the video since it can be done on the fly as the lines are built for display.

The 32X renders Doom at 128x144, and doubles it using the CPU to 256x144. Remember that the 32X version doesn't fill the screen. It probably could have also used 160x180 if the 32X had had a way to stretch the screen horizontally on the fly without using the CPU.

Actually, maybe there is... thinking about it, when I init the framebuffer, I preset the line table to point to the starts of the lines for both buffers. Well, I could assume the video mode was RLE and preset the line table, then preset all the lengths to two pixels. Then the game could just write a single byte pixel value, skipping over the length byte. That would use the RLE hardware to stretch the screen without the CPU having to double the pixels. Just double the width when calculating where the pixel should be drawn. I'll have to test that to see if it saves any time.

That's interesting - how does it compare in speed to just doubling up 8-16 and storing that way?

[kool kitty89]

PC's tended to have different issues due to VGA/EGA bandwidth from the CPU - software scaling has the advantage that HUD elements and overlays are still at full 320 res.

True, but there's also the issue of VGA not supporting lower resolutions at all. (otherwise you'd have an even bigger advantage there -lower res framebuffers would take much less overhead to copy into VRAM on top of less rendering overhead andmain RAM render buffer -similar issues for consoles using dedicated VRAM like SNES/MD/etc -MD in particular has a lot of examples of software rendered 3D, and again, quite often in rather small windows and using lower resin several cases too -in this case, with 4-bit packed pixels, it would actually be considerably faster to use double wide pixels and render with bytes-sized pseudo-pixels -either dithered pairs or just double wide 16 color pixels)

Multiple resolutions would be nice, and I guess it's not worth quibbling about them as the initial idea was to strip out the expensive object processor parts to allow Audio etc to go into Tom ( and eliminate Jerry )

Yes, definitely nothing like the OPL, or even a VGA bitmap controller (or even the 32x's primitive "Super VDP"), but still possibly with some minimal programmability. (more like the simple VDC in the ST or Slipstream -among others- except maybe without even variable color depth support -and note, while the 32x Super VDP doesn't support 1/2 res, it does a lot of other things including line tables, 8-bit paletted framebuffer, 16-bit direct color framebuffer, RLE encoded framebuffer, V/H scrolling, horizontal per-line scrolling, and genlock with the MD's analog video signal)

The rendering resolution for Doom on the Jaguar is 160x180 - that is, half resolution horizontally, and full resolution vertically. The object processor stretches the 160 wide display to 320 at display time. There's no reason to waste memory or bandwidth using the blitter to stretch the video since it can be done on the fly as the lines are built for display.

Yes, but the above discussion is in the context of a hypothetical streamlined Jaguar design with no object processor, no JERRY sound/IO/DSP ASIC (audio DACs and IO hardware moved over to TOM), no CRAM, no video line buffers, and a modestly enhanced blitter. (to better function without the object processor for 2D as well as improving 3D effects -the latter is partially related to the former though) A much simpler VDC with a phrase buffer/FIFO (perhaps 256 bits) would provide framebuffer/bitmap scanning/control support.

As such, you wouldn't have the flexible sprite/bitmap compositing and scaling of the object processor, but I was arguing that at least support minimalistic programmable resolutions to account for certain games that could benefit from allowing low-res rendering. (support for added colordepth/colorspace options would also be nice, but limiting it strictly to 16-bit CRY wouldn't be bad either -and that's what the blitter is most optimized for handling in any case, but for the most part that wouldn't be that attractive either -and 16-bit RGB isn't well supported by the blitter while 24-bit RGB would take up too much RAM and bandwidth to be really useful for most things; though, if there's any features of modest benefit that's trivial to add to the chip could probably be worthwhile -you'd have to ask someone involved with that sort of chip design to answer that "if" though))

And due to the way the blitter is designed (optimized for manipulating pixel data on 4 and 8-bit boundaries), 15/16-bit RGB is poorly suited, but 256 color paletted drawing would cater rather well (and a specialized palette could potentially allow 16 level shading as well -using 4 bits for color and 4 for shading), but 256 colors means CRAM and a good chunk of chip space dedicated to that (so a major trade-off). 24-bit rendering is supported by the blitter, but it's RAM/bandwidth intensive (and works at 32-bits per pixel) and can't gouraud shade properly (limited to Saturn-style additive shading -though with flexibility of per-channel additive lighting/shading effects too). A 32-bit RGBY mode would have been very nice for truecolor plus silky smooth shading (using 8-bits of intensity like CRY), but would still have all the RAM/bandwidth limits as well.

Finally, a 16-bit (4-4-4-4) RGBY mode could also be useful for allowing more flexible/advanced additive lighting/blending effects than CRY while still working on 4-bit boundaries and allowing 16 light levels as well. (so no silky smooth shading, but still reasonably decent -especially for flat shaded lighting- and no worse than the early model PS1s -as you mentioned, only supporting 16 shades)

The 32X renders Doom at 128x144, and doubles it using the CPU to 256x144. Remember that the 32X version doesn't fill the screen. It probably could have also used 160x180 if the 32X had had a way to stretch the screen horizontally on the fly without using the CPU.

Remember that 32x doom runs in 256 color mode, so it very well could simply write 2 pixels at once as a single 16-bit write (unlike Yeti 3D which is 16-bpp). In addition to that, 32x Doom uses simplistic dithering (paired pixels of different colors) in its rendering, unlike the PC version, and that also would make sense to handle as single pseudo 16-bit pixel rendering. (I assume that the dithering was used to better match the 18-bit palette of the PC version, and they could optimize for dithering like that since it only ran in low detail mode -vs the high detail PC version needing support for single width pixels rather than pairs)

Similarly, for the Jaguar, you have a 64-bit wide bus anyway, so you could handle up to 4 16-bit pixels per write . . . and for games using column renderers, you'd be stuck with drawing 1 pixel at a time anyway (no advantage of phrase-width writes or FPM fills either), so in that case, the only disadvantage would be using more RAM and VDC bandwidth for the framebuffer. (for reducing vertical resolution, it would be more significant though, as would it for line based renderers -like polygon rasterizers- where phrase and FPM writes would be much more significant -albeit, for texture mapping with the existing Jaguar blitter, you're stuck with single pixel reads/writes anyway with zero FPM or phrase bandwidth -unless you buffer into GPU SRAM, which has the problem of halting the GPU during blitter access to SRAM -less of a problem for 2D games using scaling and rotation effects, but much more a problem for 3D games)

[Chilly Willy]

Actually, maybe there is... thinking about it, when I init the framebuffer, I preset the line table to point to the starts of the lines for both buffers. Well, I could assume the video mode was RLE and preset the line table, then preset all the lengths to two pixels. Then the game could just write a single byte pixel value, skipping over the length byte. That would use the RLE hardware to stretch the screen without the CPU having to double the pixels. Just double the width when calculating where the pixel should be drawn. I'll have to test that to see if it saves any time.

That's interesting - how does it compare in speed to just doubling up 8-16 and storing that way?

Don't know... that's why I gotta test it. Kool Kitty makes a good point - remember that the bus is only 16-bit, so writing to RLE mode in the manner I describe is the same number of cycles as writing doubled pixels for 256 color mode. So just from that point, you don't save anything.