Quote:
Originally Posted by LeCaravage
During ingame, depending of the sprite coordinates we get the tile code under him.
|
Do you take the tile code under the bottom-left or bottom-right sprite-edge? Or from the middle?
Quote:
|
If the code attribute allows the sprite to walk on this tile, we use another table. We access this table using as index the tile attribute + the lower 4 bits of your sprite x coordinates (4 bits for a 16xH pixels tile size, 3 bits/8xH size etc...). This table will return you a #dy signed number . This #dy is to add to your sprite y. So the sprite sticks to any tiles at any angle of the slope.
|
When falling into such a sloped tile, does it immediately stick to the surface when touching it? This could mean an abrupt movement by #dy=15 in the worst case?
What happens when moving from a plain tile into a sloped tile from the side? When #dy is 0 on the side you move in, it should probably block movement, but not when #dy is 15, because it has nearly the same level as you are currently on...?
Quote:
|
On the point of backbuffer, I'm not sure I used the right word, I simply wanted to say I use 2 screens, which I flip every time the ingame loop is finished.
|
Ah, ok! You just wanted to say you are using double-buffering (to avoid flicker while updating)!
Quote:
|
I used this method because I wanted to use rawblit bobs
|
What are "rawblit bobs"?
BTW, did you consider using interleaved BOBs and planes, or are you blitting plane by plane?