ClementSparrow / Pattern-Script

Open Source HTML5 Game Engine based on PuzzleScript
20 stars 2 forks source link

not all of a sprite showing #69

Closed Pool-E closed 12 months ago

Pool-E commented 1 year ago

in this game i'm making (experimenting with 3d looks):

title Simple Block Pushing Game author David Skinner homepage www.puzzlescript.net

======== OBJECTS

Background LIGHTGREEN GREEN 11111 01111 11101 11111 10111

Target DarkBlue ..... .000. .0.0. .000. .....

Wall BROWN green lightgreen 0000000 0000000 0000000 0000000 0000000 0000000

Player Black Orange White Blue .000. .111. 22222 .333. .3.3.

Crate Orange Yellow 00000 0...0 0...0 0...0 00000

======= LEGEND

. = Background

= Wall

P = Player

======= SOUNDS

Crate MOVE 36772507

================ COLLISIONLAYERS

Background Target Player, Wall, Crate

====== RULES

[ > Player | Crate ] -> [ > Player | > Crate ]

============== WINCONDITIONS

All Target on Crate

======= LEVELS

..

.O#..

..

@P..

..*.

..

..

....

.#P.

.*@.

.O@.

....

the walls are weird and only show the above spots

david-pfx commented 1 year ago

Wall is bigger and will overlap. Is that intended? Better to ask on Discord: https://discord.com/channels/473538592896188446/603626559189942294

Pool-E commented 1 year ago

Wall is bigger and will overlap. Is that intended? Better to ask on Discord: https://discord.com/channels/473538592896188446/603626559189942294

i just wanted to make a 3d effect

Pool-E commented 1 year ago

Wall is bigger and will overlap. Is that intended? Better to ask on Discord: https://discord.com/channels/473538592896188446/603626559189942294

i wanted to make a kinda 3d, and there aren't any text channels in the server

ClementSparrow commented 12 months ago

I think it works as expected: the wall sprites are 7x6 and the sprite_size is 5x5, so the wall sprites overlap the cells to their right by two pixels and the cells above them by 1 pixel. Because the drawing order is first left-to-right then top-to-bottom, the background of the cells to the right of a wall will be drawn over the wall sprite and only two pixels of the line overlapping the cell above will be visible. You need either to use a transparent background or put the background layer in a separate layer group (see the documentation) so that all the backgrounds are drawn before the walls.

david-pfx commented 12 months ago

I'm sure you're right and I was aware of this 'unexpected feature'. I think it is probably a mistake for the default behaviour to be that the background overwrites the edges of any sprite larger than the defined sprite size. That just seems wrong. Expected behaviour would be that objects draw layer by layer, from back to front, within layer group. I plan to experiment.

ClementSparrow commented 12 months ago

Expected behaviour would be that objects draw layer by layer, from back to front, within layer group.

And that's exactly how they work. But yeah, Background should probably be in its own layer group by default. I have not done it because if for some reason that's not the behavior you want, you can't change it. Also because I don't think a background should be mandatory, but I'm not sure about that.

david-pfx commented 12 months ago

No they don't. They draw layer by layer within cell, whereas expected behaviour is to draw the entire layer before moving to the next, so that sprites in front always overwrite those behind. A reasonable solution might be to preserve this behaviour for any group that does not specify a render order, and only draw cell-wise in layers where the order is specified.

ClementSparrow commented 12 months ago

do your experiments, you will understand why it's done like that. Anyway, we need a way to tell "draw these sprites in that order in a cell before moving to the next cell" AND "draw these sprites in all the cells before drawing these other sprites". The former is accomplished with normal layers and is the default ; the latter is accomplished by layer groups that have to be marked explicitly in the collision layers section. You may think the roles of layers and layer groups should be reversed, with layer groups being the default, but 1) it would make no sense to me notation-wise, 2) this is not how drawing apps that support hierarchies of layers work. If you're an artist rather than a programmer, it makes more sense this way.