Answer 1

Ur code seems right mate. And i dont see any overlay at all. But even if there is, its not much of an issue. The sprites for such games usually have a small overlay to prevent this as well as other weird things. It could be like grass or maybe fog or smth. Point is, once u put on sprites it shouldnt be visible. Check out Hollow Knight, even a very large overlay looks good there.

Answer 2

Bob_Li

Speaking from the perspective of mentors, we are aware of these bots, and we try to report them. One can identify them rather easily from their activity and their wording, but unless they actually edit to insert the spam, I have nothing but a strong suspicion. Keep reporting them. When it looks inappropriate or suspicious, you can share the thread or profile link with a mentor or on "Stay Safe" – so that moderation can review or keep an eye on them.

Spamming is cheap, so cheap that the creators of the spam don't even put effort in caching it.

Answer 3

not sure. Looks ok to me. I don't see the problem you're describing.

how about drawing the player before the platform?

in the bottom of your code

# reverse these:

pygame.draw.rect(......., player)
pygame draw.rect(........, platform)
pygame.display.update()

this way, the platform will cover the imperfections. perhaps it's an anti-aliasing issue.

Answer 4

to moderators:

spammers are getting sneakier. using ai to generate reasonable responses, then adding spam links later on to trick people into clicking spam links.

this is not the first time it happened. I've noticed it on several topics before.

is spamming so profitable that it's cost-effective to use AI just to generate spam replies ?!

Answer 5

Lisa
sad but true.

preying on the unwary has always been the rule of the jungle. Spamming and scamming are just modern implementations of it.

with the rise of AI, staying safe just became a lot harder. it can be a great camouflage tool for nefarious purposes because it's been trained on mimicry, pretension, role playing and lots of stolen data...

Answer 6

4. The delta time provided by pygame doesn't match your device refresh rate. This means you implement a new delta time for your game

5. Update collision before rendering. Using verlet integration, store the position before collision and if collision happens, return back to the previous position then start integrating the position with descrete values

Answer 7

I've never used pygame but I can think of many reasons why this is happening... Some are programming error while others aren't

1. The data type matters (because you're using python).. If there's a narrow casting between any of the position for player and platform... Then this issue will appear. Try to find out that there is no implicit narrow cast in your variables.

2. This is based on (1) above but now the screen display density... Pixel location are integers. Run it on another display and compare

3. Wrong collision detection. There is no where in your code that actually shows how collision is detected. For most platform games, it's either you use collision area method or collision pixel method.

Doing collision with pixels is more accurate and efficient.. you simply loop through the pixels of each bodies and check if something as been written in that buffer before. However, this can be laggy so you need to implement this using algorithms like quadtree

Answer 8

Bob_Li good pointing out the colliderect function. If colliderect is custom function, OP should make it accessible for reading

also I think I figure out the likely cause, it's the idea of not using delta time when adding gravity

Answer 9

RuntimeTerror
colliderect is a built-in pygame method. it's not a custom function.

i don't feel the op is ready to handroll custom collision detection yet... 😁

display refresh rate and game clock mismatch is something I have not considered, though...

the OP made no replies at all. so we may never find out if it's resolved or not.

Answer 10

RuntimeTerror
collision detection is handled by

player.collidetect(platform)

it requires a bit of overlap to return true. but the OP also used

player.bottom = platform.top

so it is repositioned after the overlap.

and the rendering is done after all calculations are done, so i would imagine none of the intermediate states are displayed...