I thought about reworking SolidMask definitions to come from their own graphics file instesad of checking transparency on the main graphics as it is done now.
This would have some inherent advantages:
* The engine would not need to lock definition graphics surfaces during game execution. Recently, this has caused SolidMask failure in editor mode when no viewport was open (since there was no valid OpenGL context set)
* Dedicated servers would no longer need to load graphics
* No unnecessery collision masks stored in video memory
And one disadvantage:
* Would break compatibility with old player content that is using SolidMasks. Only the EarthBrick in AngryShovels comes to my mind at the moment.
Related to bugs #300, #590 and 1007.
What do you think about this change?
This would have some inherent advantages:
* The engine would not need to lock definition graphics surfaces during game execution. Recently, this has caused SolidMask failure in editor mode when no viewport was open (since there was no valid OpenGL context set)
* Dedicated servers would no longer need to load graphics
* No unnecessery collision masks stored in video memory
And one disadvantage:
* Would break compatibility with old player content that is using SolidMasks. Only the EarthBrick in AngryShovels comes to my mind at the moment.
Related to bugs #300, #590 and 1007.
What do you think about this change?
Do it!
While you are looking at solidmasks you might also want to look into moving solidmasks and clonks standing on them, moving with non-integer speeds (in pixel / seconds). Then objects tend to fall off...
While you are looking at solidmasks you might also want to look into moving solidmasks and clonks standing on them, moving with non-integer speeds (in pixel / seconds). Then objects tend to fall off...
Do you plan to define the area in such a Solidmask.png Ringwaul described or where?
The defcore and script interface should stay the same, so you can still define source and target area for SolidMasks at runtime. I would just read the pixel data from another surface.
Just loading a different surface would be a trivial change. But I think I should also refactor the code a bit so it won't keep a duplicate of the buffer in every object.
Just loading a different surface would be a trivial change. But I think I should also refactor the code a bit so it won't keep a duplicate of the buffer in every object.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill