68000 vs Blitter on filling

[sandruzzo]

Reading this post: How did games like Starglider 2 get such a high frame rate?, it seems that 68k on ocs/ecs is faster than blitter on polygons filling. It is that true? It is possible that blitter is worthless on it?

[rothers]

Weirdly I was just wondering the same after reading a few threads about No second prize etc. Can someone with knowledge give us a detailed answer?

[dodke]

Not an expert on the subject but CPU can be faster with small polygons that overlap. Blitter is very fast when displaying large filled areas or convex 3d objects. With any large polygon 3d objects the blitter would still be faster I'm sure but more complicated to use efficiently.
With the CPU when drawing a polygon you will set or unset the bits on the bitplanes as you want. If you've already drawn something on the screen it won't matter because the CPU logic can simply draw over everything.
When drawing with the blitter you will first need to draw the edges of the polygon and then separately fill the areas between those edges. This means that if you have to draw over existing image data or other polygons you'll need to add extra passes to first draw the polygon into a clear buffer and only then you can copy it to the actual destination bitplane(s).
This is probably what you'd need to do in a game. So for drawing a single 3 edge polygon to a 4 bitplane (16 colour) screen you will need to set up and call blitter quite a few times:
- Clear temporary polygon buffer. 1 call.
- draw every edge line separately. 3 calls.
- fill the pixels inside the edges. 1 call.
- set or unset bits in every destination bitplane separately. 4 calls.

All this setting up gets costly so if you have very small polygons it will end up being faster to use the CPU.

Maybe, I haven't finished any proper blitter 3d stuff yet

[deimos]

It is definitely faster to use the CPU to fill small polygons.

The difficulty is defining "small".

Originally Posted by sandruzzo

Reading this post: How did games like Starglider 2 get such a high frame rate?, it seems that 68k on ocs/ecs is faster than blitter on polygons filling. It is that true? It is possible that blitter is worthless on it?

[Photon]

It can be faster for very small polygons, if the code is very optimized. But the same is true for any small blit; I think Mega Typhoon and likely other shooters use the CPU to plot bullets and missiles, for example.

[fstarred]

Originally Posted by sandruzzo

l it seems that 68k on ocs/ecs is faster than blitter on polygons filling.

As far I know blitter speed it's the same from A500 to A4000 , so on the latter the CPU may be more convenient

[DanScott]

The holy grail of amiga OCS 3D, would to be able to plot the edge points for a whole scene, before filling the screen in one blitter fill pass.

It's something i have researched over the last 25 years on and off... but have never got around to coding it up

Pretty much what dodke says hits the nail on the head.

When blitting polygons, the polys could be aligned in such a way that the blitter clear, fill & copy to screen passes are actually working on much more data than is required (due to the fact that blits work on rectangular areas). I am not sure if I ever saw a routine that actually split the poly into smaller more efficient blits

[deimos]

Originally Posted by Photon

It can be faster for very small polygons, if the code is very optimized.

Ignoring the "very optimized" part, which should be a given in this conversation, how do you define "very small"?

[DanScott]

Originally Posted by deimos

Ignoring the "very optimized" part, which should be a given in this conversation, how do you define "very small"?

I would say, a polygon that takes less CPU instructions to render, compared to the number of CPU instructions required to set up the blitter for clearing, drawing lines, filling, copying etc... that's quite an overhead to set up the blitter


Linedraw in itself is a large number of calculations and blitter setup per line that is drawn

[deimos]

Originally Posted by DanScott

a polygon that takes less CPU instructions to render, compared to the number of CPU instructions required to set up the blitter

So, what size polygon is that?

[DanScott]

Originally Posted by deimos

So, what size polygon is that?

Who knows... it all depends... depends how efficient the CPU renderer is

would need to write some code that generates different polygons and renders them with both methods and compare the times taken to render

[deimos]

It's really great that you've volunteered to do this.

Originally Posted by DanScott

Who knows... it all depends... depends how efficient the CPU renderer is

would need to write some code that generates different polygons and renders them with both methods and compare the times taken to render

[DanScott]

Well.. my time actually would be better spent investigating some other rendering method that I devised a little while ago

[ross]

Originally Posted by DanScott

Well.. my time actually would be better spent investigating some other rendering method that I devised a little while ago

Filling with copper colors and then 'adjust' the edges?

[DanScott]

Originally Posted by ross

Filling with copper colors and then 'adjust' the edges?

That's one method we looked at a couple of months ago, but made no progress

The other method is the one I mentioned a few replies ago. Original concept for this was thought up around 1992/1993, but only recently I have gone back to look at how it could be done efficiently

[ross]

Originally Posted by DanScott

The other method is the one I mentioned a few replies ago. Original concept for this was thought up around 1992/1993, but only recently I have gone back to look at how it could be done efficiently

ah, ok found it
Yes, this should really be a good method, considering the properties of the blitter that 're-starts' to fill up in the whole rectangle when it finds the pixels in the right way.

But what sure works well is to overlay the tasks:
while calculating the vertices in the meantime use the blitter to draw/clean/fill since not all DMA cycles are occupied by the operation.

Anyway there is too much variables to consider (number of planes, poly dimension and number, processor, fast ram..) so a best/faster method do not exists

[sandruzzo]

what about doing line setup with cpu and filling the line with blitter using D=A? in this way we have to setup only 2 blitter register, and masking first word and last word with cpu, or blitter itself.

[DanScott]

Originally Posted by sandruzzo

what about doing line setup with cpu and filling the line with blitter using D=A? in this way we have to setup only 2 blitter register, and masking first word and last word with cpu, or blitter itself.

Always a possibility, especially for wider scanlines.

Why don't you code it up and see if it's quicker

[dodke]

Just code all 3 and do benchmarks on various different sizes. Put winners in a table based on some size attributes and use that table to select which method to use.
Done.

Maybe also include versions with both blitter nasty and normal for the routines that use both the CPU and blitter for the hell of it.

[sandruzzo]

Since @deimos have all code done we can ask him to implement this way: blitter line filling + cpu