Running a function BEFORE the screen updates?

[Dr. Scary]

I am making a module that outlines characters(using raw draw) when the mouse hovers over them. I have however run into a cosmetic problem...

When the character is animating or moving the outline is trailing behind the character.
So my question is, is there any way I can run the function before the screen updates to avoid the lag?

[Radiant]

You might try instead using FollowCharacter with the follow_exactly parameter.

[Dr. Scary]

I'm not using the Follow character at all. I RawDraw the outline right on the screen.

[Gilbert]

I think the problem is that the module codes were executed before the game's own scripts, in case the graphics frame were changed after the module codes were executed there would be a problem.
I guess you used repeatedly_execute[_always]() in your module to draw the outlines right?
Try changing that part to some other function which is to be called as late as possible in the game's own script.

For example, call it:
UpdateOutline();

and call it as the last line of your game's global script and see if it helps. This will beat the convnience of the module to do stuff automagically though (and I'm not sure if this helps either).

[Dr. Scary]

That's exactly what I'm doing now and the outline when a character is walking is trailing with about 2px.
I would guess that comes down to about one frame behind.

So I take it that this is near impossible unless AGS itself is altered?
In that case I would like to add a request for an overlay layer I can do RawDraw stuff on.

[SSH]

Its always possible to rawdraw on an overlay

you just do RawSaveScreen, RawBlankScreen (or whatever it is), draw your stuff, grab the area as a dynamic sprite and then create an overlay with the sprite on. Finally, you RawRestoreScreen. See the SpriteFont module for an example.

[Wretched]

You could write a function that took a view, generated dynamic sprites with outlines for all the frames, then changed the view to use the outlined sprites. This way all your processing would be done beforehand. I'll not go into all the messy details as this would require some nifty view graphics management so you can switch the outline on and off instantly. But you would use something like SSH's suggestion to generate the frames.

[SSH]

Wretched's suggestion sounds like a  good idea for your problem, but will take quite a bit of scripting

[Dr. Scary]

It's a brilliant idea, but the load it would put on the cpu... I don't know if I could pull it off on the fly without making the game stall. If I were to pregenerate them I might as well add outlined sprites by hand.

[Wretched]

The point of my suggestion is that you do all the processing beforehand, so there is no hit at all on the cpu, apart from changing all the view/loop/frame graphics value which is minimal. But yeah doing it by hand is simpler but I thought this was going to be a module so anyone can add it to thier characters. How are you generating the outlines anyway? rendering the character 9 (or 4) times around it's position with tint set to outline colour?

[Dr. Scary]

I draw the outline by scanning the block of pixels around the character and RawDraw the outline color on every pixel next to a character pixel.
The problem with this method (besides the lagging) is that a character standing behind the outlined character will overlap the outline.
I guess I have to start over on the module. I plan to expand it to outline hotspots and objects too, but that should be easier.
Wouldn't generating outline views for every character take a big chunk of the memory?

[Wretched]

Isn't that what memory's for?
At worst you'll only be doubling the number of sprites.

[Scorpiorus]

That's exactly what I'm doing now and the outline when a character is walking is trailing with about 2px.
I would guess that comes down to about one frame behind.

I guess a game loop roughly consists of the next phases in the following order:

- run script (repeatedly_execute at least)
- update engine's internal state (such as chars x/y when moving)
- drawing the screen

So, the characters x/y values you're probably using in the rep_exec script will seem outdated (one frame behind as you say), since the engine updates its state (as it seems) after script running but before drawing.

[Dr. Scary]

Yeah, That's what I figured was happening.
I've been thinking of another workaround of that.
If, on MouseOver, I set the character my mouse is over to an invisible view and put the view onto a dummy character that I could assign the frame number to manually. The animation would lag by one frame of what it should be, but the outline would work.
Think that would work?

[Scorpiorus]

I think using a dummy character would be the best approach here. But use Character.FollowCharacter with the special FOLLOW_EXACTLY parameter, as Radiant suggested.

Not only you can set it to draw a dummu character behind this way, but since the engine will take care of updating its position at the same time with an actual character, this method should provide no lag at all!

There is also another special use for this command. You can pass the special value FOLLOW_EXACTLY as the DIST parameter rather than passing a number. If you do this, then CHARID will always remain at exactly the same X and Y co-ordinates as CHARTOFOLLOW. This might be useful for effects such as a temporary halo over the character and so forth.

If you use FOLLOW_EXACTLY, then EAGERNESS has another meaning. If you pass 0, CHARID will be drawn in front of CHARTOFOLLOW; if you pass 1, it will be drawn behind.

See if it works...