Quantcast

Page 25 of 25 FirstFirst ... 152122232425
Results 361 to 370 of 370

Thread: Thoughts on Sega's "clean" hardware design aspects . . . and the Saturn.

  1. #361
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    30
    Posts
    9,724
    Rep Power
    63

    Default

    Quote Originally Posted by stu View Post
    IIRC The NV2/SaturnV08 deal between Sega and Nvidia died for some fundamentally terminal reasons.

    Firstly, Sega did not want another system that used quads as the graphical primitive and were trying to push Nvidia to include support for triangles, which Nvidia stubbornly refused to do (Curtis Priem, who was Nvidia's CTO/Chief Architect at the time, had a huge hardon for Quad/QTM based systems and it was he that was pushing the development of both NV1 and NV2.) Sega brought Yu Suzuki and AM2 to evaluate the design and towards the end had managed to convince Nvidia to include some triangle support but by that time Sega's bosses had pretty much had it with their dealings with Nvidia and they told the development staff to forget it.

    What killed the deal stone dead was that when Nvidia got the manufacturing prototypes of the chip back they did not work. It sounds like the design was pretty fundamentally broken as Nvidia tried to fix the issues without success. I personally think Sega dropped Nvidia for the best reasons, design issues with the chip would have caused delays and would have cost more money to fix.

    I agree though if the chip had worked it would have been a pretty interesting design.

    FiringSquad.com had a pretty good write up of the whole NV2 fiasco, unfortunately the site is no more, however I was able to use the Wayback Machine to pull up the article.

    https://web.archive.org/web/20110326...v2/default.asp
    Interesting, and I sort of recall stumbling on some of that before (it certainly fits my perception of the progressively more strained relations between Sega and Nvidia). It's still no less ironic that Nvidia's NV3 of the 1997 vintage Riva 128 was a complete departure from their NV2 work and totally bent on industry standard polygonal 3D and, especially, full DirectX 5.0 support with speed rivaling or exceeding the Voodoo 1. (on paper closer to the Banshee, but not usually managing that in reality) It's almost like they did that to give a further F-you to Sega after relations broke down: here's this big shiny new GPU with all the bells and whistles you were asking for, but you can't have it.

    OTOH, the Rage Pro arrived around the same time, had vaguely similar performance and added 32-bit color support and MPEG-2 acceleration. It did lack support for texture filtering on alpha textures (per-texel alpha maps, not per-polygon translucency effects) which looked really bad for things like N64 ports using super low-res textures (Turok's clouds and waterfall textures looked awful) but looked reasonably nice if higher res textures were used. It also had the benefit of being at least partially DirectX 6 compatible. (it could run the Unreal Engine without totally broken lighting effects while the Riva had no lighting at all ... a proprietary Rage-coded port of Unreal obviously would've looked better ... say had it been used in a console) The rehashed Rage XL derivative added sort of minimalistic filtering on alpha textures. (I'd thought it was just a die-shrunk Rage Pro, but trying one for myself showed filtered alpha textures where there were none on a Rage Pro) Oh, and note this goes for 1-bit alpha as well ... 5-5-5-1 RGBA that used per-textel transparency (one bit for opaque/transparent) which was a problem for games making heavy use of sprite-ish 3D objects for trees and such, as they'd all be unfiltered in spite of not being translucent. (the trees in Tomb Raider have this problem ... they also have the weird rendering errors that show a translucent rectangular texture border where transparency should be on the S3 ViRGE based cards unless you use 24/32-bit color ... )
    The Rage Pro/XL also worked on a 64-bit bus rather than 128 bit on the Riva and was generally lower cost.

    Any of those GPUs was dated by 1999, though and would've been a poor choice for the Dreamcast. (Rage 128, S3 Savage, Nvidia TNT, Matrox G400, Voodoo 2 or 3 would've all been more appropriate ... and the PowerVR of course)
    I'd need to dig up old reviews to double check, but I'm pretty sure the S3 Savage had almost no performance loss going from 16-bit to 32-bit color rendering, and while not blazing in speed compared to higher-end contemporaries, did very well at the sort of resolutions a game console could use (ie 640x480) while also allowing 16-bit Z-buffers to still be used, partially contributing to speed but also conserving video RAM. Plus it had S3 texture compression. (plus, given S3's real struggle to break into the 3D market, they'd probably have been very willing to negotiate with Sega for favorable terms, and securing a second-source for more reliable GPU manufacturing/supply) The later Savage 2000 ended up a disaster with a rushed release and broken hardware T&L that made its attempt as a budget-minded competitor to the Geforce really problematic.



    Oh, but on the topic of the Saturn itself, some other things came to mind that would've been super relevant as 'last minute' changes to the design in 1994, and especially with the 32x released as it was historically:




    Stick with dual SH2s, but put the second SH-2 on the VDP-1 bus for software renderer effects and easier upgraded ports of 32x games. (also some decent LUT based lighting/blending in 256 color or 2048 color paletted modes) Maybe expand texture RAM to 1MB while dropping main RAM to 1 MB. (ditch the 1MB of DRAM, 512kB less total RAM, but faster and more useful/flexible RAM in general ... cheaper with just the existing 512kB texture bank)

    VDP1 could access them as 2 banks of 512kB 16-bit RAM while the SH2 could access them as such (possibly interleaved with VDP-1 access) or as a single 32-bit block. (though software rendering would tend to favor the 16-bit configuration and reduce contention with VDP-1) It'd probably be simpler and cheaper just to use them as 16-bit banks alone. (a single 512kB bank would be tougher to work with, but still pretty useful and the SDRAM framebuffers would be faster to render to than the 32x ... plus you have the main CPU on a separate bus, so you'd easily have software rendering as fast/smooth as the best cutscene style tech demos on the 32x)

    You could now mix hardware-rendered quads with software rendered triangle fans that way as well, using a simple painter's algorithim for Z-sorting. (with per-polygon ray-casting to reduce overdraw)

    You could also do soft-SIMD based blending and LUT based lighting with 15-bit RGB, like Yeti-3D does, but 2048 color paletted mode could also be used as 256 colors of 8 shades with logical 3-bit shading and LUT based color blending ... or LUTs for both, with 256x256x8-bit (plus a 3-bit logical add+shift for the 8 shades) for blending and perhaps 256x64x16-bit for lighting: like Quake, but nicer than 256 color 18-bit palette lighting (2048 color 24-bit)
    Or you could use 128x16 colors/shade organization for 128x128x8-bit and 4-bit shift/addition based blending and 128x64x16-bit lighting: 32kB total LUT size) You could also use a LUT for blending the shade element, but shifts+adds would probably be faster and be one less thing to contend for on VDP-1's bus.

    These 'modes' are similar to some of the hardware rendering options I mentioned above, but wouldn't require foresight to implement in the design process a year or two earlier ... just do them all in software with the existing Saturn hardware.

    You'd also be able to use VDP-1 to accelerate software rasterization. (certainly for line fills, but possibly for gouraud shading while line drawing and possibly texture mapping on a line-by-line basis as an ad-hock blitter rather than a quad-warping engine)

    You could also do things like read from the framebuffer (back buffer), render into texture RAM then render back into the framebuffer for some effects.



    This would also make PC ports much easier as software renderers could be directly adapted without having to work with the Saturn's rendering hardware (or selectively use it) and would be significantly faster than using the master+slave SH-2 arrangement for software rendering in main RAM and DMA copying to VDP-1 RAM. (this especially goes for non-polygonal renderers and ones using palettized color tricks, all of which the Saturn would do better than the PSX; Doom and Build based games along with enhanced Wolf3D a la Rise of the Triad would all work great, and voxel-style height maps would also work well)
    For Doom/Build engine games, you could software render columns and use VDP1 to accelerate spans. (line by line texture filling of floors/other horizontal surface planes)

    This could be better for 2D games as well, since 2048 color mode could be used for software translucency effects while providing sufficient priority bits/flags to handle nice granularity with the VDP2 BG planes.

    Quake could be software rendered and optimize to draw perspective-correct span segments into the SH-2 scratchpad in leu of abbusing FPU registers as in the Pentium-optimized PC original. (incidentally something that a Cyrix-specific Quake patch also should have done with its 256 byte L0 scratchpad ... but that never happened)


    This would also make the logistics of supporting the 32x and Saturn in parallel AND branching out to Sega PC publishing much more sound and viable. Games developed for the 32x first or PC first would be much easier to adapt to and upgrade/tweak for the Saturn: for 32x games, you'd have the software renderer running full-bore on the VDP-1 bus and selectively throw in some VDP-1 effects while easily replacing the Mega Drive background layer stuff with really nice VDP2 BGs.

    You wouldn't have a cheaper system than the PSX, but you'd have something a great deal more flexible and easier to adapt PC games from that era, from 2D, to pseudo 3D, to various flavors of 3D (including software renderers that worked with quads or quads and triangles along with polygon fans/chains/strips). The Playstation would only become universally easier to port to later in the generation when API-based 3D rendering became dominant on PC and software rendering took a back seat. (with rare exceptions like Unreal's MMX-optimized software renderer and Outcast's polygon+voxel based software renderer ... which might have been SSE/3DNOW! optimized, or just MMX optimized, I'm not sure ... I suspect MMX given the popularity of the Mendocino Celeron and Pentium II, and the K6-2's MMX was as fast for integer ops as 3DNow! was for floating point, so for something already integer-MMX optimized it probably wasn't very appealing to bother with floating point)

    Quake, Duke Nukem 3D, and Amok probably would've been on the Saturn Sooner, and looked nicer.

    Any game that worked around quads by pre-warming textures and folding them into triangles would have also looked better as a software renderer even with just 512kB texture/work RAM for the graphics-SH2. (you'd have properly formatted textures that didn't waste half the RAM as triangles pre-warped and unfolded into rectangles) You'd also have more flexible and nicer looking lighting and blending using look-up tables (LUTs) in software. (plus you could do LUT based effects in 256 color mode where VDP1 can't light or shade or blend translucency: it'd be 256 color Doom/Quake-like blending, but a lot better than nothing or just dithering)
    **Note: this goes for 2D as well as 3D: software-rendered 2D could do things that VDP1 lacks the ability to do, including using LUTs for 50/50 translucency, and the same goes for 2048 color paletted mode. (a 2048x2048x16-bit table wouldn't be practical ... it'd take 8 MB, but the above mentioned 256 color by 8 shade or 128 color by 16 shade organizations would've allowed for usable LUT based shading)

    Now, maxing out the system's performance on really optimized Saturn-specific/native games would've been pretty close to the same as the historical Saturn, but getting GOOD performance out of it for more general purpose use for ports or more average talent or real-world deadlines (or real-world documentation constraints) would have been much more common. It would've been just as 'complex' overall, but much easier to program for most developers. (and the hard parts of software rendering would've already been learned on the PC side of things ... or cutting their teeth on the 32x for that matter)




    Regardless of how good or bad an idea the 32x itself was, this arrangement would've made it better (or less bad) all around, and SoA's 32x dev kit would've gone even further towards building the initial Saturn Dev kits/tools than happened in reality.



    Edit:
    Oh, and the sort of flexibility offered there, as well as the specific mix of 2D/3D hardware and CPU grunt (and the SH architecture itself) might have attracted some of the Atari Jaguar developers to the Saturn and allowed them an easier path to adapt rather odd/quirky engines heavily optimized for the Jaguar RISC processors, Blitter, and object processor (sprite engine). The 2048 color mode even offers a sort of makeshift way to adapt games designed around the Jaguar's CRY colorspace. A few very talented teams were left hanging in 1996, some big, some very small start-ups, but many would've found the Saturn a good fit. (moreso than the existing Saturn, where the closest path would've been software rendering on the main bus, then DMAing to VDP1's framebuffer) Jag developers were also naturally accustomed to horrible bus contention issues, so working around the trade-offs of an SH2 sharing a bus with VDP1 would be rather tame by comparison.
    Last edited by kool kitty89; 02-12-2018 at 02:33 AM.
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude its the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the worlds first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  2. #362
    Outrunner
    Join Date
    Oct 2012
    Posts
    617
    Rep Power
    46

    Default

    Quote Originally Posted by kool kitty89 View Post
    Interesting, and I sort of recall stumbling on some of that before (it certainly fits my perception of the progressively more strained relations between Sega and Nvidia). It's still no less ironic that Nvidia's NV3 of the 1997 vintage Riva 128 was a complete departure from their NV2 work and totally bent on industry standard polygonal 3D and, especially, full DirectX 5.0 support with speed rivaling or exceeding the Voodoo 1. (on paper closer to the Banshee, but not usually managing that in reality) It's almost like they did that to give a further F-you to Sega after relations broke down: here's this big shiny new GPU with all the bells and whistles you were asking for, but you can't have it.

    OTOH, the Rage Pro arrived around the same time, had vaguely similar performance and added 32-bit color support and MPEG-2 acceleration. It did lack support for texture filtering on alpha textures (per-texel alpha maps, not per-polygon translucency effects) which looked really bad for things like N64 ports using super low-res textures (Turok's clouds and waterfall textures looked awful) but looked reasonably nice if higher res textures were used. It also had the benefit of being at least partially DirectX 6 compatible. (it could run the Unreal Engine without totally broken lighting effects while the Riva had no lighting at all ... a proprietary Rage-coded port of Unreal obviously would've looked better ... say had it been used in a console) The rehashed Rage XL derivative added sort of minimalistic filtering on alpha textures. (I'd thought it was just a die-shrunk Rage Pro, but trying one for myself showed filtered alpha textures where there were none on a Rage Pro) Oh, and note this goes for 1-bit alpha as well ... 5-5-5-1 RGBA that used per-textel transparency (one bit for opaque/transparent) which was a problem for games making heavy use of sprite-ish 3D objects for trees and such, as they'd all be unfiltered in spite of not being translucent. (the trees in Tomb Raider have this problem ... they also have the weird rendering errors that show a translucent rectangular texture border where transparency should be on the S3 ViRGE based cards unless you use 24/32-bit color ... )
    The Rage Pro/XL also worked on a 64-bit bus rather than 128 bit on the Riva and was generally lower cost.

    Any of those GPUs was dated by 1999, though and would've been a poor choice for the Dreamcast. (Rage 128, S3 Savage, Nvidia TNT, Matrox G400, Voodoo 2 or 3 would've all been more appropriate ... and the PowerVR of course)
    I'd need to dig up old reviews to double check, but I'm pretty sure the S3 Savage had almost no performance loss going from 16-bit to 32-bit color rendering, and while not blazing in speed compared to higher-end contemporaries, did very well at the sort of resolutions a game console could use (ie 640x480) while also allowing 16-bit Z-buffers to still be used, partially contributing to speed but also conserving video RAM. Plus it had S3 texture compression. (plus, given S3's real struggle to break into the 3D market, they'd probably have been very willing to negotiate with Sega for favorable terms, and securing a second-source for more reliable GPU manufacturing/supply) The later Savage 2000 ended up a disaster with a rushed release and broken hardware T&L that made its attempt as a budget-minded competitor to the Geforce really problematic.

    I agree that there were probably other graphics solutions available as an alternative to the NV2, however from what I have read Sega were not so interested in Nvidia's chips for its graphics feature set and were more interested in the fact that it could fulfill the role of both graphics chip, sound chip and I/O , thus reducing the amount of chips on the system board. Apparently the deal between Sega and Nvidia was signed before the NV1 launched and Sega even saw Nvidia's graphics technology.

    Other observations that I would make regarding the Saturn V08 system were that it seems that the whole deal was signed by a Sega that was almost in a reactionary "panic" mode. They were hearing a lot of complaints regarding the Saturn's design by developers versus the PS1 and they probably felt that the situation for the Saturn could potentially get worse once the N64 came out. Looking at some of the games that were rumored to have started development for the system, like Sonic Xtreme it makes me wonder whether Sega actually considered either dumping the Saturn early and going with this Nvidia system instead, or possibly releasing some sort of upgrade for the Saturn with this new chip set in it. (if that was even possible)


    Quote from an interview with Don Goddard (from a Vogons thread)

    Quote " 9. Is it true that AM2 within SEGA really did push for triangles in the end as the Firingsquad article mentions?
    Yes. We were told directly that SOJ just wanted a triangle based rendering engine and nothing else. The literally said 'We want Virtua Fighter 3 to run on this platform and be available by Christmas (1995)'. Being a VF fan I asked when VF3 would be available in America. They said it wasn't even out in Japan, but should be by the end of the year. If you look at the Wiki you'll see they didn't even have a demo till a year later (March 1996)!

    STI was directly told by SOJ they just wanted triangles and not to have any quads (massive Saturn fail) or QTM's. Even SOA didn't want anything but triangles as figuring out QTM's seemed like stepping into another 'quad rendering' disaster. STI was allowed to explore this directly with nVidia after six months or more because SOA was tired of dealing with nVidia. SOA and SOJ just wanted a good triangle rendering engine and 3DFX was clearly better at doing that in early 1995 so there was massive pressure on nVidia to just put something out and fast.

    What's interesting is the Sega Saturn wasn't even released in America yet and Sega knew it was going to fail against the Sony Playstation who never made a game console before but their demos were amazing so Sega was seriously trying to get a new platform done before the end of the year! Sega had already pre-eminently killed the 32x by announcing it as the lesser bastard child of the Saturn and, if this NV1 info had gotten out, the Saturn would have been a lesser child of the NV1. Sega was going through very difficult times as Nintendo was out of the game in 1995 (N64 came out in 1996), Sega's great Tom Kalinske was leaving and later to be replace by Bernie Stolar, and everyone's expectations for a 3D Sonic game were so high it was ridiculous. Those are all stories for another time though.

  3. #363
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    30
    Posts
    9,724
    Rep Power
    63

    Default

    Quads were really not the Saturn's main problem, or VDP-1's main weakness, and quad-based arcade hardware (including the Model 3) was much more powerful for the same reasons. The problem was primarily use of forward texture mapping and the massive pitfalls it has in both fillrate due to overdraw and shading/blending errors due to overdraw when shrinking/warping any primitive. Folding quads into triangles just makes these problems 2x as apparent. (3DO, NV-1, and NV-2 have the same issues) Had there been a triangle mode using the same forward mapping (linear reads from texture, scanning every single textel and drawing at least one pixel to the screen for every single textel) would have still been a major bottleneck to any system.

    https://forum.beyond3d.com/threads/t...-3#post-371228
    This touches briefly on Foreward Texture Mapping problems. (and he gets the terms right: PSX/normal 3D, even the Jaguar and most software renderers are rasterizers ... I think the Sega CD's ASIC even works that way, though it only does 2D scaling/rotation of rectangular cells)

    DeanoC
    It wasn't really quads that was the issue but the use of forward texture mapping rather than the much more useful backwards texture mapping.

    To those who prehaps haven't heard of the issue (all hardware today uses backwards) I'll try and explain.

    Backwards texture mapping.
    You iterate across the triangle or quad in screen space, calculate a UV coordinate and lookup that into the texture. You hit a texel only if it appears on screen and you only hit each screen pixel once.

    Forward texture mapping.
    You iterate across the texture, for each texel calculate the screen position it hits and put the texel on the screen. The problem is when you minify the texture onto the screen, you hit a screen position several times. That breaks transparency and wastes fillrate. One advantage is that because you are iterating into screen space, you can produce non-linear screen segments (i.e. curves) but in practise is very hard to use as there are only a restricted set of curves surfaces you can produce.

    Forward texture mapping comes from thinking about scaling and distorting sprites. 3DO and SEGA Saturn used it, just about everybody does backward texture mapping.

    Had the Saturn worked like the Jaguar or Sega CD, but added full 4-point distortion to the rectangles rather than just rotation (which requires line by line set-up for rasterization: done using the RISC GPU in the Jag), you'd have had much more efficient use of bandwidth and fillrate would be competitive with solid color polygon drawing ... or a bit slower due to page-breaks in the texture RAM (assuming no SRAM cache or buffer, just SDRAM) but you save a ton of reads and writes when down-scaling objects, folding them, warping, and avoid over-draw of all sorts (and don't break blending or G-shading). You can no draw quads or triangles in single operations, though you'd have the limitation of rectangular textures being applied to each primitive rather than to strips/fans. (so RAM use for textures is no better than VDP-1, but bandwidth is much more efficient)

    This also would've saved a ton of CPU hits on the 3DO as you'd need far fewer main RAM reads for textel fetches. (and interleave more with CPU access) Same for a hypothetical SH-2 (or other co-pro) on the VDP-1 texture RAM bus.

    Also, quads are all over most 3D models, much moreso than triangles, and a system that can draw EITHER quads or triangles in a single operation would be liked by most devs. (geometry math still uses triangles, and quads are 2-trip strips, but cutting the number of blitter/GPU/VDP commands required to draw a given scene is pretty useful)

    On the other other hand, given the way the Jaguar and MCD scaling/rotation texture mapping units work, and the way MOST primitive affine rasterizer engines normally work, it'd be simplest to include not 4 or even 3-point primitive drawing, but simply add a trapezoid drawing function. This is then used to draw segments of arbitrary polygons, but each segment has to have horizontal top and bottom lines, so an arbitrary triangle rquires 2 segments (to allow for 3 arbitrary points) and a quad would take 3 ops, etc. The S3 ViRGE architecture draws polygons this way internally, but it has higher level hardware and software masking that for 3D operations (the 2D polygon draw operations work directly on traps, though). This is also how the Jaguar II's blitter works (and like the ViRGE, it also supports bilinear interpolation) though it has a nice RISC GPU to handle the trap-chaining for building primitives or complex fans/strips. (a CPU routine to build appropriate lists on the Saturn would've have been a big deal, but sticking an SH-2 or even an SH-1 at half-speed to assist the VDP with that directly would help ... sort of like the Jag's GPU or N64's RSP ... not the vector portion, but the R3000-derived MPU portion handling RDP list processing)


    Sega may have gone with VDP-1 working the way it did due to extending the System 32's sprite zooming function, but it also may have been due to having a look at the 3DO hardware back around 1990 (Mike Katz had gotten approached by them and passed the offer on to SoJ, but they turned it down ... but who knows how much info was shared; going by his comments, it sounds less serious than the SGI chipset review in 1993) so that may have been a factor. OTOH, Sega didn't implement RLE compressed textures like the Lynx and 3DO did, which is one of the main advantages of forward texture mapping. (linear texture reams makes RLE convenient)


    That said, my suggestion of supplementing VDP-1 with an SH-2 for software rendering, software polygon set-up, etc would still seriously help this, particularly BECAUSE Sega didn't use RLE format textures, actually. One workaround for seriously helping with fillrate bottlenecks with VDP-1 would be realtime generation of mipmaps and avoiding down-scaling of textures like the plague. Do fast integer-scaled textures from a block of local RAM and spit those out to the VDP-1's texture SDRAM ('VRAM') to make sure nearly everything is being drawn zoomed or at least 1:1.

    Of course, you could also just use tons of low-res textures for everything, but that's look bad ... like unfiltered N64 game bad.

    That sort of scaling task would probably be OK for a 14.3 MHz (or 13.3 lower res mode) SH-1 with 512k DRAM to work in and store source textures in (hell, you could store those as RLE compressed at varying color depth, using formats optimized for fast scaling/filling ... so like 4/8bpp but also 5/6/7 bpp special formats like 5+3 bits, 6+2, 7+1, with the latter using the last bit to simply signify single pixel vs run, adding another byte for a run as needed) but an SH-2 would be nicer and potent enough to do software or hybrid rasterization for triangles. (software rasterization would want to use already unpacked 8/16-bit textures, no RLE stuff, and use software affine rendering or something approximiating that, etc, but hybrid stuff could be done to allow the VDP to forward-texture-map triangles directly without folding textures by breaking up drawing operations and turning sprite-scaling/rotation function into triangle set-up ... but it's still forward texture mapped, so shrinking/warping any textels smaller than their native size causes overdraw: full software rasterization avoids this, but would be slower for drawn large/zoomed in polys)

    Looking at more of the Saturn board diagrams as well as SH-2 datasheets, I think VDP-1 has sufficient bus control/DMA interface connectivity on it to allow some sort of piggybacked CPU on its bus (using similar connectivity to the SCU DMA) but you'd obviously need to account for such when doing system DMA as well, had they added such a thing. But better than that, the SH-2 has built-in SDRAM interface logic, so it could have a private local SDRAM chunk and flip on/off the VDP-1 bus as needed. (you could potentialyl use 2 256kB chips as 32-bits ... but that's more cost, board space, trace count, etc, so sticking to a 16-bit 512kB chip would make more sense, while omitting the 1 MB of slower low-RAM to cut costs and balance things somewhat ... though honestly, for cost savings: cutting the sound subsystem as well in favor of simple 16-bit DMA sound that could be software managed by either the main CPU, CD buffer controller SH-1, or even the SCU DSP ... hell, bulking up SH-1 RAM to 1 MB for a more flexible general-purpose sound+data buffer would be great, and the SH-1 was designed with DSP-like features for sound and signal processing, so it'd work out great as a general-purpose sound processor ... better for simply mixing PCM/ADPCM with a few effects than the Saturn's more elaborate Yamaha unit could, too)

    Oh, actually, if you really focused on the SH-1 handling audio, I don't think you'd even need a DMA sound circuit, just use one of its internal DMA channels (it has 4) to read from a buffer in its 4kB scratchpad and use one of its serial outputs to feed a serial DAC. (it has a ton of UART functionality, more than the Saturn itself should need ... unlike the SH-2s which have more slimmed down and general purpose I/O functions)




    Hmm, and I stumbled on this over at NESDEV (lots of Sega-16/spritesmind folks in that thread too XD),
    https://forums.nesdev.com/viewtopic....rt=120#p176551

    Talking a bit on the SH-2's use as a geometry processor, though I'd seen this a few times years ago on Sega-16 too, it might be good to summarize here:

    I believe the SH-2 does 16x16 multiplies in one cycle (though multiply-accumulate throughput might be limited to 2 cycles max, and delay can be 3 cycles) while 32x32-bit takes 2 cycles minimum (4-cycles worst case) while it does divides at one cycle per bit, so 32 clock ticks for a 32-bit divide, 16 for a 16-bit divide, etc.

    I believe the SCU DSP does 1 cycle 32-bit multiplies (not sure about single-cycle MAC throughput) and 32-cycle 32-bit divides ... not sure if it can do 16-bit divides any faster. It also runs at half the clock speed of the SH-2s.

    So a 16-bit fixed-point optimized geometry routine might be a bit faster on the SH-2 (slaving one to geometry), while 32-bit is likely going to be close to the same. (this all of course, for games not CPU bound by other things, or CPU bus bandwidth bound)

    For the marginal performance gain you get in best cases, it seems a poor reason to add the second SH-2, though a decent 'bonus' on top of an array of other potential reasons. (though the SoJ interviews from back then pointed more to 3D computation being the main factor)

    I've also seen comments from actual Saturn devs and some SH-2 programmers regarding the SH-2 also having some nicer features to so software floating point with its fixed point math, and being a bit friendlier to developers used to relying on FPU functions for 3D. (that's less a performance and more 'ease of use' argument, and one that better tools for the DSP should have addressed ... though also a situation where the second SH-2 put on the B-bus or localized to the VDP-1 texture bus would be useful, especially in the context of PC games heavily optimized for Pentium FPU-biased quirks, though less so for games aimed more at 486 platforms ... ie most non-quake 3D and ray casting in 1996 where you'd have a 486 FPU slaved to 3D coprocessing and not for weird graphics chunk buffering/packing in FPU regs: most such 486 optimized games, if FPU-enabled at all, still had 486SX/386-compliant routines as well, and could run on pure ALU driven math too ... hence why stuff like X-Wing, Tie Fighter, Wing Commadner II, Descent, and possibly even Tomb Raider could run on FPU-less platforms: Chilly Willy even managed getting Tomb Raider to 'run' on a 386DX-20 ... with a postage stamp sized screen window XD ) I actually wanted to test that out, but didn't stumble on any 486 or 386 board when scrounging around old PC stuff a few years back with Appoloboy ... plenty of Socket 7 and 370 class stuff, but no old 386DX-40s or 486SXs. (oddly enough a batch of AM286-20s came in at one point, and we did pick up one of those to tinker with, though I regret not going for the SIMM-slot equipped one over the DIP-socketed one ... not that it really needs more than 1 MB of RAM for any sort of realmode gaming, but still ... I've got so much old SIMM RAM0

    Heh, maybe I'll pop in there again and stumble on one of those once-common generic AM386DX-40 boards. Maybe an odd one with a VESA slot. (there's usually some old VESA cards floating around there too ... otherwise I've got an old ATI VGA/Mach8 ISA card ... not a scrounging find, but ours from back in the early 90s) Heh, I never did try installing Wing Commander on that 286-20 ... that'd be neat to try. (Wolfenstein 3D was slower than I'd expected, though I'm not sure what sort of wait states the RAM was incurring either) Heh, that reminds me, we've also got a box of old DIP cache chips for 386/486 boards, so if I find an unpopulated 386/486 board, I've got a purpose for those at least.



    Oh, and the Saturn might've been a pain to develop for, but it really didn't look too bad compared to working around all the crazy weird bottlenecks and variables that software-rendered PC games had to deal with at the time (1994-96) ... you just had some developers who were already experienced working around that stuff, and those who jumped on the Pentium-optimization bandwagon as well. Though for folks coming off Amiga, ST, MD, and arcade game development ... the Saturn might look more elegant than software rendering on an IA-32 platform. (the days of realmode x86 were mostly gone aside from DOS functionality ... so the boot/batch file/config portions of software would have to deal with that madness of virtual-realmode and oddness with extended memory managers, but you had 386 protected mode to work around for most realtime single-task application stuff ... or 32-bit linear mode, but I'm not sure DOS games could really work with that ... OTOH, you still had the issues of VGA vs SVGA memory and I/O port stuff and sound and lots of odd variables compared to consoles and home computers that generally didn't change their architectures all that much, especially beyond RAM expansion and sometimes CPU speed)

    For that matter, the Jaguar didn't look all that bad either, though you did have the chicken vs egg sort of market share catch 22 and devs waiting and seeing, that and a slow progression of detailed documentation + bug reports + tools. (given Quake was being seriously developed on it, and Carmak had expressed a great deal of advances in workaround and optimizations over his initial dabbling with Doom, including a much improved compiler, there's some indication it could've been stretched a lot further) Oh, actually, even without any sort of coprocessor add-ons or fast RAM carts or anything but the CD unit (for reasonable storage costs) Quake might have been pulled off mainly be using a lower screen resolution, like Doom and like Yeti 3D on the 32x/GBA. Given how slow the texture mapping is from main RAM, and how it can't make use of page-mode speed (it could with RAM on a different memory bank, or halting the GPU and using textures in GPU SRAM, but that's another issue) you'd get 2x the screen draw speed simply by halving the res and using Doom style double-wide pixels. Forward texture mapping on the Saturn doesn't allow that, but software rendering and hardware rasterization does. (and given rendering in main RAM works at the full random read cycle time of DRAM ... 5 clocks per read/write at 26.6 MHz, dropping to lower res would be really nice ... plus you'd have more excuse to use the hardware Z-buffering functionality without using too much RAM with a 152x160-ish 16bpp screen window with 16-bit Z-buffer would be nice, and probably fit in with Carmak's rendering scheme, but using Z-buffer depth values rather than per-polygon ray-casting for determining scene visibility ... the blitter has full-speed hardware Z-buffer functionality, so THAT aspect would be vastly faster than texture mapping itself, and anything that cuts down on actually drawing textures would be important)

    Oh, on that note, software rendering at lower res to a 16bpp window and then having VDP-1 do nothing by upscale that and draw it to the framebuffer would be nice. (VDP-1 is fast at zooming, remember, but bad at shrinking/warping/folding) And you could even use full-frame translucency to composite that with other VDP-1 sprites/objects. (translucent blending works fine so long as textels are 1:1 or zoomed/stretched) Or draw a translucent HUD at higher res over the scaled game window. (rather than slaving a VDP-2 BG layer for that)

    VDP-2 would be best to optimize for BG generation, but that could certainly include leveraging scaling/rotation effects for a more dynamic BG in 3D games to go along with camera tilt, POV shift, etc, and to do 3D-simulated sky and such (looking straight up in a first-person game for example), while using it for floor/ceiling tricks would be better for native exclusive games or PC games already using similar effects in software. (you'd also probably want to avoid fiddling with dynamic tile RAM updates and just optimize around the existing 512k) Using a VDP1 plane to add distance fog could also work, and not need to be as elaborate as Sonic R was for that. (just a simple distance fog ... and something nicer looking that Tomb Raider's fade-to-black effect ... which looks odd in bright environments: though is ideal for the Jaguar's CRY colorspace shading, incidentally) VDP2 tricks would be a good way to make some of the same compromises the N64 did for its very limited fillrate and polygon budget using the basic dev tools/library and limited documentation. (ie either keep textures low res and stretched huge, and keep models simple OR resort to a really short draw distance with a ton of fog ... Turok would be an extreme example of that, Donkey Kong 64 would be another, though that's using RARE's own modified codebase ... so hitting different limits than 'average' games)

    The Playstation itself was also mostly CPU-bound, so the GPU could out-pace the actual game engine/logic going on. I recall an interview addressing the unreleased version of Quake for the PSX having a renderer capable of 60 FPS while a functional game had to drop to 30 fps due to CPU constraints. Meanwhile, the Saturn version was capped to 20 fps by the VDP. I used to interpret comments on Saturn Quake as they'd resorted to folding every single quad into a triangle, but given the speed it manages (and how horrible triangle-only rendering would go) I've got to assume they used a mixed renderer that used triangle geometry (as you basically have to ... for math reasons) and using folded quads only when necessary in models, while otherwise treating quads as 2-triangle fans (ie situations where a PSX or software renderer would do a 2-trip fan draw, you defer to a single warped quad). So most of the level stuff should be quads (quads drawn/hung on a lattice of wireframe triangles, if you will) with enemy models and a few other things using triangles where necessary. (and some quake enemies use an unusual amount of triangles compared to typical quad-heavy 3D modeling you usually see)

    Oh, I'm also not positive, but I think the SH-2 is actually better-suited to C-style compiled code than the PSX's CPU, plus it has a more advanced cache. (it's got a unified 4kB set-associative instruction/data cache vs the PSX's direct mapped instruction cache (4kB) and 1kB data scratchpad (not a cache, but just fast on-chip RAM). The SH-2 can also split off half its cache for a 2kB scratchpad if needed (handy for sound processing and some software rendering routines) but would generally be best left as the full 4kB unified I/D cache. On top of that, the 16-bit fixed length instructions of the SH architecture means code is much denser and around 2x as much code fits in cache than comparable 32-bit RISCs (MIPS, ARM, etc). It's slightly better than 68000 code density and comparable to best-case x86 fare according to Hitachi literature. (incidentally, the custom RISC chips in the Jaguar also used 16-bit instruction length for high code density ... the assembler code also looks deceptively like 68000 code, which confused Chilly Willy when he was looking at the Jaguar Doom source iirc)

    You'd need actual compiled code benchmarks and various compilers to compare, but on the surface of things, the SH-2 looks to potentially have an advantage. OTOH with hand-tuned assembly language, you'd tend to leverage the R3000's better raw performance and can make better use of the data scratchpad.

    So you might have odd situations where games coded in C don't leave the Saturn as far behind as hand-tuned games, even though the graphics portion could be using API-level libraries on the PSX, while on the Saturn, you'd probably be using a C-interface to generate VDP lists at most. (incidentally, the ATI RAGE series of GPUs only supported a C interface for native programming, not a complete rendering API) API level extraction would probably be a bad idea on the Saturn anyway, but optimized C interfaces might have been reasonable for abstracting things above the bare register and machine code levels while still being flexible and nuanced enough to actually use the system effectively.

    Trying to treat the Saturn's graphics hardware like the PSX GPU or a 3DFX card or such would be a bad idea ... almost as bad as trying to use a first-gen ViRGE GPU for DirectX-5.x. (the Rage I was even worse, though ... really limited for anything but native 3D ... the Rage II ended up OK for DX5 once it got stable drivers, though it wasn't particularly fast ... better than a Virge or NV-1 and more compatible, though: the Voodoo 1 and RIVA 128 were in another league)



    On that note:
    http://www.vintage3d.org/#sthash.8zJyqAHN.dpbs this site is really neat


    Oh that also reminds me: I'm not sure why the Matrox Mystique used dithered mesh transparency. I don't think it used forward texture mapping, though it did use mipmapping and perspective-correct rendering ... so maybe that was the reason (mipmapping for speed, not for filtering optimization, and forward texture mapped trips and quads?). Lacking support for alpha texture is one thing, but lacking per-primitive half-transparent (or other fractions) would be really odd in general when you've got perspective correct texture mapping. It was a relatively fast card, even comparing Virge and Rage II with filtering disabled, and perspective correction was better than the Rage II. (the Virge had done pixe-accurate perspective from the start, though wasn't stellar in speed and lacked full directx-5 compliance, including lack of alpha texture support: it did vertex/polygon translucency fine, and could filter translucent textures unlike the Rage ... though the speed loss with filtering on wasn't really worth it, moreso for ports of PC/console games optimized around unfiltered rendering: Terminal Velocity for example probably would've looked nicer had it run unfiltered or had an option for such ... and also run at 320x240 ... though MAYBE run in 24-bit color: speed loss wasn't too great, and shading was much nicer ... lowres, perspective correct 24-bit color stuff was probably the Virge's best balance ... I imagine some devs would've used that configuration for console based games had it been used in one ... 304x224x24bpp would be nice ... oh right, it had Z-buffering too, and you could mix 24-bit color and 16-bit Z buffering)

    Oh right, it also didn't support indexed textures, that was a problem. The Virge that is. it supported some funky 4-bit packed interpolated color mode (using 2 color registers and a 16-shade gradient between the two) which was sort of nice for low-color textures that were ALSO going to be filtered, but it had no 16-color CLUT for textures and the 256 color CLUT was just for 256 color rendering. (namely for 2D desktop stuff ... though it could've been used for 2D games as well, or 3D without shading or blending at all, or flat shading done for solid-color polygons or texture swapping for textures ... so like 256 color mode on the Saturn without software tricks)

    In other words, the Jaguar II's GPU would've been a good deal nicer. (16 color CLUT for textures along with a software-managed 8kB texture cache, which itself could potentially be used to load compressed textures of various formats on the fly) Shame Atari had ditched the computer market as that'd have been an awesome addition to a low-cost all-in-one home computer in 1996/97. (especially if they'd switched to PowerPC by that point ... even a cost-cut one like the 602) Then again, the Jag itself would've been a nice fit in the cancelled Falcon030, and a lot easier to develop for than the console version. (68040 on its own bus, floppy disks or CD-ROM media ... hard drive space to work with, more RAM, etc) Ironic they dropped out of computers just before CBM folded and left the EU market open to Wintel (and later Apple).

    Oh ... damn, actually, Atari could/should have sold their Jaguar II project to Sega in 1996, they'd just made a big settlement with Sega a couple years prior that led to a pay-out and cross-licensing software deal, and with Atari wanting to get out of hardware but toying with the idea of spinning off the publishing end, while Sega was torn over the Saturn + successor and NVidia end of things in 1996 ... THAT would've been interesting.

    The Jaguar, Jag II, and Flare engineers' design philosophy in general was very low-cost embedded system optimized, and even beefing it up with some of Sega's advantages in big chip vendors, the Jag II chipset could've been a really nice, low-cost, high performance design ready for 1997 ... potentially late 1996 (that was the roadmap) but given Sega's situation at the time, they'd probably have pushed the engineers to add a bit more and refine things while possibly switching to a newer, denser chip process (though I think they were already targeting .5 micron, though I've seen some other things pointing to continued use .8 micron, hence also limiting the speed to around 33 MHz and the prototypes sticking to 26.6 MHz due to use of the old JERRY DSP chip externally) and pushed for something in the N64-but-cheaper-simpler-and-easier-to-code class of hardware for a 1997 release.

    A faster SH-2 model or an SH-3 mated to the Jag II would've been super nice and they could've scrapped some elements of the WIP JERRY II chip (which had a J-RISC chip intended as the CPU as well as one dedicated to sound processing). Plus they'd been focusing on continuing to use slow/cheap FPM DRAM or switch to a 16-bit bus on SDRAM (64-bit internal, fast 16-bit external ... sort of like the N64/PS2 with RDRAM, but not the nasty latency or massive peak bandwidth) but Sega could've easily pushed that to doubling the GPU speed to 66 MHz-ish, using an SH3 of similar speed, and a fast 32-bit SDRAM bus dedicated to graphics and another for the CPU. (conventional 2-bus design ... possibly also scrapping the slow sound bus Flare had planned for the DSP, though knowing Sega, they'd probably have liked that idea ... and a J-RISC as DSP hooked to cheap DRAM would probably be more flexible and a lot cheaper than what the Dreamcast later used, or even the Saturn)


    Sooo ... uh ... Sega, Atari, and Flare Technologies (all 3 engineers therein ... ) lost out there. I can't imagine SoJ's engineers wouldn't be impressed regardless of any NIH bias. The Jag/Flare design philosophy was well within the low-cost, high performance range that the SGI chipset had turned them off to in 1993, and vastly more appealing than the Saturn's compromises there (the chip processes around in 1993/4 would've made Project Reality a good deal more costly, on top of being slower). Sega + Flare + Hitachi would've been a really nice combo. (on that note, Atari probably missed out on Hitachi's marketing of the new Super H back in 1992, else they might have scrapped the very WIP and buggy JERRY DSP chip along with the 68000 in favor of an SH7032, the SH-1 with 8kB scratchpad and no ROM, as the CPU+sound+UART chip ... and potentially even using its own chunk of DRAM and not just stuck on the shared bus ... but that's another story :P )


    Oddly enough, one or both of the two main Flare II guys ended up at Nvidia eventually, not sure how much later, but I think one is still there now, and worked on Project Shield. (their handheld ARM based game console) https://en.wikipedia.org/wiki/John_M...ter_scientist)

    https://en.wikipedia.org/wiki/Martin_Brennan_(engineer)

    The third guy involved with the Jaguar was mostly a technical writer (did documentation), though he contributed to JERRY's design too, I think. Ben Cheese had left Flare after the Slipstream/Konix era and worked with Argonaut to make the Super FX chip, then form the spin-off Argonaut Risc Core embedded chip company, and died in 2001, sadly. https://en.wikipedia.org/wiki/Ben_Cheese


    Hmm, had Bernie Stolar been responsible for salvaging Atari/Flare while at Sega, we'd probably have a different view of him ... that hardware would totally fit his 'kill the saturn, cut costs, and focus on rapidly restructuring things' mentality, also his 3D-centric marketing in his Sony days (albeit the Jag 2 retained all the flexible potent display list based sprite 'object processor' hardware of the Jaguar on top of a much beefier blitter) ... oh right, plus he'd actually been briefly head of Atari Corp's Game division in 1992 (I think it was 92) just before moving to Sony and also just before that position at Atari was eliminated entirely as they phased out divisions for a more single-product plan and downsized. (and discontinued their computers, marginalized the lynx, and focused on Jaguar propaganda ... I mean marketing and licensing/contracting: and hey, they ended up scaring SoJ and getting IBM, Toshiba, and Motorola onboard in various capacities)


    Oh right, IBM was doing Atari's PCB manufacturing for the Jaguar and some other components (I think Motorola and Toshiba did most of the TOM/JERRY chips), so if Sega had taken on their project ... I wonder if IBM+Motorola would've tried to attract them away from Hitachi and towards one of the embedded Power PC chips. (the PPC 602 would've been super nice in a console, and a good fit for the existing 64-bit bus plan, even if they switched to 66 MHz core speed and SDRAM ... a unified bus at 64-bits ... socket 7/Celeron bus speed would certainly be interesting; N64 class bandwidth, but much lower latency, plus a nice, fast single-precision FPU on the 602 for 3D math and a simpler, more flexible, easier to directly code or make custom APIs for GPU than the RDP+RSP combo: plus Sega would likely release low-level documentation)

    Oh, and imagine if Sega had ALSO implemented GD-ROM along with that ... in 1997. I think I've got another pet 'what if' scenario. XD
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude its the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the worlds first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  4. #364
    Smith's Minister of War Hero of Algol Kamahl's Avatar
    Join Date
    Jan 2011
    Location
    Belgium
    Age
    29
    Posts
    8,438
    Rep Power
    137

    Default

    Jesus christ that is a long post.

    TL;DR: If you have a 64x64 texture drawn as a 16x16 square onscreen on the Saturn, you're drawing 64x64 pixels regardless. On the PS1 you'd be drawing 16x16 pixels. Forward texture rendering sucks.

    Trying to optimize the Saturn's rendering with mip maps would speed it up quite a bit, but then you have ugly jumps from texture levels since there's no filtering what so ever. Specially bad when you're only shrinking vertically or horizontally (like walls on the sides) and your mip maps are all scaled in both directions. Keeping mip maps for all directions seems like a massive waste of VRAM or CPU to generate them in real time (I'd rather waste the CPU doing some basic software rendering for transparencies ala Burning Rangers).

    Might still be worth it just to squeeze extra performance out of the machine.
    This thread needs more... ENGINEERS

  5. #365
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    30
    Posts
    9,724
    Rep Power
    63

    Default

    Quote Originally Posted by Kamahl View Post
    Jesus christ that is a long post.

    TL;DR: If you have a 64x64 texture drawn as a 16x16 square onscreen on the Saturn, you're drawing 64x64 pixels regardless. On the PS1 you'd be drawing 16x16 pixels. Forward texture rendering sucks.

    Trying to optimize the Saturn's rendering with mip maps would speed it up quite a bit, but then you have ugly jumps from texture levels since there's no filtering what so ever. Specially bad when you're only shrinking vertically or horizontally (like walls on the sides) and your mip maps are all scaled in both directions. Keeping mip maps for all directions seems like a massive waste of VRAM or CPU to generate them in real time (I'd rather waste the CPU doing some basic software rendering for transparencies ala Burning Rangers).

    Might still be worth it just to squeeze extra performance out of the machine.
    Yeah, sorry I forgot to summarize what mipmaps even are.

    And some of the real code-heads around could probably point out some mistakes I've made, but I'm pretty sure the SH-2 +local 16-bit SDRAM and direct connectivity to VDP-1 RAM would be faster than DMAing from main RAM and have better performance than the master+slave dual SH-2s arranged on main RAM. The main 'awful' situation for an SH-2 on VDP-2 RAM would be without a local bus to flip onto AND when VDP-1 is rendering everything anyway (so the SH-2 would only work in cache + whatever bits of time VDP-1 is idle/waiting).


    I'm pretty sure there's still some scenarios where letting the SH-2 render (practically) everything in software acting as a GPU on the VDP-1 bus would be faster, but more cases where it'd be a lot easier and just look nicer than compromises+effort to adapt things to play nice with VDP-1. Plus, coding an API for software rendering on an SH-2 might be a good deal easier (if trying to do 'standard' 3D) ... and also have a lot more overlap with 32x development. (including a world where they decided it was practical to continue parallel development and keep the 32x there as a budget platform, or at least do so to finish up the outstanding projects in development in 1995 ... and piss off fewer developers who'd already invested in such)

    That and non-polygon or mixed rendered games would be heavily biased towards software rendering. (ray casting, voxels, etc) THAT and the SH-2 architecture has some similarities to the J-RISC architecture in the Jaguar, and might attract some of the talented oddball Jag devs who were doing weird tricks on that architecture. (plus use the 2048 color mode as a makeshift alternative to the Jag's CRY)





    EDIT:


    The best case for optimized mixed rendering might just be splitting things up to do software-rendered triangles and defer quads to VDP-1, not bothering with the mipmapping idea. As well as software rendering anything that needs translucency in projected/warped/shrunk form. (and just make do with semi-broken gouraud shading on some heavily warped quads and the non-multiplicative lighting of the Saturn in 15-bit RGB mode and lack of real lighting support in 2048 color mode ... unless MAYBE you can organize it to do 32 shades along 5-bit bounds for a custom-optimized palette: not sure there, I don't know enough about how programmable VDP-1's shading is or if you can do single-channel color lighting effects: you'd hack that sort of effect to do a 5-bit shade-channel)


    And, Kamahl, you're right that bothering with mipmaps would probably be a waste of time and space. Simply dropping to untextured polygons in the distance would be way simpler and more memory efficient. Plus, in cases like Tomb Raider where the lighting is already mediocre, you could drop to solid-color (flat or gouraud shaded ... flat only if it's any faster) at a closer distance than games that are less excessively dark.

    Actually, I'm not sure if VDP one can just draw solid-color quads, or if it needs to be pointed to a texture, not sure on the 3DO or NV-1 either. It'd be weird if you had to point to a single-pixel texture for stuff like that rather than just having a color register or something on-chip to set for color fill operations.

    You'd still get 50% overdraw for triangles even doing solid color, so software rendering might be faster even then. (or a CPU-built list of VDP-1 line-fill operations ... you MIGHT at least be able to do hardware G-shading with that method, too and not have it broken as with folded quads)






    That said ... uh, the following is probably mostly off-topic or extra-topic stuff, but some folks might find it interesting if they care. (I already wrote it out and had it fail to post sooo ... why not?)

    ***



    Addendum to previous GPU-architecture stuff:
    http://www.vintage3d.org/verite1.php....Nls3mFKV.dpbs

    The Rendition Verite would be another early 3D accelerator using a dedicated custom RISC CPU to manage the blitter/pixel pipeline and do triangle set-up like the Jaguar (or more akin to the Jaguar II), though it's pixel pipeline was optimized around standard 15/16-bit RGB more like the PSX and most PC accelerators of the era rather than the proprietary CRY colorspace the Jaguar was optimized for. (the latter gives 24-bit RGB quality lighting at the expense of more limited colored lighting effects ... though the hardware being 4-bit and 8-bit element optimized should have adapted well to 24-bit RGB, or a proprietary 32-bit RGBY format for similar fast shading on top of 24-bit quality colored blending .... I don't recall that being a feature of the Jaguar II, but would've been easy enough to add and something Sega would've obviously appreciated ... plus 24-bit RGB is standard, CRY is non-standard, even if id Software would've been experienced with it and it was also easy to adapt most 256 color PC games to, but with silky smooth 256-shade lighting ... and fit perfectly with the Tomb Raider engine)

    The Jaguar already supported 15/16-bit RGB and 24-bit RGB (as unpacked 32-bit), but the hardware shading and translucent blending were all oriented around CRY (though blending would technically also work with 12-bit RGB or RGBA, it didn't support 4-4-4-4 colorspace) and 24/32-bit RGB supported blending via the blitter quite well and doing colored lighting/shading, but not multiplicative lighting. (trying to use subtractive blending for shading would make everything desaturate to black, like Saturn Tomb Raider but worse) The Jag blitter uses addition/subtration for multiplicative lighting via the 8-bit Y element, so adding that to an 8-8-8-8 RGBY scheme would work quite well without adding costly multiplier hardware to the blitter. (given the Jaguar already supported full 24-bit color internally and used 3 8-bit multipliers on the digital RGB stage just before the DACs, it should've been fairly trivial to include 32-bit RGBY in the original Jaguar, too, so I assume they omitted it due to it just being low priority and not seen as necessary ... though personally, I'd say it's a lot more useful than the 5-5-5 and 5-6-5 RGB modes they did include, and a truncated 4-4-4-4 RGBY mode supporting 16 light levels and 12-bit RGB colorspace would also have been more useful, plus allowed flexible colored lighting/blending ... also a 4-4-4-4 RGBI mode adding the lower nybble of the 3 color channels for fine shades, not allowing for multiplicative lighting but nice for really fine shading/transluecency and good color choices for 2D games while using a 16-bit framebuffer and 4-bit element allignment ... plus easier conversion from other RGB colorspaces ... 15/16/24-bit would all work nicely: the RGBY mode would be more lossy, closer to 12-bit RGB due to the number of redundant shades the Y element would produce, OTOH it wouldn't posterize as much as 15-bit RGB when shading, and wouldn't require dithering to smooth things out, so would probably look nicer to most people than PSX or Saturn lighting)


    Oh, and given the way the Jag texture maps one pixel/textel per read/write, doing 32-bit rendering would be just as fast, or rather, 160x200x32-bit would be faster than 320x200x16-bit while using the same framebuffer scanning bandwidth. (you'd be using unpacked 32-bit textures though, which would eat RAM fast unless you fiddled with realtime CLUT unpacking or some such with GPU assist ... shame the blitter couldn't just read the OPL's 256x16-bit CLUT for color expansion ... the GPU might be able to do that as a workaround, though) Oh, and textures loaded into GPU RAM would also be as fast at 32-bits as 16-bits, though obviously using 2x the space.
    Of course, you could ALSO just use really low res 32-bit textures and lots of re-loads between levels to make it not so bad, on top of a low res screen. So you'd have the odd contradiction of 32-bit color at low res with blocky textures, but really nice shading/lighting. On the plus side, you could synch the pixel clock to the NTSC color clock and have zero composite video chroma artifacts, just a pure 3.58 MHz pixel clock like the Atari 8-bit. :P

    Since there's no real-world 8-8-8-8 RGBY mode on the Jaguar, this isn't something homebrew devs can play with ... though there is a model that outputs 16-bits directly to the digital RGB output, so you could hypothetically use an external VDAC to do 4-4-4-4 RGBY at least, but it only has 24-bit output, not 32-bit, so the extera byte can't be used. (OTOH, having those 24 pins on the package at all, and intending super high pixel clocks for workstation use was a bit pie in the sky and waste of cost as well, especially since Atari had abandoned the computer market early in the Jag's development ... and weren't planning on using the chipset on a PC video card ... they'd abandoned their IBM-compatible Atari PC line as well, too ... else an Atari-IBM parnership PC using one of those nice little IBM 486SLC/2-50 chips would've been nice, plus the clock-trippled Blue Lightning at 3x25 MHz in 1994)

    Note IBM's Intel license didn't allow their CPUs to be sold on their own, but embedded as part of a main board (or complete PC), this would change with the IBM-Cyrix partnership in 1995. (the Cyrix 5x86 would certainly be an interesting one to couple with the Jag chipset too)

    You'd need a cheap little VGA core for compatibility, but the Jaguar (or just TOM) would make a good SVGA class 2D accelerator with proprietary 3D functionality. Actually, given they didn't need 100% compatibility with the console, they could've bug-fixed TOM and spun off a new revision specific to the Atari PC line for 1994. (had Atari shifted to x86 rather than dropping home computers entirely, that would've certainly made sense alongside the new IBM contracts/investment/interest they'd got for the Jaguar) The 15/16/24-bit RGB modes of the Jaguar itself only really make sense for standard PC-style SVGA mode compliance, honestly. Hmm, a bug-fixed, tweaked TOM also probably would've run fine with variable 25.175 and 28.322 MHz VGA clock rates and shared the oscillator(s) used by the onboard VGA core. (and also genlock nicely with VGA output)
    Last edited by kool kitty89; 02-28-2018 at 03:47 AM.
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude its the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the worlds first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  6. #366
    Nameless One SonicTheHedgehog's Avatar
    Join Date
    Aug 2011
    Location
    Cardiff, Wales
    Age
    35
    Posts
    71
    Rep Power
    9

    Default

    Quote Originally Posted by kool kitty89 View Post
    Those are SH3 CPUs/MCUs, they came too late to fit into the Saturn, but I'm pretty sure it's the CPU Sega was targeting for their Nvidia NV2 based platform, possibly the 60 MHz version of the SH3.
    Only just spotted this post so sorry for the late reply. I was more wondering wether that CPU would have been ready if the Saturn had been released around August 1995 in Japan and then early/mid 1996 in the US/Europe?

    Basically i feel that as soon as the Saturn was out it was game over for Sega no matter what they did. They needed a better designed Saturn but they couldn't of afforded to release in 1996/97 as that would of given the Playstation to much time to grab the marketand keeping the release date but streamlining the machine would leave it to weak for 3d gaming and the people wouldn't of accepted a purely 2d machine no matter how good it was. Assuming Sega had made the decision to delay the Saturn in 1993 to around late August 1995 in Japan would that CPU along with a redesigned machine have been feasable from a cost and parts standpoint for late August 1995.

    SH3 @ 57.2mhz
    2MB main SD Ram

    0.5 micron 32 bit wide VDP1 doing BACKWARD rendered quads @ 57.2mhz
    1.5 MB VRam (1MB for sprites/textures + 2x256kbit framebuffers) + texture cache

    32 channel PCM (no FM Synthesis chip)
    1MB audio ram

    SH1 on a 32 bit bus acting as both the audio chip AND CD-Rom controller
    256-512KB CD-ROM

    If you think about it they would have far fewer pin/trace counts with this design and less chips used as well as less motherboard space so i cant imagine it costing more and from what i have read online i get the feeling an August 1995 Japan launch would have been doable?

    I feel with a better 32 bit machine they would have got more 3rd party support aswel as having better games and better arcade ports and using the 4MB Cartridge we could have had respectable Model 3 ports like Virtua Fighter 3.

    Dreamcast then could have been released a few years later due to the more successful Saturn and could have been more competitive with the PS2.
    Last edited by SonicTheHedgehog; 09-13-2018 at 04:23 PM.

  7. #367
    Master of Shinobi
    Join Date
    Sep 2012
    Posts
    1,031
    Rep Power
    28

    Default

    Quote Originally Posted by Kamahl View Post
    TL;DR: If you have a 64x64 texture drawn as a 16x16 square onscreen on the Saturn, you're drawing 64x64 pixels regardless. On the PS1 you'd be drawing 16x16 pixels. Forward texture rendering sucks.
    I think it only renders 64x16 in that scenario, since it can skip over unused rows, but can't skip over unused texture pixels due to texture end codes. Which still sucks but doesn't suck that much.

    Quote Originally Posted by stu View Post
    IIRC The NV2/SaturnV08 deal between Sega and Nvidia died for some fundamentally terminal reasons.

    Firstly, Sega did not want another system that used quads as the graphical primitive and were trying to push Nvidia to include support for triangles, which Nvidia stubbornly refused to do (Curtis Priem, who was Nvidia's CTO/Chief Architect at the time, had a huge hardon for Quad/QTM based systems and it was he that was pushing the development of both NV1 and NV2.) Sega brought Yu Suzuki and AM2 to evaluate the design and towards the end had managed to convince Nvidia to include some triangle support but by that time Sega's bosses had pretty much had it with their dealings with Nvidia and they told the development staff to forget it.

    What killed the deal stone dead was that when Nvidia got the manufacturing prototypes of the chip back they did not work. It sounds like the design was pretty fundamentally broken as Nvidia tried to fix the issues without success. I personally think Sega dropped Nvidia for the best reasons, design issues with the chip would have caused delays and would have cost more money to fix.

    I agree though if the chip had worked it would have been a pretty interesting design.

    FiringSquad.com had a pretty good write up of the whole NV2 fiasco, unfortunately the site is no more, however I was able to use the Wayback Machine to pull up the article.

    https://web.archive.org/web/20110326...v2/default.asp
    The NV1 could already do triangles from what I remember. Doing quads (as well as 12-point transformed quads!) was a bonus on top. Of course, it was a waste of silicon if no one would use that function, and other cards were simply way faster at the time.
    Also remember that the NV1 also had sound and controller inputs integrated, if the NV2 was like that, then that could've also contributed to why it was dropped (Sega would rather use the Yamaha parts).

  8. #368
    Smith's Minister of War Hero of Algol Kamahl's Avatar
    Join Date
    Jan 2011
    Location
    Belgium
    Age
    29
    Posts
    8,438
    Rep Power
    137

    Default

    Quote Originally Posted by zyrobs View Post
    I think it only renders 64x16 in that scenario, since it can skip over unused rows, but can't skip over unused texture pixels due to texture end codes. Which still sucks but doesn't suck that much.
    Yeah I don't really know the details (I understand 8 and 16 bit console hardware relatively well, 32bit not so much), I was only summarising koolkitty's post.
    If the Saturn can skip unused rows it's actually a lot better since you only need horizontal mipmaps.
    This thread needs more... ENGINEERS

  9. #369
    HNNNNNNNNNNNNNNNNNNNNNNNG Raging in the Streets Moirai's Avatar
    Join Date
    Jun 2011
    Posts
    3,987
    Rep Power
    54

    Default

    Quote Originally Posted by zyrobs View Post
    My impression is that they tried pushing the System24/32 quality graphics into a home machine, and at the same time also fix all the design snafus they had with the Megadrive that prevented it from being extended. And they ended up going overboard so much that the machine ended up way too complex.

    Given that Sega demoed the Saturn back in 1994 March with Virtua Fighter and Daytona USA footage, I have the feeling that they initially imagined the Saturn as a sprite pusher that could do outdo the SNES and Neogeo, etc (not sure if you guys noticed it, but in the early 90s Sega was all about knee jerk reactions). But their Model 1/2 games ended up looking so grate, that they did their best to upgrade the processing power to be capable of pushing 3d graphics, given that the video ASIC was already capable of doing so.



    This is the rumor, but what evidence do we have to support that? We have Mean Machines Sega mentioning the Saturn having a custom NEC V60 at 27Mhz (more likely 26.8Mhz to coincide with the dot clock), video output capable of 16.7 million colours (VDP2 can do that), Alpha Channel effects (VDP2 can do that... sort of, I think?), and a "polygon generator capable of displaying and animating 16000 polygons on-screen" (which at 30fps matches the 500k figure printed on the console boxes). This was in 1993 September, and in that same article they also mentioned a possible 1994 Spring launch, however the project slipped and 1994 December was more more likely.

    I think there was one article listing the SH1 as the main processor, but it could've been a journalistic error. They might've omitted the SH2s from the listing. Who knows, the fact that they had 2x SH2, a 68k, AND a SH1, it was so unheard of at the time that they didn't knew how to report it.

    What we know for sure is:
    - the VDP1/2 was designed to work together, and were similar to System 24/32 arcade tech.
    - the VDP1 had full documents by 1993 December
    - the SCSP had docs by 1993 December as well
    - the VDP1 got a revision inbetween 1993 December and 1994 February that implemented a few minor functions (high speed shrink, pre-clipping disable).
    - the SCU went through 4 revisions (there's a list for changes in one of the Sega libraries, I'll have to dig it up, but its mostly memory addressing related stuff)
    - the SH2 was designed to work with two of them in a master/slave configuration
    - the entire hardware was finalized by at least 1994 April
    - the earliest engineering sample silicon for Saturn hardware I've seen, date to 1994 late April - early May (SCSP) early/mid-June (VDP1), and late June (the DRAM controller for the extra 1mb memory).
    - official docs dating 1994 April 1st have the full final hardware detailed.


    If there was a significant hardware change, it had to have happened back in 1993, given how much time it takes to design a system and its custom ASICs (including manufacturing of those ASICs).

    When were the Playstation and N64 (Project Reality) first demoed anyway?
    Final detail docs on april fools day... so saturns hardware was all a joke after all!

  10. #370
    Master of Shinobi
    Join Date
    Sep 2012
    Posts
    1,031
    Rep Power
    28

    Default

    Quote Originally Posted by Kamahl View Post
    Yeah I don't really know the details (I understand 8 and 16 bit console hardware relatively well, 32bit not so much), I was only summarising koolkitty's post.
    If the Saturn can skip unused rows it's actually a lot better since you only need horizontal mipmaps.
    I'm only guessing it skips rows because otherwise transparency would produce completely broken striped junk (entire rows would end twice as bright). But it only draws a few double opacity pixels per row, so it must be skipping rows.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •