Weirdest actual 3D card for PC's

[AzBat]

Uhm, was it ever introduced at all? Thought I read something about the card never making it to market.

I believe it was. Metabyte was the first to announce one back on Halloween 97. It was called Wicked 3D. Bad thing is OAK announced a couple of months later it was divesting its PC audio and graphics division. Metabyte announced that they would only make it available for high-volume VARs and OEMs in Feb. 98. So it was available, but highly doubtful any were shipped to retail. And maybe even doubtful that any were shipped to VARs or OEMs. However, they did continue a couple of months later with the release of a Voodoo2 card as the replacement for the WARP5.

Tommy McClain

EDIT: fixed quotes

 

[Dio]

I think one of the main reasons it didn't suceed was because it didn't have any way of turning off FSAA to make it go faster.

AFAIK it wouldn't have been any faster. It used a scan-line rendering process that meant it got the edges of the polygons 'for free'.

 

[ben6]

Hrm that picture is old school. A friend says there's SEVERAL HUNDRED sitting in Microns labs (the picture is a Rendition reference verification platform).

 

[ben6]

geez tommy and Dio you guys been around FOREVER

 

[AzBat]

geez tommy and Dio you guys been around FOREVER

[sarcasm]
Ahh thanks.
[/sarcasm]

Just kidding. Though I did turn 30 on Monday. Not as old as some of the other geezers here, but I'm starting to feel it. Like I said earlier, I got started with consumer 3D graphics in 1995. So I was 22 at the time. I suspect there are still a few others here that have been around as long or even longer.

Tommy McClain

 

[ben6]

Err obviously, I didn't mean it that way. Just reminiscing from the old D3D days. Wonder whatever happened to that guy that ran the intel side of that site?

 

[Dio]

geez tommy and Dio you guys been around FOREVER

I did turn 30 on Monday. Not as old as some of the other geezers here, but I'm starting to feel it. Like I said earlier, I got started with consumer 3D graphics in 1995. So I was 22 at the time. I suspect there are still a few others here that have been around as long or even longer.

Sounds horribly familiar, although I turned 31 last week. I started out in 3D contracting to do drivers for BRender back in 95 or 96, so I got all the old cards preproduction, made friends with some excellent devrel guys at S3 and ATI, and started contracting with them to do some game ports. The rest is history....

 

[Simon F]

Oh to be 31 again...

Anyway, all this reminiscing has reminded me of what I would consider to be the weirdest "framebuffer" I ever had to work on.

My first job was writing ray tracing software for a transputer-based system in Aus', and, to save memory, the HW guy had designed the development card's frame buffer to be runlength encoded - it didn't have pixels at all per se.

Each scanline consisted of up to 128 runs (I can't remember if these used blends or were a single colour) with the added restriction that the minimum run length was 3 pixels (I think the max run length was about 1/4 of the X res). To display the results of my work, I also therefore had to write a 'compressor' to fit the rendered image data to the available runs.

It worked reasonably well, but I really felt sorry for the guy who wrote a windowing system for it - complete with software mouse pointer!!!!!

 

[Dio]

Sounds a bit like the Amiga's sample-and-hold mode... think they chickened out of windowing mode for that one... but I never had one of those, I was an Atari man.

The VCS would get my vote for weirdest framebuffer - i.e. it didn't really have one. I've been reading some of the hardware docs on the web. The best quote was along the lines of 'It's easy to see why VCS cartridges didn't crash - if it wasn't perfect it just plain didn't work!'

 

[Simon F]

Sounds a bit like the Amiga's sample-and-hold mode... think they chickened out of windowing mode for that one... but I never had one of those, I was an Atari man.

I think HAM would have been pleasant! At least (IIRC) you could always choose to use a lower colour precision value for any pixel.

 

[ET]

Talking about strange graphics modes:

Just in case you haven't encountered the Amiga's Hold And Modify mode, it worked by changing just one colour component per pixel. It had 6 bits per pixel, where it 2 bits said what to change (either use one of 16 paletted colours, or modify R G or B). It also had halfbrite mode, which had 32 paletted colours and a bit to show them at half intensity (it only had a 32 entry palette). Plus it used bitplanes for the display, that is, it didn't pack the bits consecutively, as most other chips did. All in all, pretty interesting.

The ZX81's display memory was in the form of characters (that was in the age of character displays) with an end of line character to save memory in incomplete lines (it had just 1K of memory total, including the display). The basic clear display took 23 bytes (for 23 lines).

The Apple IIGS had a fill mode, where the start of the line could be set to a colour, and that colour would continue until it was changed, allowing a fast line fill by just changing two pixels.

 

[DeanoC]

Talking about strange graphics modes:

Just in case you haven't encountered the Amiga's Hold And Modify mode, it worked by changing just one colour component per pixel. It had 6 bits per pixel, where it 2 bits said what to change (either use one of 16 paletted colours, or modify R G or B). It also had halfbrite mode, which had 32 paletted colours and a bit to show them at half intensity (it only had a 32 entry palette). Plus it used bitplanes for the display, that is, it didn't pack the bits consecutively, as most other chips did. All in all, pretty interesting.

The ZX81's display memory was in the form of characters (that was in the age of character displays) with an end of line character to save memory in incomplete lines (it had just 1K of memory total, including the display). The basic clear display took 23 bytes (for 23 lines).

The Apple IIGS had a fill mode, where the start of the line could be set to a colour, and that colour would continue until it was changed, allowing a fast line fill by just changing two pixels.

But the best Amiga 'framebuffer' was copper mode The copper was a display coprocessor capable of changing hardware registers (like the colour table). Colour 0 was the background colour and it was possible to write directly into a copper list (i.e rewrite the program every frame). The only problem was the copper took 4 dot clocks (IIRC) to change a register but apart from that you could create any framebuffer you like (1 line with 1 pixel, next line with 8 pixels, next line with 80 pixels) and each colour could be any of 4096 colours. You could even do weird things like halfway down the screen, cause the blitter to rewrite the copper list, or the framebuffer to 'loop'.

Most famously Team17 used it in Alien Breed 3D (Doom like game) for 4096 onscreen colours and real-time lighting etc.

It was also possible to use a similar technique to achieve a VCS style framebuffer less system (infact you could even combine all 3! Use the bitplane HAM mode for overlayed hires, a true highcolour lores copper framebuffer in the background plane and then get CPU to 'tweak' all of the above in real-time )

 

[BoardBonobo]

All this talk of the Amiga is almost making grab my ROM kerenel reference manual and the Hardware Guide. Boot up the 4000 and look at all my old code, and then sit and reminisce about the good (bad?) old dazes.

 

[Hyp-X]

The ZX81's display memory was in the form of characters (that was in the age of character displays) with an end of line character to save memory in incomplete lines (it had just 1K of memory total, including the display). The basic clear display took 23 bytes (for 23 lines).

IIRC it was 24 lines, like on the Spectrum.

Talking about the ZX spectrum it was more "conventional" framebuffer, altough the fact that the address of the nth line was

((n & 0xC0) << 5)  + ((n & 0x38) << 2)  + ((n & 0x07) << 8) + 0x4000

made it a "little" complicated.

 

[Dio]

bitplanes are evil. I had to live with those for the whole six years the ST was my main target.

Display lists are old as the hills. Hardware ones were in the Atari 400/800, I think (and the designers of that were largely responsible for the Amiga). The ST had to do them in software - mostly for colour change reasons. This was mostly used in demos, but was actually practical in games - the pinball game I did on the ST used different palettes on different parts of the table. The Amiga was far more flexible - a very clever system.

The addressing of the Spectrum was perverse because it used the refresh cycles on the Z80 to generate addresses for the screen updates...

 

[ET]

IIRC it was 24 lines, like on the Spectrum.

Yeah, sorry, I mixed it up with the VIC20, which had 23 lines of 22 characters.

The unique thing about the VIC20 is that it had nibbles for its colour memory -- that is, half bytes.

 

[DeanoC]

bitplanes are evil. I had to live with those for the whole six years the ST was my main target.

Display lists are old as the hills. Hardware ones were in the Atari 400/800, I think (and the designers of that were largely responsible for the Amiga). The ST had to do them in software - mostly for colour change reasons. This was mostly used in demos, but was actually practical in games - the pinball game I did on the ST used different palettes on different parts of the table. The Amiga was far more flexible - a very clever system.

The addressing of the Spectrum was perverse because it used the refresh cycles on the Z80 to generate addresses for the screen updates...

Yep the Atari 400/800 chip had display lists, Same kind of stuff was possible (split resolution was used alot 8 bit Atari stuff). IIRC Antic was the name (also did collision detection which the Amiga also had).

Atari ST was so simple (hardware wise). The ST's graphics chip was such a simple machine compared to the the Amiga graphics (Video shifter compared to Agnus's Copper and Blitter).

IIRC To achieve a copper style effect, you could get the video shifter to interupt at a particular screen clock, in the ISR you would update the palette or if you were a demo coder switch NTSC/PAL at the right point to access overscan. I remember Space Harrier used the interrupt trick to get more colours on the ST for the background sky effect.

I've still got my very first book I ever brought on 3D graphics, Abacus 3D graphics in Atari ST Assembler. Don't produce books like that anymore (had several hundred pages of assembler to type in)

 

[darkblu]

come on, guys, bitplanes and mid-refresh palette/dac programming were everyday stuff on EGAs and VGAs alike.

now, the classic apple2 had really funny color graphics mode, and the monochrome 'hires' mode was no less cunning either ..having a well-optimized 'division by 7' routine for the 6502 was really important in those days, yeees..

 

[ET]

now, the classic apple2 had really funny color graphics mode, and the monochrome 'hires' mode was no less cunning either ..having a well-optimized 'division by 7' routine for the 6502 was really important in those days, yeees..

Come on, don't be so vague -- give some details!

 

[Simon F]

now, the classic apple2 had really funny color graphics mode

That was the 'complementary colour pair' addressing wasn't it? That came back into the limelight recently because of Microsoft's patent on LCD AA/"Clear Type". There were arguments that it had all been done before on the Apple ][.