search

solarus-games / solarus

This repository was moved to GitLab: https://gitlab.com/solarus-games/solarus
http://www.solarus-games.org
Other
712 stars 134 forks source link

Hardware surfaces are cleared after rendering #395

Closed vlag closed 10 years ago

vlag commented 10 years ago

There is a last difference between software and hardware solarus's surface : if we draw on a hardware surface which already has been renderered, all previous draw are cleared.

This was done because we can't predict when a previous drawed surface needs to be removed from the subsurface tree, but now that we have a Surface::clear() method accessible to lua, maybe we can let quest makers explicitly clear surfaces on their own (and clear "engine specific surfaces" every frames).

This is a little more error-prone, because the quest maker have to know when clearing a surface is needed or not, but it allow to have the exact same behavior between software and hardware surface on lua side (and allow to construct a sprite during more than one loop, without have to fully rebuild it).

This is just a suggestion, close the issue if the difference of behavior is negligible.

christopho commented 10 years ago

This difference of behavior is a problem. But forcing users to make surface:clear() is not an appropriate solution. I'm not sure what to do.

christopho commented 10 years ago

Maybe we should just keep the current implementation and clearly document in the C++ code what happens with hardware surfaces. After all, hardware surfaces are only for our internal low-level optimizations, and not for the user drawings, so the difference of behavior might be okay.

vlag commented 10 years ago

You're right, if all surfaces accessible to lua are software destination, the hardware surface's behavior shouldn't be significant. Clear them every frames shouldn't even be painful.

But in this case, I think it is really important that hardware surface are not accesible on lua side and be sure to never draw a hardware surface on a software destination, so it might be better to set the software destination by default and explicitely deactivate it on "engine-specific surfaces".

christopho commented 10 years ago

Okay. I keep the bug open then. Note that some hardware surfaces are accessible to Lua (like the screen). If a Lua script tries to draw it onto a software one, Lua raises a proper error so we are safe.

christopho commented 10 years ago

Done. Thanks for your feedback.