kskunk, on Fri Oct 14, 2011 8:45 PM, said:
Proper rasterization is complicated. There are tons of edge cases involved with creating seamless edges between adjoining polygons as they split and join, and grow thinner or shorter than one pixel. The 3DO mishandles seams and the Saturn famously picked the wrong algorithm. Leaving it to the GPU is a better idea than screwing it up!
Yeah . . . not just the rasterization algorithm to worry about either, but the whole quads vs triangles issue. (granted, what the Jag 2 did was still neither of those -not full rasterization either, but warped trapezoids you could manipulate to form triangles, right?)
The PSX had a lot of seaming too due to rounding errors in the GTE iirc. (actually more noticeable than seaming on the Saturn -Tomb Raider is a prime example- though the Saturn had other problems . . . )
Quote
I get the feeling they didn't think too deeply about 3D. They tried to put in some nice ingredients in hopes developers could use them to bake up a 3D pipeline, but they didn't really think it all through
.
Leaving flexibility in the system is more fool proof in some respects for sure . . . more so with the various pseudo-3D engines that were popular in the early/mid 90s on PCs (ie Doom and Comanche style height maps).
And that's a bit up to luck too, since Flare obviously wasn't aiming at supporting those sorts of engines (especially voxels -though corridor/maze style ray-casting renderers may have been considered).
The Z-buffering thing still bothers me though . . . with the amount of work that went into that, what else could they have pushed. Texture mapping was hard to judge, granted (especially since they already had fast scaling/zooming with the object processor -so affine rendering was only needed for warping and rotation effects), but there's other areas that seem like they would have been major concerns at the time too . . . like a dynamic instruction (possibly data) cache for the GPU, a command cache (or double buffered blitter registers) to help pipeline blitter operation, and/or keeping the overall design simpler (ie similar but no Z buffer -either saving some silicon or perhaps designing the chip with a larger scratchpad from the start) and focusing on trouble shooting more prominently. (albeit some things probably couldn't be helped without more time or more funding for aggressive testing . . . just putting more engineering time into it could only go so far -though I'd think omitting Z-buffering logic would at least help avoid bugs/problems to some extent)
Quote
Don't forget that the most optimized, highest bandwidth, most deeply buffered part of Tom is the 2D engine. The OPL can sustain 2 pixels per cycle, and it achieves that easily. It has huge dedicated SRAM buffers, several independent buses, and deep pipelines to make that possible. The OPL has dedicated, fixed-function, hardware to DMA and parse the object list, and "rasterize" sprites, including clipping and scaling edges.
The blitter is nowhere near that elaborate. It's just a little state machine. You can see where their priorities were. The GPU was quite deliberately intended to add all the "missing" stuff to the blitter. You can see it in how their buses connect, and they say as much in the docs.
This is another thing I've though about but never commented much on . . . the blitter was part of the 2D engine too, but far less optimized than the OPL (obviously the brunt of 2D was intended to be handled with OPL sprites -similar to Panther).
What I wonder is how things might have ended up if Flare kept more along the lines of an evolutionary development of the Slipstream (or Lynx) with a pure blitter+framebuffer graphics engine, pouring all that buffering/optimization into blitter operation and leaving the OPL concept back with the Panther. And more so, what implications would that have for 3D, since the blitter largely handled 3D, and enhancing the 2D blitter operations would generally impact 3D performance as well. (and if that ended up beefing up the affine texture mapping logic, aside from 3D textures, it would mean silky smooth rotation and warping effects for 2D games -on top of scaling/zooming effects)
Granted, you'd still need a VDC to scan the framebuffer, and you'd want enough buffering on that to make efficient use of the bus. (but such buffering should have been a small fraction of what the OPL used)
The 3DO kind of ended up like that (graphics focused on a blitter), but far, far more conservative and less cost effective than the Jaguar. (the PSX took that route too, except with 3D first and 2D second -still, the GPU was pretty efficient at handling 2D drawing, and even had the fast "sprite" mode that disabled rotation/warping -only drawing zoomed/stretched rectangles . . . obviously a much more aggressive design than the 3DO, though with a far higher manufacturing cost ceiling than the Jaguar -so efficient design with lesser cost constraints on top of that making stuff like separate CPU/audio/video buses, 2 MB SDRAM and 1 MB SGRAM, etc practical)
Quote
Quote
Or in the context of "last minute" hacks/tweaks for performance demands that were apparent by late 1992... and the Jag is already set-up to interface a 2nd DRAM bank
Yes, increasing the on-console RAM by 20% with a 5th DRAM chip, would allow DRAM->DRAM texture mapping in 5 cycles. You'd have 512KB of dedicated texture RAM in this design, which is probably enough. (You wouldn't want to use it for frame buffer because reading is too slow.) Of course, it would cost $10, and the Jaguar was over its cost budget already.
A single 128k chip would have been $3-4 (plus the added cost to the motherboard), and whatever that inflated to at SRP . . . and then weigh the benefits that it could have to marketability in spite of added cost. (or they could have made other trade-offs to keep costs down, like reduce RAM to 1.5 MB to facilitate using both banks -ie 8 128kx8-bit chips for the 64-bit bank and 1 256kx16 for the 2nd bank . . . or -cheaper- 2 512k chips and 4 128k chips for 1MB at 32-bits and 512k at 64-bits -using a full 2MB with more chips to allow more banks would probably be more costly than the single 2M+128k or probably even 2M+512k if you tried something like 2 banks of 8 128kx8-bit DRAMs for 2 1MB 64-bit banks -higher cost of the RAM chips and lots more traces on the board)
And regardless to RAM or CPU modifications, you'd still be stuck with ROM carts and the inherent disadvantages and limitations -including unattractive nature to 3rd party developers with Atari having a hard enough time getting support . . .
Which brings up back to Crazyace's main argument from the 1993 Jag thread (and a recent thread on Sega-16) . . . adding CD-ROM.
That obviously would have been more costly than a bit more RAM -or a different CPU- but the pay-offs could be massive -from far lower cost and risk of software manufacturing for 1st and 3rd parties, reduced overhead for pack-ins, demo discs -or demo discs as pack-ins reducing lost profits, multimedia prospects, potential for budget/lower-end developers, facilitating ports of computer games designed around floppy or CD mass storage, etc)
Without investment spending to suppress the point (selling at or below cost), the price would obviously increase even with the cost saved from manufacturing CDs rather than carts (that would pay off more in the long run, but the few games released in '93 probably wouldn't be enough to make up the difference in cost) . . . then again, all it needed was a positive reception in the test market to secure funding. (after that, Atari had more investment capital to work with)
Except Atari had a target price point to meet, apparently regardless of how it may compromise the overall marketability of the console. (CD-ROM isn't that impressive from a raw performance or programming standpoint -which Gorf's criticism mirrored, but the impact it could have on consumers, critics, publishers, and general software production -1st or 3rd party- were extremely far reaching)
I'd suggest a floppy drive instead (for cheap mass storage), but by 1993, a bare-bones cheap-o chinese CD-ROM drive and off the shelf controller chipset was probably cheaper than a HD 3.5" floppy drive. (unless Atari had a sizable back stock of drives/controller ICs left over from ST production)
Quote
By the way, CoJag can do DRAM->DRAM texture mapping in 5 cycles. This is the fastest way to texture map on the Jaguar, since there is no extra overhead in copying stuff in or out of SRAM.
The cojag also uses VRAM, right? (and a 25 MHz 'EC020 or R3000 . . . though even with the VRAM and enhanced CPU it was probably nominally cheaper to manufacture than the PSX, let alone Saturn
-not counting economies of scale or vertical integration)
Quote
You could also just use faster ROM in the cartridge. For another couple of dollars, your cart could use 200ns ROMs, allowing ROM->DRAM texture mapping in 8 cycles, which is as fast as all of the fastest approaches we've discussed above once you include the copy in/out overhead.
Yes, but then you need uncompressed textures in ROM on top of faster/expensive ROM, further negating any practical use. (one of the major advantages of having all that RAM was heavily compressed games on cart . . . not as cheap as CDs, but still a lot better than having all that data uncompressed in ROM -which is pretty much what you had do do for 32x games with its limited RAM)
Quote
Not to toot my own horn, but the Skunkboard can do texture mapping from ROM->DRAM in 8 cycles as well. This is enabled by default. Try it out with your own code!
Yeah, in the context of modern homebrew, ROM (or flash) costs or speeds are non-issues . . . so you could push 75 ns ROMs with uncompressed textures. (assuming the Jaguar's ROM speed is programmable and not locked at 375 ns -I haven't gotten a straight answer on this, but it seems like it should be programmeable)
That's exactually whant 32x homebrew is doing . . . well, within the speed/capacity constraints of current flash carts. (and capacity is still an issue since the max normal configuration is 4 MB flat mapped or the 5 MB SSFII mapper configuration -that mapper was designed to support up to 32 MB, but current flash carts only support it configured as 5 MB -the Neo Myth also has a custom mode that maps 8 MB iirc)
I wonder if Atariowl's demos are expoiting this. (I know Chilly Willy's Yeti3D demo is on the 32x: 256 color uncompressed textures are sroted in ROM -though shaded/lit in 15-bit RGB . . . or it may be technically 12-bit RGB due to the soft-SIMD routine used)
Quote
It's also technically possible to put a small PSRAM in the cartridge itself, allowing 5 cycle PSRAM->DRAM texturing. Talk about an echo of the old 2600 days! (Sadly, there is no way to put a DRAM in, but 128KB PSRAMs were under $3 in the Jaguar's prime days.) 128KB is sufficient for scenes in AvP or Doom without too much costly texture swapping behind the scenes.
Putting a 128k DRAM inside the Jag would have been a much better investment. (avoiding game price inflation and/or profit loss onsoftware -not to mention greater risk/investment for manufacturing)
That, or if they really planned to add it a couple years after launch, maybe add a simple socket for a DRAM card/stick (in that case perhaps for 512k) and offer that at an affordable price (and pack-in with some games).
Though RAM expansion would be even more important for a CD based system . . . that's a thought too. (cutting some of the overhead of a built-in CD drive but reducing RAM capacity, but including a cost-effective/easy to use RAM expansion port -a hell of a lot more realistic to market a simple RAM module than a CD add-on
. . . not to mention cheaper/easier to build-in as standard on later models -especially from 1996 onward when RAM price stagnation ended) Plus, the expansion module could widen the width of the 2nd bank. (ie 512k at 16-bits could get a module with another 512k at 16-bits boosting that bank to 1 MB at 32-bits, or 1 MB at 16-bits could become 2 MB at 32-bits . . . or 512k at 16-bits could become 2 MB at 64-bits -except that would require 48 data lines on the RAM port rather than 16 and a 1.5 MB RAM card -so the 16=>32-bit examples make more sense)
. . . .
But for all of this tech talk on how the Jag could have been different or better . . . or even some of the less technical issues (like the inherent marketability and cost efficiency of CD-ROM), it all still would have been a bit moot due to Atari's position at the time.
They were pretty much screwed in the US, and their situation didn't foster particularly good management either (under those circumstances, they did pretty damn good though).
At best they might have been able to establish the Jaguar as a viable long-term platform in Europe (especially the UK) . . . and had they managed that, they might have gotten enough support to allow it a notable niche in the US, but all that would have been under ideal circumstances of good management making the best of hard times. (and timers were even harder than when Atari Corp was established in 1984 . . . except they had less debt -but also far less potential for the future)
As such, if one was to make hypothetical suppositions about missed potential or missed opportunities (or just hsitorical observations of the company and market), the time to really look at is 1989-1991. That was pretty much their last chance to make it big in the mass market . . . both the potential for Atari Corp games/entertainment and computers died in that period (and some would directly tied that to Sam Tramiel's management -though other factors played in as well, like the DRAM crisis of '88 andthe A500 matching the 520STFM that year . . . not to mention Michael Katz leaving in early 1989 -he was largely responsible for Atari being able to hang in there as a distant 2nd against Nintendo with around 2x the market share -sometimes more- over Sega in '86-89 . . . so much so that Sega offered exclusive licensing rights for the Mega Drive to Atari Corp in 1988 -which Katz favored, but Tramiel and Dave Rosen couldn't agree on the terms of, especially due to a conflict of interests in Europe since the contract was for North America only and Atari would thus be competing in Europe to some degree -I assume Jack Tramiel understood the ST's position in Europe enough to know that it was very significant in the games market, and obviously the 7800 was being brought over to Europe around that time as well)
So, yeah, lacking any follow up to the 7800 (a "16-bit" generation console) left Atari to largely fade from the US game market, especially with the poor performance (and arguably poor marketing/management) of the Lynx (really ironic that Katz left just a few months before Atari launched a machine brought by Epyx -ehere Katz had formerly been the president prior to joining Atari Corp in '85), and then the botched management of the computer line (general lack of a timely/efficient/competitive evolution of the hardware, issues with marketing and market positioning -in different respects in Europe and the US, etc, etc . . . and Atari had in-house alternatives being considered at the time)
Unlike 1985, 1989 had Atari Corp just past their 1988 peak, albeit had been shed a couple years prior, positive assets had been established, market share was significant in consoles and computers (the latter mainly in Europe), they had gone from a moderately sized start-up tech company that had taken on a large chunk of Atari Inc's old consumer division properties (and debt) to a successful, profitable multidivision entertainment/technology company in the fortune 500. They were in a position where significant investment spending was a realistic option to push into the mass market for games again, especially with at least decent hardware and good marketing and good software support -including fostering good relationships with licensed 3rd partypublishers. (like what Katz was capable of pulling off -which he did his best at with Atari's limited marketing budget for the 7800/2600/XEGS, but was allowed to really show that at Sega in 1990
)
Not to mention the potential to maintain/improve the ST line. (except both issues should have been worked on well before 1989 . . . a serious competitive successor/evolution of the ST should have been in the works from day 1 and a console definitely should have been in the works early enough to push for a 1989/1990 release -technically they could evenhave aimed at a convergent evolution of the ST and game system plans to make more efficent use of engineering resorces -not necessaily diretly repurposing ST hardware as a console, but perhaps designing some new custom hardware that could be used on a console as well as fit well to enhance the ST -even more so since gaming performance would be a substantial boon for the ST's marketability as well) Heh, if they'd managed to hang on at least astride of CBM's position in Europe, Atari potentially could have pulled ahead again as CBM collapsed under its own weight in '94. (granted, PCs would still be pushing in too . . . but that could have been far more gradual if the ST and Amiga hadn't failed ~1992-1994 -In much of Europe, PCs didn't get big for the masses until after Atari and CBM's platforms had died off on their own -makes you wonder if they could have retained a niche to this day in that region, sort of like Apple has but a bit of a different context)
Oh, and, of course, had Atari had a (reasonably) successful "16-bit" game console (not to mention better maintained success in computers), the Jaguar wouldn't have existed as it did in 1993. (they wouldn't have needed to rush a new system out so soon, so a longer, more mature design cycle could have been possible -maybe ending up with something between the Jaguar and jag II -not to mention the better software support facilitated by the existing market position)
Atari also never had a chance in Japan . . . even Atari Inc with the VCS for that matter, that is unless they licensed/partnered with a powerful domestic Japanese company for distribution. In the context of Atari Inc, that might have been Namco -at least had they maintained a good relationship after the Atari Japan buy-out . . . but in the context of Atari's desperate position with the Jaguar in 1993, there's some interesting thoughts that come to mind:
You had Bandi considering entry into the console market, and NEC being a bit confused with their next-gen entry (apparently getting spooked by Sony and rushing out somewhat dated hardware that had been shelved a couple years prior). With NEC's position and Atari having nothing to lose, there might have been some chance in negotiations there. (or perhaps even a trade . . . Atari had a better chipset than NEC at the time and NEC had powerful manufacturing resources, so perhaps something like free licensing of the Jaguar chipset in return for attractive deals on RAM or possible even a CD drive and/or an NEC CPU -especially since the Jag could accept varying RAM and CPU configurations fairly easily -Atari's success outside Japan would also be in NEC's best interests since it would mean more incentive for 3rd party software support for all regions -even more so if Atari sweetened the pot with royalties of sales in the US/Europe)
Edited by kool kitty89, Sat Oct 15, 2011 2:36 AM.
4
Every time I'm pretty sure I know how the Jaguar works I'm surprised by the results when I try it. Maybe there's something I'm missing in my accounting for cycles.
