Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sorting with sprites on same y coord is incorrect #47

Open
bitcraft opened this issue Sep 2, 2021 · 6 comments
Open

Sorting with sprites on same y coord is incorrect #47

bitcraft opened this issue Sep 2, 2021 · 6 comments

Comments

@bitcraft
Copy link
Owner

bitcraft commented Sep 2, 2021

image
probably not a common situation, but the stump tiles are aligned with the sprite on the bottom edge. when sorted, their b (bottom) values are the same, so then they are sorted by the x value, so the stump on the right is drawn after the sprite.

@javier5109
Copy link

Is it possible to make this intended behavior? I am trying to render the tile that the character is on, after the character so that they look like they are inside the tile. ( Like for grass). I am unsure if that's the way games do it or they have some other method.

What i am thinking is that, the pyscroll group can take layer names to render the characters after them only if they are on them.

I saw that you have sprite damage in the files, not sure if my request is going to be done that way.

@ravenironwing
Copy link

ravenironwing commented Nov 29, 2021 via email

@javier5109
Copy link

Sorry, i wasn't clear enough. I was thinking conditional rendering for tiles on the same level as the player. If they collide then it is rendered after, else it is rendered before.
Example down below. Where the player rendered based on the tile it is on. I assumed that that this bug could be used to figure out where the player is and render conditionally.

I am working on the assumption that this is how u do the rendering for grass and stuff. I attempted to do the conditional rendering myself with other sprites but I don't know how to get the world offset and screen transformation data from buffered renderer

Screenshot_20211129-142445

@ravenironwing
Copy link

ravenironwing commented Nov 29, 2021 via email

@bitcraft
Copy link
Owner Author

bitcraft commented Dec 1, 2021

i've wrestled with how to do this a bit and currently, the sprite will always be over all the tiles of the layer that it shares tiles with. there is a "tall_sprites" feature, which needs more work, but the idea is that:

  • if a sprite and a tile share the same layer, draw the sprite or tile having the lowest bottom value (the lower part of the surface)

it can be slightly configured using the "tall_sprites" value, but its not really designed for general use -- the only game that uses it is Tuxemon, and that game has a pretty specific way of rendering tiles. for rendering the player in the grass, there is a layer of half-grass tiles, and the tall_sprites value determines when to draw the player sprite over the grass.

image

thinking about stardew valley, i don't think that this is something for pyscroll to deal with (though i might change my mind about it). pyscroll is really meant to draw the background and forground layers of a game, but not the objects. the tall grass and crops in SDV would be sprites in a game. for pyscroll, they would be passed into the renderer with layers, and pyscroll could render them as you see it, being in the crops/grass, etc.

it gets a bit more complicated if you were to put the grass tiles in Tiled, but if you were to treat them as game sprites, then i don't think there would be a problem with rendering. feel free to try it out or ask questions..... putting more features into this kind of render puts pyscroll more into "rendering system" rather than being a "tilemap renderer", but i think that eventually i would like to support it,

@bitcraft
Copy link
Owner Author

bitcraft commented Dec 1, 2021

btw, layers for sprites are supported using the method with pygame groups. you can set Sprite.layer (ie hero.layer = 2), and the sprite will be rendered over layer 2, but under layer 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants