Open damusss opened 4 months ago
Could the 2 faulty tests be rerun?
The shifting was incorrect, not setting the space created by the shifted pixels to black.
Why do you think this is incorrect? The docs currently say:
Move the image by dx pixels right and dy pixels down. dx and dy may be negative for left and up scrolls respectively. Areas of the surface that are not overwritten retain their original pixel values.
Which looks to me like what the current behaviour is.
e.g.
Current main branch scroll a 200 pixel wide surface right by 100 pixels:
After this PR:
I think we should retain the current behaviour as the default, and if we want the original pixels not overwritten by scrolled pixels cleared to a colour (and why specifically black?) that should be an option/parameter. Otherwise we will probably accidentally break somebody's code.
As an addendum - do we think this function is likely to be a performance sensitive one like blit, or one used less frequently? I'm wondering whether it should support keyword arguments or not, now it has 3 params (possibly 4 after the above).
@MyreMylar yeah that was a misunderstanding on my side. I don't think 4 arguments are too much. If they are, what do you suggest? Another function for repeat? only positional?
Looking at how you implemented it, I believe the best option would be to use the same system used for flags on surfaces and window. Like that we can a fair amount of arguments for this function.
Looking at how you implemented it, I believe the best option would be to use the same system used for flags on surfaces and window. Like that we can a fair amount of arguments for this function.
That would require 2 new constants pygame.SCROLL_REPEAT and pygame.SCROLL_ERASE i believe. the new arguments would go from 2 to 1, i guess
Looking at how you implemented it, I believe the best option would be to use the same system used for flags on surfaces and window. Like that we can a fair amount of arguments for this function.
That would require 2 new constants pygame.SCROLL_REPEAT and pygame.SCROLL_ERASE i believe. the new arguments would go from 2 to 1, i guess
I prefer this approach.
I think there were separate functions for the actual process of scrolling and the function definition, what about doing this to keep some kind of readability ?
After a little digging with @damusss about some issues, here are the potential problem we are facing out currently:
erase
mode doesn't work when we have an alpha channel.https://github.com/pygame-community/pygame-ce/assets/69472620/2a261e5c-c730-442a-9a35-d29a12bfc026
Code example so you understand how it simplifies the life a lot : https://gist.github.com/bilhox/ce024b994e536338a750a760024b5939
The shifting was incorrect, not setting the space created by the shifted pixels to black. Now it does that [EDIT: now it does that with the erase flag only], but most importantly I think I implemented this feature idea: https://github.com/pygame-community/pygame-ce/issues/2159 implementing a way to allow for repeated shifting. The video proof is here: https://discord.com/channels/772505616680878080/772940667231928360/1240055647584911443
I would love feedback about the C code as I did quite a lot of pointer operations. Why?
Question: how can I add a test for it? Edit: I modified the test, tell me if it's incomplete
You can use the following code with my request to test locally: