7
« on: 23 May 2009, 03:01 »
Yeah, basically I do things both ways, depending on the specific effect's needs.
For instance, I have a particle system whereby I create an emitter and set up its properties (textures, positions, life, velocities, rotations, etc...) then tell it to start. These are not effected by the issue as they don't rely on Repeatedly_execute_always.
Then in other cases where I need finer real-time control based on changing game variables, I use my sprite/overlay system, and call it from Repeatedly_execute_always.
A crude Example:
// some function to position an effect overlay above an in-game character
SomeScriptFunctionCalledFromRepExecAlwa ys()
{
EFFECTS_SPRITE_SetPosition(SpriteHandle, GameCharacterPosition.X, GameCharacterPosition.Y - 27.0);
EFFECTS_SPRITE_SetChannel(SpriteHandle, EFFECTS_CHANNEL_ID_PRE_AGS_SPRITES);
EFFECTS_SPRITE_AddSpriteToDrawList(SpriteHandle);
}
Your idea of caching whatever was drawn during the last frame is promising. However, I would need some way to detect that a render-loop had occurred without a game-loop happening from inside the DLL, as the draw list is flushed after rendering, so it is clean each frame.
EDIT: Actually, I could probably detect this myself, by checking if any 'EFFECTS_SPRITE_AddSpriteToDrawList()' calls have occurred between the current and last DLL update, and if none have, render the last frame's draw-lists (multiple lists, nested between AGS' different layers), before flushing them out for the next.
EDIT 2: Although, this would stop overlays from disappearing, anything scrolling would still visually stutter.
Another crude example:
// cloud effects
SomeScriptFunctionCalledFromRepExecAlwa ys()
{
CloudScrollOffset_X+= Cloud_Scroll_Speed_X;
CloudScrollOffset_Y+= Cloud_Scroll_Speed_Y;
EFFECTS_SPRITE_SetPosition(CloudSpriteHandle, CloudScrollOffset_X, CloudScrollOffset_Y);
EFFECTS_SPRITE_SetChannel(CloudSpriteHandle, EFFECTS_CHANNEL_ID_POST_AGS_SPRITES);
EFFECTS_SPRITE_AddSpriteToDrawList(CloudSpriteHandle);
}
So in this example, moving the mouse up and down over dialogue options would cause the scrolling overlays to frequently stutter/pause (as opposed to flickering on and off like they do currently). So it would be a slight improvement, yet still very ugly.
Is there a way to force Repeatedly_execute_always to happen regardless of the game-loop being skipped, or would that cause some internal issues with AGS's script processing?
If it would cause problems, is there any way a new script function could be added that I could use instead of repeatedly_execute_always? Something along the lines of 'Execute_before_every_render_loop()' maybe?
Or alternatively, could something be done to stop AGS from rendering a frame when no game loop occurs? So if the game-loop is skipped (for whatever reason), then AGS doesn't do a Clear-display & Render-loop, so the last frame (and any external overlays) remain as-is for that skipped game-loop's frame?
Show Posts
