The ISA/VLB VGAs should be pretty standard.

The CL should be quite good, and the ATI is probably also decent. The others I would stay away from.

+1 for the Cirrus Logic. I've found them to be very compatible, reasonably fast, and to have a decent picture quality.

Considered the releasing years, the Alliance and the RealMagic did have some features to test or just another 2D card?

If they are cheap get them all.

Stojke wrote:

If they are cheap get them all.

I agree with Stojke...can you not get them all?

But if you had to choose, I would also say CL.

But getting all of them would be good to at least have extra VRAM chips to add to other cards.

retrofanatic wrote:

I agree with Stojke...can you not get them all? […]
Show full quote

Stojke wrote:

If they are cheap get them all.

I agree with Stojke...can you not get them all?

But if you had to choose, I would also say CL.

But getting all of them would be good to at least have extra VRAM chips to add to other cards.

Yeah I think I will take them all. But I already have to spend a lot for 4MB x 4 of 30 pin ram...🙁
Nothing is cheap today.. 😁

386SX wrote:

retrofanatic wrote:

I agree with Stojke...can you not get them all? […]
Show full quote

Stojke wrote:

If they are cheap get them all.

I agree with Stojke...can you not get them all?

But if you had to choose, I would also say CL.

But getting all of them would be good to at least have extra VRAM chips to add to other cards.

Yeah I think I will take them all. But I already have to spend a lot for 4MB x 4 of 30 pin ram...🙁
Nothing is cheap today.. 😁

I know what you mean. It can really add up when buying multiple cards, but usually I find that down the road, I always regret not buying it all if it's relatively cheap.

Obviously, it boils down to what you already have and what you're willing to spend.

The Alliance is most notable for it's appearance as the 2D chipset on the Voodoo Rush - there was another chipset that also turned up there.
The Oak is not highly regarded!

I read that the RealMagic is pin-compatible with S3 Trio64+, and it is probably just a relabeled S3 chip. No idea if that's true.

Scali wrote:

I read that the RealMagic is pin-compatible with S3 Trio64+, and it is probably just a relabeled S3 chip. No idea if that's true.

I was reading that too today. But they call it an Mpeg 1 decoder solution. Did the S3Trio64+ decode in hardware mpeg1 videos?

By the way I bought them all... 🙁

😁

386SX wrote:

By the way I bought them all... 🙁

😁

Very nice!

retrofanatic wrote:

386SX wrote:

By the way I bought them all... 🙁

😁

Very nice!

My wallet disagree... 😁

386SX wrote:

I was reading that too today. But they call it an Mpeg 1 decoder solution. Did the S3Trio64+ decode in hardware mpeg1 videos?

Well, it can't do full MPEG1 decoding, but the V+ version can perform some parts in hardware.
Wiki says this: https://en.wikipedia.org/wiki/S3_Trio

Like the 868, the 64V+ has a video acceleration engine that can perform YUV to RGB color space conversion and horizontal linear filtered scaling.

So it would indeed make MPEG1-playback much faster on early systems. The YUV-to-RGB and filtered scaling were very expensive in software in those days.
I had a Pentium 133 at the time, with a Matrox Mystique, which did the same, and it allowed me to play VideoCD in 1024x768 without a problem.
With my non-accelerated Trio64, even 640x480 was a bit slow. Scaling up was not an option.

Scali wrote:

Well, it can't do full MPEG1 decoding, but the V+ version can perform some parts in hardware. Wiki says this: https://en.wikiped […]
Show full quote

386SX wrote:

I was reading that too today. But they call it an Mpeg 1 decoder solution. Did the S3Trio64+ decode in hardware mpeg1 videos?

Well, it can't do full MPEG1 decoding, but the V+ version can perform some parts in hardware.
Wiki says this: https://en.wikipedia.org/wiki/S3_Trio

Like the 868, the 64V+ has a video acceleration engine that can perform YUV to RGB color space conversion and horizontal linear filtered scaling.

So it would indeed make MPEG1-playback much faster on early systems. The YUV-to-RGB and filtered scaling were very expensive in software in those days.
I had a Pentium 133 at the time, with a Matrox Mystique, which did the same, and it allowed me to play VideoCD in 1024x768 without a problem.
With my non-accelerated Trio64, even 640x480 was a bit slow. Scaling up was not an option.

Well I always thought that conversion was more a "box feature" than really something to benefit. The same Voodoo3 (3000) DVD playback feature actually led me to buy a Dxr3 card. 😁

Certainly something important in the Pentium era. 😉

386SX wrote:

Well I always thought that conversion was more a "box feature" than really something to benefit.

Back then it really was an issue...
PCI only has about 120 MB/s bandwidth at most.
Now if you take 1024x768 32-bit, at 50 fps, you get 786KB*4*50 = 153MB/s. It simply isn't physically possible to upload video images to the card that fast.
So you'll want the card to perform scaling, so you can upload less data per frame.

Likewise, YUV can be seen as a form of compression. With RGB you get 24-bit per pixel (in practice videocards usually work with 32-bit, for alignment purposes). YUV in MPEG is stored in a 4:1:1 pattern. So only 1 in every 4 pixels has U and V information. Which means you have 6 bytes for 4 pixels, instead of 12 bytes. So it's 50% compression there.
Having the card perform YUV-to-RGB means you again have to upload less data (in practice it's usually YUY2 on early hardware, which means it's just 4:2:2, so you only have to process it horizontally, not vertically).
Aside from that, YUV-to-RGB is also reasonably CPU-heavy, involving some matrix-vector multiply for every pixel, and doing it the right way is even more expensive.
Most software players would just copy the same U/V pixels to all 4 pixels in the 2x2 block. This results in very blocky red and blue components in the image.
Doing it the right way involves bilinear filtering of the U/V pixels. Basically you take the U/V values as the center of each 2x2 block (subpixel-correct processing), and you 'smear' the values into the neighbouring 2x2 blocks.
Most hardware scalers will do this correctly.

So yes, it really did make a big difference, both in quality and because you can now run at much higher resolutions with little or no difference in performance.

Scali wrote:

Back then it really was an issue... PCI only has about 120 MB/s bandwidth at most. Now if you take 1024x768 32-bit, at 50 fps, y […]
Show full quote

386SX wrote:

Well I always thought that conversion was more a "box feature" than really something to benefit.

Back then it really was an issue...
PCI only has about 120 MB/s bandwidth at most.
Now if you take 1024x768 32-bit, at 50 fps, you get 786KB*4*50 = 153MB/s. It simply isn't physically possible to upload video images to the card that fast.
So you'll want the card to perform scaling, so you can upload less data per frame.

Likewise, YUV can be seen as a form of compression. With RGB you get 24-bit per pixel (in practice videocards usually work with 32-bit, for alignment purposes). YUV in MPEG is stored in a 4:1:1 pattern. So only 1 in every 4 pixels has U and V information. Which means you have 6 bytes for 4 pixels, instead of 12 bytes. So it's 50% compression there.
Having the card perform YUV-to-RGB means you again have to upload less data (in practice it's usually YUY2 on early hardware, which means it's just 4:2:2, so you only have to process it horizontally, not vertically).
Aside from that, YUV-to-RGB is also reasonably CPU-heavy, involving some matrix-vector multiply for every pixel, and doing it the right way is even more expensive.
Most software players would just copy the same U/V pixels to all 4 pixels in the 2x2 block. This results in very blocky red and blue components in the image.
Doing it the right way involves bilinear filtering of the U/V pixels. Basically you take the U/V values as the center of each 2x2 block (subpixel-correct processing), and you 'smear' the values into the neighbouring 2x2 blocks.
Most hardware scalers will do this correctly.

So yes, it really did make a big difference, both in quality and because you can now run at much higher resolutions with little or no difference in performance.

Thanks! I didn't know this. Considering how the K62 just couldn't decode easily the mpeg2 of dvd and the Voodoo3 lack of motion compensation or idct, probably the yuv conversion wasn't enough anyway with that generation of cpu. In fact I remember that only with the Dxr3 great card the whole process was done probably with just 10% of K62 cpu power.

In short, PC graphics has sucked for a long LONG time, at least partly because of the concept of having videomemory on a separate card, only accessible via a bus.
Other systems such as the C64 and Amiga had their memory shared by video chip and CPU, which meant that you had a lot more flexibility in processing data and showing it on screen, without having to move it around.
They could play video/animation quite well, where it has always been a struggle on PCs.