Vampire Flatshading Experimenting

[roondar]

Originally Posted by VladR

Thanks for the number.

3.3 MB @ 60 fps -> 55,000 Bytes per frame

That's less than 320x200@8bpp

So, it looks like it wouldn't be actually too useful.

Damn, I'm starting the appreciate the bloody buggy Jaguar HW more and more

The Amiga Blitter actually was pretty good, considering it did this back in 1985 and only uses half the bus while clearing, meaning you can interleave Blitter clearing with CPU clearing for about twice the given speed*. I'd have been really surprised if the Jaguar couldn't do better

Anyway, it can only clear in Amiga chip memory to begin with - which you are not using on the Vampire. I actually thought the Vampire had a Blitter as well which was supposedly way faster. But again, could be wrong.

*) it's actually a tiny bit faster for clearing: ~3.5MB/sec.

[VladR]

Oh I absolutely am not attempting to ridicule the A500 config. It certainly was a hell of a machine and its Blitter was pretty adequate for the bitdepth and resolution, not to mention the playfields capabilities, etc.

But in my quest for max performance it is certainly a valid question - if it makes sense or is even possible, to use Blitter.
Especially given the fact that it's paramount to getting max performance from Jaguar for flatshading.

So what you're saying is that Blitter will only work with certain address range, e.g. chipram (or something) ? Can you not simply give it pointer to the address where it is supposed to blit ?

Perhaps it would be useful for certain specific length of blits ? Assuming we could get it to fill 32bit value (and not just the bitplanes)...

[roondar]

Originally Posted by VladR

So what you're saying is that Blitter will only work with certain address range, e.g. chipram (or something) ? Can you not simply give it pointer to the address where it is supposed to blit ?

Yup. The Amiga Blitter (and the rest of the Amiga custom chips) can only operate in Chip RAM.

Perhaps it would be useful for certain specific length of blits ? Assuming we could get it to fill 32bit value (and not just the bitplanes)...

It can only fill 16 bit values (I mean the width of a pattern based clear here, it's obviously not limited to just 16 bits of data).

[Higgy]

VladR - was your Jag version playable? I was luckily enough to get a Jag Flash Cart so it would be nice to try it and see your work.

[VladR]

Originally Posted by Higgy

VladR - was your Jag version playable? I was luckily enough to get a Jag Flash Cart so it would be nice to try it and see your work.

Sure it was. I just didn't upload a public vid (and the latest one had majority of features disabled, but let's not get into the jaguar drama here).


Anyway, the V4 vid is getting closer as I just received my V4 today. I will certainly wait with the vid upload till I get all features ported and working - so this will take few weeks for sure. Hopefully not more than two...

[VladR]

Originally Posted by roondar

I actually thought the Vampire had a Blitter as well which was supposedly way faster. But again, could be wrong.

So, you are probably thinking of the "voodoo line rasterizer" feature - which is supposed to draw a textured scanline (in parallel to your code execution, if I understand it correctly - which would basically make it a textured Blitter).


It's a work in progress currently as it needs a lot of testing and somebody to do some work with it.


Which I volunteered to do, so I should have some first benchmarks/tests in near future.


If the numbers I saw about it are 50% correct than it will be a killer feature, as it would offload the per-pixel texturing costs from main CPU, potentially allowing for flatshading scanline fill...

[str0m]

Off topic sorry @higgy that makes two of us Speaking of flat shading polygons, check out the ST conversion of Stunt Car Racer, works well on the SD cart https://atariage.com/forums/applicat....php?id=656414

[roondar]

Originally Posted by VladR

So, you are probably thinking of the "voodoo line rasterizer" feature - which is supposed to draw a textured scanline (in parallel to your code execution, if I understand it correctly - which would basically make it a textured Blitter).


It's a work in progress currently as it needs a lot of testing and somebody to do some work with it.


Which I volunteered to do, so I should have some first benchmarks/tests in near future.


If the numbers I saw about it are 50% correct than it will be a killer feature, as it would offload the per-pixel texturing costs from main CPU, potentially allowing for flatshading scanline fill...

That's very cool actually. It'll be interesting to see what it can do once available.

[VladR]

So, a week ago I finally got my V4. Apparently, networking is still a work in progress, so I couldn't connect it to my PC to upload builds.

I ordered micro SD card extension, which arrived few days ago but once plugged in, it is so wide that neither power cable nor HDMI can be plugged in.

Given the horror stories of broken pins, I can't abuse the SD connector 20 times a day, manually plugging SD card, for each new build.

In the meantime I am trying to estimate the half milimeter clearance for other potential SD card extensions.

[VladR]

Coding wise, the rewrite saga continues.

Last two weeks, I have been rewriting lasershot handling, collision detection and smooth interpolation over the track (height/elevation).

Laser shots are fully working now - there's several procedural parameters in place - from total limit of active shots, their speed, lifetime, damage through visual ones like color or even separate 3d mesh.

Today I started porting the Enemies and their AI.

Assuming no major issues, by the end of this week I should have first level fully playable.

[VladR]

Since it's unclear how soon I can start deploying builds to V4, it's obvious now that about 90% of all code will be written against emulator - WinUAE.

This implies the 68040 instruction set with Vampire-specific codepaths coexisting in the code later via compile-time flags.

This means that a 68060 version is now extremely likely, perhaps even 040 (rtg one anyway) as I didn't expect to get this far and not have a V4-specific render path.

[OlafSch]

Originally Posted by VladR

Since it's unclear how soon I can start deploying builds to V4, it's obvious now that about 90% of all code will be written against emulator - WinUAE.

This implies the 68040 instruction set with Vampire-specific codepaths coexisting in the code later via compile-time flags.

This means that a 68060 version is now extremely likely, perhaps even 040 (rtg one anyway) as I didn't expect to get this far and not have a V4-specific render path.

That would be cool... I would be interested too and I do not have a vampire and use UAE

And perhaps there are some other crazies out there too

[DamienD]

Originally Posted by OlafSch

That would be cool... I would be interested too and I do not have a vampire and use UAE

And perhaps there are some other crazies out there too

Many, and I think "Vampire" users are really in the minority here so targeting that system only is a bit silly IMHO

[VladR]

Originally Posted by DamienD

Many, and I think "Vampire" users are really in the minority here so targeting that system only is a bit silly IMHO

If only I was doing just "a bit silly".

I went straight for bat-shit crazy, as originally (2 years ago) the plan was to do Jaguar-exclusive carts.

At the last minute I discovered V4, which also gives me console-style fixed HW (well, two configs really - 128 MB V2 and 512 MB V4) and no physical carts.

A week ago I refactored level of detail system, so as long as I create three versions of each 3D mesh, configuring LOD based on 68060 frequency should be easy.
I suppose I should create a menu for LOD and let user try to set the distances and visibility for himself.
While on V4, I will make that determination, 68060 CPU space is too fragmented so best to let everyone to choose his own preference between detail and frame rate.

[Tigerskunk]

Targetting a 68040 config might really not be a bad idea. Lots of people have those.

[coder76]

Originally Posted by Steril707

Targetting a 68040 config might really not be a bad idea. Lots of people have those.

Not to mention that 68030 boards are the most common today (40-50 MHz), because they are enough to play most games and to use workbench, and also the most compatible with old software. And they are still manufactured today in the form of ACA accelerators. Also way cheaper than 68060 boards. Some 68040/68060 boards also have problems with chip ram access speed (giving less than 7 MB/sec), which is vital for CPU-drawn graphics speed.

[roondar]

Edit: I've removed my post here, I felt it was too far off-topic.

[grond]

Originally Posted by coder76

Not to mention that 68030 boards are the most common today (40-50 MHz)

Funny how considering lowering the minimum specs to 060-based systems then led to people suggesting including 040 systems (a Vampire is ten times the speed of an 040...) and now we are even getting 030s into the mix. It is only a matter of time until someone will argue that plain 68000 systems are the most common Amiga systems and that those should be supported, too...

[d4rk3lf]

060 and 040 version would be really really nice.

But I'd like to see anyway that you push Vampire to the limit (basically, you have exclusive opportunity to do that), and then make degraded versions for 060 and 040 (and 030, if possible).
Make a 2D version for A500 too

Cheers!

[coder76]

Originally Posted by grond

Funny how considering lowering the minimum specs to 060-based systems then led to people suggesting including 040 systems (a Vampire is ten times the speed of an 040...) and now we are even getting 030s into the mix. It is only a matter of time until someone will argue that plain 68000 systems are the most common Amiga systems and that those should be supported, too...

I'm pretty sure that many do not use a real 68000 system these days, there are some kind of basic requirements for playing WHDLoad games (more memory, better CPU), and if you want to use workbench smoothly, more memory and better CPU is needed. Those who keep dreaming about nice A500 conversions of games only use UAE anyway, and can be ignored.