Well, it's almost as fast as fullscreen AB3D2 on my machine ;)

[Karlos]

Just for the lulz...

[youtube]UcuNR3yyIo4[/youtube]

You'd have to be certifiable to try and play it though.

[paul1981]

Was that 640x480?

[Karlos]

Was that 640x480?

Yes. I don't have any lower resolution modes defined at the moment.

[rvo_nl]

Hah, great video. I was hoping for better, but I guess this is already quite an achievement. I remember when I got my first pc this was one of the first games I played on it and I remember thinking my Amiga -which was standing next to it and was equipped with ppc+bvision, would never be able to run that.

Wrong, wrong.

[Karlos]

Hah, great video. I was hoping for better,

A CSPPC + CVisionPPC would be better

but I guess this is already quite an achievement. I remember when I got my first pc this was one of the first games I played on it and I remember thinking my Amiga -which was standing next to it and was equipped with ppc+bvision, would never be able to run that.

Wrong, wrong.

It runs, but it's not exactly what I'd call playable. I just thought I'd share it to show that improvements to the driver have been made. Recent iterations were suffering from a bad texture corruption bug which I've finally more or less solved.

[Damion]

Wow! Never thought I'd see that!

[rvo_nl]

I just thought I'd share it to show that improvements to the driver have been made. Recent iterations were suffering from a bad texture corruption bug which I've finally more or less solved.

well done then Are there ways to improve performance by lowering settings or screen size?
 
Cant wait to get my system running again, I got to try this.

[Karlos]

well done then Are there ways to improve performance by lowering settings or screen size?

Well, it might help, but I'm not sure that fillrate is the limit at 640x480. The main problems are:

1) Lack of texture memory - even at the lowest texture detail possible, there's not enough VRAM to hold them all, so paging them in and out is practically unavoidable.

2) The driver runs in PIO mode. Theoretically, DMA is possible, but I've never gotten it working. DMA based drawing would allow better overlap between the CPU and Permedia2. DMA could also theoretically help with texture transfer from main memory.

3) The driver only handles rendering as the final stage of a software 3D pipeline. Even as a PIO mode driver, it spends some time waiting to be able to send the chip commands. Instead, it could be doing some software 3D transformation calculations for the next polygon. But that would require massive updates to Warp3D (to include 3D transformation into the system) and whatever flavour of GL is implemented on it in order to use it.
 

Cant wait to get my system running again, I got to try this.

256MB is an absolute must. Just loading the game alone used close to 170MB...

[rvo_nl]

Wow, that means it would never work on Cvisionppc? :| Im glad I have the full 256. Lets just hope I can quickly find out whats wrong with my machine.

[Karlos]

Wow, that means it would never work on Cvisionppc? :| Im glad I have the full 256. Lets just hope I can quickly find out whats wrong with my machine.

Actually, Darren Eveland was able to run it on his CSPPC previously. I suspect the game actually grabs as much RAM as it is able and perhaps 128MB is enough.

There's a video of an older (pre-release) version of the driver on his system running quake 3 with the same (or at least similar) basic settings and it was certainly a bit faster.

[youtube]3GNtOM3ZLQM[/youtube]

You'll see some nasty graphics corruption at the end. This was a long-standing bug that has only been kicked into touch recently.

[delshay]

I think a modified Blizzard/Bvision will out class a Cyberstorm/cybervision in GFX ONLY according to the benchmark I have seen posted on other website. Cyberstorm has CPU power over Blizzard, but according to benchmark figures Blizzard has a faster PCI bus.

This is reflected here that I never needed to use a screemode below 800x600 & a small number of PPC games showed no difference with 1024x768 but you need a very high PCI bus speed to play at those screenmode.

Cyberstorm 400Mhz will not hold this crown for long on classic amiga, I just need to finish the last Bvision project ( Master Bvision ).

[Karlos]

This is reflected here that I never needed to use a screemode below 800x600 & a small number of PPC games showed no difference with 1024x768 but you need a very high PCI bus speed to play at those screenmode.

Only with games where you don't have texture paging. And the larger the screenmode, the less room you have for textures and the more likely paging becomes.

Even with some recent optimisations in this area, Quake 3 on full texture detail will bring your Blizzard/BVision combination to it's knees, I guarantee it.

[matthey]

I think a modified Blizzard/Bvision will out class a Cyberstorm/cybervision in GFX ONLY according to the benchmark I have seen posted on other website. Cyberstorm has CPU power over Blizzard, but according to benchmark figures Blizzard has a faster PCI bus.

This is reflected here that I never needed to use a screemode below 800x600 & a small number of PPC games showed no difference with 1024x768 but you need a very high PCI bus speed to play at those screenmode.

The only reason PCI bus speed is important is because there is not enough texture memory on the Permedia 2 as Karlos pointed out. As the resolution increases, more and more textures have to be retransferred over the gfx bus. A fast 68060 with a slow gfx bus Mediator and Voodoo 3+ with plenty of texture memory can compete with a faster PPC with faster gfx bus and Permedia 2 with low texture memory for some 3D. It's a matter of how much work doesn't have to be redone. My 68060@75MHz with Voodoo 4 640x480x16 is more playable with GLQuake than Karlos's demo. Don't be surprised if that same rev6 68060@100MHz with Voodoo3+ in a Natami with non-handicapped PCI gfx bus outperforms Classic PowerPC boards for 3D requiring a lot of texture memory.

Edit: Karlos beat me to it. Texture memory rules, at least when there isn't enough .

[Karlos]

Incidentally, if you take a Permedia2, put it on an AGP bus, with a proper DMA enabled driver (where command buffers and textures are downloaded by the chip from system memory, interrupts can be used to signal stuff we have to poll for), and attach it to a CPU where the rest of the time spent is irrelevant, it can turn out good performance:

[youtube]5EA9xtM22tA[/youtube]

The above is on a FireGL card in a 1.4GHz P3 machine, where the chip is at least able to run at it's full potential, unhampered by all the problems it has in a BVision machine.

[Karlos]

I am hoping that with some experimentation and a limitless supply of irreplaceable old BVision cards*, I might be able to get DMA working at least.

At the bare minimum, I would like to be able to use DMA command / vertex transport as it would increase the parallelism between the CPU and the Permedia significantly. The CPU would also be able to spend far less time polling the chip to see if it is busy and whether or not it has space in it's limited FIFO for more data. Which, having stripped away many layers of code from the innermost loops, is where it now spends most of it's time.

* I wish...