Lemma Soft Forums

The subject says it all, really - is there any chance that ATL/The Transform class could be given control over the zorder of a Displayable as well? I'm guessing this would probably be a bit more work than it would at first seem, since zorder isn't one of the listed Position Properties and probably is stored in the scene list of Displayables rather than in the position information, but... well, it would be pretty useful!

(Proximate need: battle engine again, I'm having to resort to some circuitous measures to make sure that fighters - when they move around the battlefield - appear correctly 'in front of' or 'behind' of any fighters they stand next to. It's not impossible to resolve, but it would be a lot cleaner if I could incorporate the zorder into the position-information Transform that I already pass around all over the place instead of having to remember to grab it separately for every call to renpy.show().)

Right now, that's not possible with the current design of Ren'Py. I'll look into changing that at some point, but probably not before the next release.

huh ? I'm wrong or is actually the same issue I discussed in my very first (e-mail back then) contact with PyTom ? I wrote about sprites and foreground/background after noticing that some static images in Moonlight 1.0 can be done with sprites and fg/bg layering whose can have led to smaller grx footprint of the game.....

ahh, memories of when I was much more active in coding.....

Best regards from Italy,
dott. Piergiorgio.

dott.Piergiorgio wrote:huh ? I'm wrong or is actually the same issue I discussed in my very first (e-mail back then) contact with PyTom ? I wrote about sprites and foreground/background after noticing that some static images in Moonlight 1.0 can be done with sprites and fg/bg layering whose can have led to smaller grx footprint of the game.....

Not quite - it's about the situation where you have multiple sprites shown on the same layer, and you want some of them to appear 'in front of' or 'behind' others... presently if you want to programmatically move a sprite from behind to in-front (or vice versa) you have to use the 'zorder' parameter of renpy.show. I'm just saying it would be cool - although I understand it's not necessarily so easy - if you could move a sprite in terms of depth in the same way as you can move it left and right and up and down.

well, I have understand the question my first comp was a Commodore 64, and sprite handling was part & parcel of 64 hacking & coding and the question (image/sprite priority) is fully understanded by me

I guess that when Zposition is implemented we will have a quarrel between Eileen and Lucy for the foreground

Best regards from Italy,
dott. Piergiorgio.