Vampire Games

[daxb]

Originally Posted by idrougge

No, SAGA is the yet-unreleased super-chipset of the Apollo architecture, which is based on a model closer to the Amiga custom chipset. The current RTG support in the Vampire is basically just a framebuffer, eating a lot of CPU.

Sounds stupid. RTG should be super fast without or nearly no CPU usage. Maybe an RTG chip on board would do the trick. To have AGA a bit faster is nice/good but for compatibility and future I would go the RTG way.

[grond]

Originally Posted by daxb

Sounds stupid.

Sounds wrong. The Vampire has something like 400 MB/s mem bandwidth. A 640x480x8 resolution at 60 Hz takes 17.5 MB/s away from the bandwidth available to the CPU. This is only about 5%. 16bit, 24bit and 32bit resolutions take 2, 3 and 4 times 17.5 MB/s away from the CPU, obviously. The CPU will often work inside its caches during such times. The SAGA's display DMA also has a buffer and will leave the memory interface to the CPU as long as the buffer is well filled which also reduces the impact of the display DMA on the CPU. Of course, if you run really HD resolutions in 32 bits, the display DMA has quite some effect on the CPU but this is no difference to any other "chipset graphics" computer on the market. My Intel Atom began to crawl in such a scenario. Obviously such high resolutions aren't viable for games on an Amiga anyway.

[coder76]

Does anyone know, what is the current status of Vampire SAGA? Is it possible to program directly like for OCS/ECS/AGA? Does it have similar DMA control registers for bitplane, sprite, blitter, copper, audio and disk, located at $dff000?. And copperlists etc. of course.

I hope the documentation will be better for SAGA than for AGA..currently I have only some VGA compatible displays around, and it was difficult enough to open correctly a 640x480 screen with AGA in hardware. There are some docs available for AGA, but they aren't quite right. I'm seeing things like people opening screens with -8 modulo in 4x fetchmode, instead of setting display DMA data fetch regs properly, or screens that are wrongly aligned/missing data.

[grond]

All SAGA features are controlled through registers in the traditional register address space. This also means that they can be controlled by the copper. Of course, copper tricks won't be available through RTG libraries. So some hardware banging may even be necessary to unleash the full power of SAGA (e.g. planar overlays over chunky screens, totally free hardware scrolling of chunky screens etc). Otherwise SAGA would only be very fast AGA plus very fast RTG (which is pretty nice already).

[alpine9000]

Originally Posted by grond

All SAGA features are controlled through registers in the traditional register address space. This also means that they can be controlled by the copper. Of course, copper tricks won't be available through RTG libraries. So some hardware banging may even be necessary to unleash the full power of SAGA (e.g. planar overlays over chunky screens, totally free hardware scrolling of chunky screens etc). Otherwise SAGA would only be very fast AGA plus very fast RTG (which is pretty nice already).

That sounds a lot more interesting (for me) than just writing a boring SDL game.

[idrougge]

Originally Posted by daxb

Sounds stupid. RTG should be super fast without or nearly no CPU usage. Maybe an RTG chip on board would do the trick. To have AGA a bit faster is nice/good but for compatibility and future I would go the RTG way.

Yes, it does sound stupid, doesn't it?
Apart from the fact that, as Grond points out, the RTG feature of the Vampire soaks up RAM bandwidth (more with higher resolutions), it is also unaccelerated. That means that the CPU will need to do the job of the blitter, further degrading the performance.

And that's even discounting the fact that 060+RTG games are just so 2001.

[grond]

Originally Posted by idrougge

Yes, it does sound stupid, doesn't it?
Apart from the fact that, as Grond points out, the RTG feature of the Vampire soaks up RAM bandwidth (more with higher resolutions), it is also unaccelerated. That means that the CPU will need to do the job of the blitter, further degrading the performance.

"Degrading performance"? It's a lot faster than any of the accelerated graphics options for the Amiga: http://www.apollo-core.com/gfx/SAGA-P96.png And I did not point out that the RTG "soaks up" bandwidth, I pointed out that in a realistic scenario the display DMA takes a very small part of the available memory bandwidth. And if you think about it a little more, in a unified memory architecture it doesn't really matter whether it is the CPU or a companion chip that does the blitting because they both have to go through the same bus. If the companion chip does a lot of large blits, the CPU will be blocked from memory anyway. A "chipmem-only" Amiga is a unified memory architecture, just with very slow memory. Of course, it would be possible to add yet another memory bus to the 080 and add "fastmem" to the Vampire. But just look at the numbers: while fastmem on an 060 board usually is like 20 times faster than the Amiga chipmem, the Vampire "fastmem" would only be between 5 to 20 percent faster than the Vampire "chipmem". This hardly justifies the increased hardware complexity and costs.

And that's even discounting the fact that 060+RTG games are just so 2001.

Which is why you prefer games that are so 1985?

[Daedalus]

Originally Posted by grond

It's a lot faster than any of the accelerated graphics options for the Amiga:

Is it? Perhaps it has improved massively recently, but last time I saw a Vampire playing Payback it struggled to get anywhere near the speed of my A1200 with a Mediator + Voodoo 3 at the same resolution, and had nowhere near the resolution capabilities (said Voodoo-equipped A1200 tops out at 1920x1200x24@60Hz). Maybe you're comparing it to cards like the Picasso IV, which are even further obsolete than the Voodoo, or maybe you're comparing specific benchmarks that favour the Vampire; I can't tell since the link is blocked here. But some real-world comparisons would be nice.

[demolition]

It is a real-world comparison with a Cybervision 64 and P-IV setup. It is probably not quite up to Voodoo 3 speeds, but hopefully it can get close with further optimizations (resolution cannot though).

[grond]

Originally Posted by Daedalus

Is it? Perhaps it has improved massively recently, but last time I saw a Vampire playing Payback it struggled to get anywhere near the speed of my A1200 with a Mediator + Voodoo 3 at the same resolution

There are quite a few videos of Payback on the Vampire on YouTube. I'm not sure what "struggle" means to you but to me they don't look as if the Vampire did a bad job. Perhaps not as good as your gear but this is only possible if Payback actually uses rendering functions provided by your graphics card. I don't think there is a lot of code that does this.

While your mediator setup can drive high resolutions, the bus that connects the graphics memory to the processor is so slow that you can watch the pixels being updated one after the other. Not my definition of a fast graphics solution.

[Daedalus]

Originally Posted by grond

There are quite a few videos of Payback on the Vampire on YouTube. I'm not sure what "struggle" means to you but to me they don't look as if the Vampire did a bad job. Perhaps not as good as your gear but this is only possible if Payback actually uses rendering functions provided by your graphics card. I don't think there is a lot of code that does this.

And is that not the definition of hardware acceleration? Don't get me wrong, it's playable on the Vampire, but my immediate thought was "is that it?" I was expecting more from it after all the hype.

While your mediator setup can drive high resolutions, the bus that connects the graphics memory to the processor is so slow that you can watch the pixels being updated one after the other. Not my definition of a fast graphics solution.

You clearly haven't used such a system then. It's quite comfortable in everyday use, windows are redrawn instantly, icons are displayed as fast as they can be read from disc, and at no point is the screen ever visibly updated pixel-by-pixel. The only slowdown occurs when swapping large screens, since then you're going beyond the video RAM available and need to load the other screen and its windows into video RAM instead. That takes about a second, enough to be quite noticeable and jarring compared to the otherwise instant responsiveness, but is also quicker than it takes my monitor to switch resolutions so it's quite acceptable, and only ever noticeable when switching multiple identical screens.

At lower resolutions of course it's instant - 1600x1200 for example has no perceptible screen switching time.

[demolition]

I think the point here was that perhaps Payback was designed specifically to take advantage of Voodoo 3 cards. The only way the Vampire could compete with that is to make it Voodoo 3 compatible (which seems like a silly way to go). You could also look at it another way that software that was designed to utilize AMMX and the other Vampire specific features does not run well on non-Vampire software (if at all). It is not the fault of the hardware or the software specifically, but a combination of the two.

[Daedalus]

Well, I was comparing the software rendering mode since I prefer that to the Warp3D mode. Obviously comparing two different executables optimised for different hardware would be pointless in this context. That game mode is graphics card independent, though I'm sure it relies heavily on standard P96 functions that are accelerated on most cards, just like Intuition and any other system-friendly software.

Pushing a screen to video memory pixel-by-pixel would obviously be extremely slow on such a setup, and much faster on a Vampire. Thankfully most software doesn't use such methods.

[grond]

Originally Posted by Daedalus

And is that not the definition of hardware acceleration? Don't get me wrong, it's playable on the Vampire, but my immediate thought was "is that it" I was expecting more from it after all the hype.

That is the definition of hardware acceleration but, as I said, to my knowledge there is very little Amiga code that uses such features. I think the very fast bus of the Vampire is a far more useful feature in comparison and will show in many more programs. E.g. 60 FPS high colour animation as in the Dragon Crown demo for the Vampire is just impossible with a slow video bus.

The only slowdown occurs when swapping large screens, since then you're going beyond the video RAM available and need to load the other screen and its windows into video RAM instead.

With just 16MB of video RAM there ought to be quite a lot of those slow-downs when running several programs on screens with high colour depths. But this doesn't really matter. It's good that you have a setup that meets your preferences.

[demolition]

Well, then I think this new P96 driver should provide significant speed boosts in Payback since the improvements looks like they are generally scattered all over the P96 accelerated functions.

[grond]

Originally Posted by Daedalus

That game mode is graphics card independent, though I'm sure it relies heavily on standard P96 functions that are accelerated on most cards, just like Intuition and any other system-friendly software.

Then it might be worth looking at Payback again once the (CPU-)accelerated new SAGA driver is available.

Pushing a screen to video memory pixel-by-pixel would obviously be extremely slow on such a setup, and much faster on a Vampire. Thankfully most software doesn't use such methods.

Um, I think that most games software does use such methods.

[Daedalus]

Originally Posted by grond

That is the definition of hardware acceleration but, as I said, to my knowledge there is very little Amiga code that uses such features. I think the very fast bus of the Vampire is a far more useful feature in comparison and will show in many more programs. E.g. 60 FPS high colour animation as in the Dragon Crown demo for the Vampire is just impossible with a slow video bus.

Naturally, full video playback on the Voodoo setup is impossible at the resolutions it can be done on the Vampire. But all this is related to your statement that the Vampire's framebuffer is "a lot faster than any of the accelerated graphics options for the Amiga", when clearly that's only true for certain tasks for which the Vampire's architecture is suited.

With just 16MB of video RAM there ought to be quite a lot of those slow-downs when running several programs on screens with high colour depths. But this doesn't really matter. It's good that you have a setup that meets your preferences.

A 1920x1200x24 screen is around 7MB, so while two such screens will slow down when switching between them, there are no slowdowns at all when working on either screen with many windows open. So yes, it is a very pleasant machine to work on.

Originally Posted by demolition

Well, then I think this new P96 driver should provide significant speed boosts in Payback since the improvements looks like they are generally scattered all over the P96 accelerated functions.

Ah, so it's no longer a simple framebuffer then? Yes, that should massively improve things alright, because on paper the Vampire should run rings around my A1200 setup. Clearing it of such bottlenecks as a simple framebuffer will make it a far more impressive piece of equipment.

[Samurai_Crow]

The original P96 driver didn't use AMMX at all. The new one uses AMMX2.

Sent from my Prism II using Tapatalk

[demolition]

Originally Posted by Daedalus

Ah, so it's no longer a simple framebuffer then?

I think that it wasn't simply a frame buffer before, but the various P96 API functions had just not been optimized very much.

[grond]

Originally Posted by Daedalus

But all this is related to your statement that the Vampire's framebuffer is "a lot faster than any of the accelerated graphics options for the Amiga", when clearly that's only true for certain tasks for which the Vampire's architecture is suited.

Okay, that statement was probably wrong then.