68000 vs Blitter on filling

[deimos]

I'll be happy to share my CPU based code once I believe I can't make it faster, but until people better than me have verified that it is as fast as it can be, it's not the basis for comparison with anything.

As for blitter based code? That's a job for someone else.

Originally Posted by sandruzzo

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

[sandruzzo]

@deimos

Thanks for your reply. you've been doing a hell of job!


I could try to put on some simple test to see which is faster. Some sort of best case scenario with well aligned quand, and fill it with blitter and cpu

[sandruzzo]

I did a simple test and blitter, on A500 seems to be more than 2 time faster

https://ibb.co/eeCN4z

[deimos]

I think your test needs to be a bit more representative of what a real application or game would draw.

Originally Posted by sandruzzo

I did a simple test and blitter, on A500 seems to be more than 2 time faster

https://ibb.co/eeCN4z

[sandruzzo]

Originally Posted by deimos

I think your test needs to be a bit more representative of what a real application or game would draw.

I'll do in the future, now I wanted to test blitter line filling with simple d=a. Since you don't need to setup a lot of register, i could help a lot the cpu.

[DanScott]

Does you blitter test iinvolve the following steps:

clearing the blitter buffer?
drawing the lines?
filling the buffer?
copying the buffer to all the bitplanes (either "or'ing" or "not anding")?

To be honest, your test is not representitive of anything if it is not doing all these things....

[sandruzzo]

Originally Posted by DanScott

Does you blitter test iinvolve the following steps:

clearing the blitter buffer?
drawing the lines?
filling the buffer?
copying the buffer to all the bitplanes (either "or'ing" or "not anding")?

To be honest, your test is not representitive of anything if it is not doing all these things....

I just wanted to see if line filling with blitter is fast. Now I have to do better test, just need time. Like I said, I'm interested on line filling

[sandruzzo]

About filling, I've an idea. Instead of fill a triangle, we can use a mask that cut unwanted pixels outside triangle edges(some sort of inverted mask)on a prefilled bitmap, and then, with blitter, copy this triangle chunck, into screen, piece by pieces, meanwhile cpu is preparing the next triangles' chunck. Every chunck is maximum 16 px in height

[Kalms]

Originally Posted by sandruzzo

About filling, I've an idea. Instead of fill a triangle, we can use a mask that cut unwanted pixels outside triangle edges(some sort of inverted mask)on a prefilled bitmap, and then, with blitter, copy this triangle chunck, into screen, piece by pieces, meanwhile cpu is preparing the next triangles' chunck. Every chunck is maximum 16 px in height

Out of curiosity, what performance would you estimate that this gives you?

[sandruzzo]

Originally Posted by Kalms

Out of curiosity, what performance would you estimate that this gives you?

I have no figures. Like I said, was just an idea that'll try

[Kalms]

Originally Posted by sandruzzo

I have no figures. Like I said, was just an idea that'll try

Okay. When the CPU "prepares" a chunk, do you intend that the CPU draws the mask pattern into a buffer? Effectively drawing the left- and right- edges of a 16-pixels-high segment of a triangle into a 1-bitplane image? If not, how do you intend this to work?

[sandruzzo]

Originally Posted by Kalms

Okay. When the CPU "prepares" a chunk, do you intend that the CPU draws the mask pattern into a buffer? Effectively drawing the left- and right- edges of a 16-pixels-high segment of a triangle into a 1-bitplane image? If not, how do you intend this to work?

You'we got it, cpu draws that mask patter, and then with blitter we can draw this chunk into buffer. This way should free cpu do fill the whole triangle since it's prefilled

[sandruzzo]

I think that with a bunch of precomputated masks(16*16 pixel), and knowing lines' slope, we can build that edge mask very fast.

[Kalms]

Originally Posted by sandruzzo

I think that with a bunch of precomputated masks(16*16 pixel), and knowing lines' slope, we can build that edge mask very fast.

Alright, that makes your idea a lot more concrete, thanks.

Here are some more things for you to consider when you refine this:

- How many mask patterns do you need? Is there a trade off between precision and memory usage here? Can the mask patterns reasonably fit into memory?
- How do you handle edges that slope more horizontally than vertically? (This is a more general version of 'how do you handle edges which cross a horizontal 16-pixel boundary halfway through a 16-line-block?')
- what the CPU does is similar to drawing the edge of a triangle. Would it make more sense for the CPU to work directly against the screen?
- How do you effectively handle the 'interior' portions of large triangles - those areas where there are entirely filled 16x16-pixel-blocks?


If you can sort out these algorithmic problems then you are closer to a point where this can be compared to other approaches.

[sandruzzo]

Originally Posted by Kalms

Alright, that makes your idea a lot more concrete, thanks.

Here are some more things for you to consider when you refine this:

- How many mask patterns do you need? Is there a trade off between precision and memory usage here? Can the mask patterns reasonably fit into memory?
- How do you handle edges that slope more horizontally than vertically? (This is a more general version of 'how do you handle edges which cross a horizontal 16-pixel boundary halfway through a 16-line-block?')
- what the CPU does is similar to drawing the edge of a triangle. Would it make more sense for the CPU to work directly against the screen?
- How do you effectively handle the 'interior' portions of large triangles - those areas where there are entirely filled 16x16-pixel-blocks?

If you can sort out these algorithmic problems then you are closer to a point where this can be compared to other approaches.

Thanks for your Questions, I'll think on them.

- what the CPU does is similar to drawing the edge of a triangle. Would it make more sense for the CPU to work directly against the screen?

Yes, is better to write directly on screen if you don't have so much colors on screen, but if you have to handle multiply bit-plane, or tringles that require to be filled with many move or movem, that could slow down

- How do you effectively handle the 'interior' portions of large triangles - those areas where there are entirely filled 16x16-pixel-blocks?

There is no need to handle them, since we have only to cut triangles' edge on a prefilled are....

[sandruzzo]

I think I wasn't able to explain this way well. Think about a piece of paper which is our prefilled area. Now, think about having scissor to cut our triangle and put it into screen.

I hope this example would be fine. Some sort of Stencil buffer

[Kalms]

I'm not going to spend more time on this myself, but from what I can see so far the two main challenges will probably be 1. memory consumption for the precomputed masks (with too few masks, the triangle edges will look ugly when they cross between 16-pixel blocks) and 2. CPU overhead per individual block.

[sandruzzo]

Another possible way to optimize this kind of rendering is to define traingles' or quads' bounding box, and fill the outside portions' of these polygons and then doing a cookie cut operation with blitter

[DanScott]

Just code it up and come back with some results. Will be interesting to see what you come up with

[sandruzzo]

Originally Posted by DanScott

Just code it up and come back with some results. Will be interesting to see what you come up with

I'm doing it, just a code a tri/quad filler to test some rendering tecniques