The first thing I was really curious about is what happens when an object gets obliterated by merging it into the background. The manual seems pretty explicit when it states:
QuoteNOTE: after calling this function, you cannot use the object any more and it is permanently removed from the game.
But what about the my scripts? Will they crash if I try to use an object after merging it? Will it horribly corrupt my computer's memory, frying my RAM (and eggs)? Will it bring "The War on Terror" to a terrifying end?
So many questions...there was only one way to find out.
Huh. It seems that even after the object has been completely and utterly destroyed...I can still access it via the script! I love AGS!
This lead to new ideas. If I can still access the instance of the Object struct...can I do other things too? Can I assign it a new graphic? Can I successfully Tint and Merge the new graphic? Can I remove the previous graphic from the room's background?
The answer is to all these questions is yes. The last seemed the least obvious since AGS doesn't have any specific function for doing so, but it would seem that the methods used by Object.MergeIntoBackground() and the RawDraw functions are the same. In short, I found that if I call RawSaveScreen, Object.MergeIntoBackground(), and then RawRestoreScreen(), the RawRestoreScreen will actually remove the object's graphic from the room bitmap.
Something else I discovered is that although I can use a single object to merge multiple tinted graphics into the room background, any "new" sprites following the object's original merged graphic apparently aren't being "painted" on the screen properly. It seems that they don't actually appear until I move the mouse over them. Unless I have saved and restored the raw state of the screen (permanently saving the previously merged sprites to the room's bitmap).
As for practical use of this knowledge, this could provide a workaround for DynamicSprite tinting but with two major drawbacks:
1. You do in fact lose an object from any room you want to use this functionality in. You can still use the object within the script. Hell, with a bit of scripting you could even make it so it were like the object was still there. But AGS will not handle it as an object.
2. Any sprite you wanted to tint would have to be at the same color depth as the current room background.
If you can live with this though, it would be possible to grab tinted copies of dynamic sprites like this:
// global script
DynamicSprite* dsPlayerGreyscale;
// some function
RawSaveScreen();
RawClearScreen(63519); // 'magic' transparent pink
ViewFrame* vf = Game.GetViewFrame(player.View, player.Loop, player.Frame);
object[0].Graphic = vf.Graphic;
object[0].Tint(100, 100, 100, 100, 100);
object[0].X = 0;
object[0].Y = Game.SpriteHeight[vf.Graphic];
object[0].MergeIntoBackground();
dsPlayerGreyscale = DynamicSprite.CreateFromBackground(GetBackgroundFrame(), 0, 0, Game.SpriteWidth[vf.Graphic], Game.SpriteHeight[vf.Graphic]);
RawRestoreScreen();You could then do whatever you wanted with your tinted sprite. Clearly a DynamicSprite.Tint function would be much more beneficial to this cause...yet this is probably the first workaround I've discovered (actually before using objects I tried using DynamicSprite.CreateFromScreenshot but that requires the screen to actually reflect the changes, i.e., showing the magic pink screen, even if just for a second (or 1/40th of a second :P)). Still I think it could prove useful for someone who really felt they needed it.
As I recall, the Merge function simply first calls RawDrawFrame, and then disables the object. That's all. You can enable it again, or call any other object function.
Really? I didn't think it could be turned back on...I could've sworn I tried that. Oh good. So now as long as the room has at least one object available you can tint DynamicSprites. The sprites would still have to be at the same color depth as the room background, and the room would have to have at least one object...but other than that...
Actually the rate Chris is going at, he'll probably implement some type of tinting support for 2.8! 8) (edit...I knew it! :=)
Hmm...I don't appear to be able to turn it back on. Even explicitly setting "object[0].Visible = true;" seems to be failing.
Well..in any case...this is irrelevant now.