removers library Properly Clearing Frame Buffer for fb2d Functions

[+BitJag]

I already dropped an email to Seb, and I am still waiting for a reply. But I thought I might be able to save him some time by asking for help here. I have been beating my head against a wall for a few days on this one and can't figure it out. So, any suggestions are appreciated.

 

I am learning from his Example #2 program how to use his llinear and affine transform functions. I have a basic understanding of how to use the functions, but what has me confused is the visual difference between my program and his example program.

 

In my program, when I make a translation or rotation with the affine/linear transform functions the graphics data will "smear" in the frame buffer. I have seen this before when manipulating frame buffers with the fb2d functions in the past.

 

In the example program, this doesn't occur though. Somehow the fame buffer is cleared, and the graphics data is updated with no smearing between frames.

 

I am thinking it might have to do with my graphics data not being created correctly, as I have copied his example code, line for line, with the only difference being the graphics data. And any other differences in code, I have tested to see if they make a difference with no results.

 

This leads me to believe there is something fundamental with exporting my graphics that I don't understand that is creating this difference between my program and the example program. I have tried various bit depths, and other options with the removers image converter with no success.

 

I have uploaded the source C files for both the example and my program for comparison. Also a video file for for comparison, since most people probably aren't setup to build programs with the removers library (first program is the example the second is my program).

 

Thanks in advance for any help!

 

Example Program - https://drive.google.com/open?id=1mJX9XcSJ64zL-ndVxXLAzwTnPNIo_C70

My Program - https://drive.google.com/open?id=1wlf6ZeYIlNJQynaDuEKgDr0Pj1P2pxz1

Video - https://drive.google.com/open?id=19fO04bKRaan9GsMsT2PSVtSoKYCXrSPB

[neo_rg]

Did his graphic file have a black border?

[+BitJag]

Did his graphic file have a black border?

I believe so. He doesn't have the source image for the graphic included, but I was able to rip it from the binary, and it does have black.

 

A few days ago I had the same idea, so I swapped the graphic I use in the video with another that does have black in it, but it has the same effect. Still smearing.

 

I will try it again, just in case something has changed since then...

[+BitJag]

Did his graphic file have a black border?

 

That did it!

 

The image I tested with originally has black only on the interior of the image, nothing along the border. I added a black line around the edges, and now it is working. Thank you so much neo_rg! I knew this was something stupid simple.

 

If you have a second, could you tell me why this is needed, or point me to material that explains why a black border is needed?

 

What is the minimum requirement for this? (one pixel thick line around the whole image, a single pixel in the top left corner)

 

Thanks again!

[neo_rg]

It was just a hunch, after watching the video and having a think. I've done something like that on the ST in where I wasn't screen swapping properly and as a hack I placed a black border around a logo and it fixed the problem.

[Sporadic]

Sounds like the black border is then clearing the image away (smearing black pixels) behind the image as it goes, so self clearing. Well thought neo

[+BitJag]

Sounds like the black border is then clearing the image away (smearing black pixels) behind the image as it goes, so self clearing. Well thought neo

 

 

This was just a "no duh!" moment for me, after you guys made it clear. Thanks again!

[ggn]

Just a "small" caveat here: this will burn much more bus time than doing a fast clear buffer using the blitter. The reason of course being that setting the blitter in the mode required to do the rotation and copy black pixels is much slower than a dedicated clear - I'm not 100% sure but a clear might not even require source reads, just destination writes.

[+BitJag]

Just a "small" caveat here: this will burn much more bus time than doing a fast clear buffer using the blitter. The reason of course being that setting the blitter in the mode required to do the rotation and copy black pixels is much slower than a dedicated clear - I'm not 100% sure but a clear might not even require source reads, just destination writes.

Good to know may be a better way of approaching this. I haven't taken the time to look into this my self, and I am not at a skill level with assembler to approach this at the moment.

 

Seb does have a clear_screen() function that I could dig into and see what is going on there (I assume it is just writing a specific value to the created frame buffer to "clear" it). Right now when I add this function to my code, it doesn't seem to be fast enough (lots of screen flicker), and therefore may not be using the blitter in similar way as you mentioned, or at all.

 

Seb does mention on his site that the fb2d functions are still an "on-going work". I am working on getting to a point where I can dabble in the assembler level of things so I can add optimizations like this. For now, and because of my lack of programming experience, I am working within the limitations of the engine.