Messages

Okie dokie.

Any plans to change the sprite tinting to not require S1.4?

As this means anything using D3D (which some plugins will require, mine for instance) will simply not work on rather a lot of laptops.

[There was a problem initializing graphics mode 800 x 600 (32-bit).(Problem: 'Graphics card does not support Pixel Shader 1.4')Try to correct the problem, or seek help from AGS homepage.]

Hi.

We are getting some error reports from people trying to play TGP (mainly on laptops) with D3D enabled.

The error is:


There was a problem initializing graphics mode 800 x 600 (32-bit).
(Problem: 'Graphics card does not support Pixel Shader 1.4')
Try to correct the problem, or seek help from AGS homepage.


Is there a specific need for shader 1.4 support? As most cards support shader 1.1 and this could be making any AGS game fail to work with D3D on lots of older cards. Cards which should be able to handle AGS/TGP just fine.

Strangely, this error was generated by a laptop with shader 2.0 support.

Cheers,
Nick

I found the special effects were very snazzy.

YAY! Thanks!

No, my system can only _safely_ work for caching one frame.

I have to flush it after one re-draw, otherwise things would persist forever even if they are meant to have gone.

IE, the way I am doing it internally, I can't be sure why no sprites were added. It could be because a Game-Loop was skipped, but it could also be because a game-loop occurred that was not supposed to draw any effect sprites.

I think just to be on the safe side, I am going to add that EFFECTS_SPRITE_NewGameLoop function.

Cheers for your input.

Another thought just occurred to me.

Would there be any instances whereby multiple render loops happen without a game loop occurring?

For instance, could the changing of text selection on a dialogue menu take 2,3,X amount of frames on a particularly slow PC?

Because if so, then your suggestion of having a flush-call at the start of RepExecAlways would be a more appropriate solution, as any effect-overlays would continually persist until the next true game loop. (Whereas my current solution will only keep things cached for one extra frame.)

But if one is the maximum frame skip then I will stick with what I have, as it needs no extra calls, purely for the sake of simplicity for the end user.

Perhaps the easiest thing is to add some sort of function like

EFFECTS_SPRITE_NewGameLoop

that your script calls from the start of rep_exec_always, which clears the draw list. That way, if no game loop occurs, the draw list will not get wiped.

I have done something that has the same effect as that without the need for a new function call. Basically if no calls to EFFECTS_SPRITE_AddToDrawList happen between two DLL updates, it re-renders the previous draw list and then flushes it. Also the first call to EFFECTS_SPRITE_AddToDrawList in any given frame, will flush the old lists before adding the new object, to stop things from being rendered twice.

It's working nicely so I am marking this as solved.

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
   SomeScriptFunctionCalledFromRepExecAlways()
   {
        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
   SomeScriptFunctionCalledFromRepExecAlways()
   {
        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?

Gotcha.

So is this considered to be a bug, or correct behaviour?

As it is, it makes it impossible to rely on it for doing any external drawing calls, as they will glitch when this occurs.

Hi.

I've done some more investigating into this, and it turns out that the DLLs are in fact being called every-frame.

However, the current room's repeatedly_execute_always() function is the thing that is being skipped (for a single frame) when new text is highlighted on a set of dialogue options.

Is this the expected behaviour or should repeatedly_execute_always never be blocked/skipped?

Nice one. Thanks.

Hello.

Just a polite bump to ask if you have had a chance to look at this before it slides off the screen.
It's been very sunny recently, so this issue is probably way low down on your priority list right now. (I know it would be a triviality on mine.)

Thanks.

Another possible culprit has just occurred to me. Would there be any new/different render-states set on the frame that the highlighted text changes colour? Or maybe some kind of stencil or mask?

If so, I wonder if the effects/textures I am rendering are being masked for a frame or something like that.

I forgot to mention in my previous post that "Run game loops while dialog options are displayed" is already set to TRUE.

With it set to FALSE, the DLL is not called for the whole duration of the dialogue, as you would expect. However, with it set to TRUE, the DLL fails to be called at the instant you highlight new text. Causing it to flicker when you move over different dialogue options.

Hi.

I am having a slight problem with DLL calls.

For the most part my DLL is successfully called every frame, however there are instances where it seems that on certain frames, DLL's are not called by the game/AGS-Engine.

This appears to happen when different dialogue options are highlighted with the mouse.

EG: When the user has a set of dialogue choices, moving the cursor over them causes them to highlight/change-colour. At this very instant it seems that DLLs are not called for one frame.

This is causing the Direct3D visual effects that I am overlaying to not be rendered during that frame, so they briefly disappear.

This also happens for one frame when a conversation is initiated. So when clicking on a character with a speech-bubble icon, I get a single frame flash of my effects not being rendered.

Specifically, the following events do not occur during the frame in question:

AGSE_PRESCREENDRAW
AGSE_PREGUIDRAW
AGSE_POSTSCREENDRAW

It is probable that no events are passed to the DLL during that frame, although these are the ones I am using to know when to render specific layers of my effects.

Are there any known workarounds for this?

Or maybe something I can do to ensure that the events are passed to my DLL every-frame, regardless of any special states that the AGS-Engine might be processing, which would normally cause the DLL-events to be skipped?

Cheers,
Nick

Hi, Gilbert.

Yeah, I still get the same issue (unable to import *.asc/*.ash scripts) with the very latest build:

AGS Editor .NET (Build 3.1.0.60)
v3.1, November 2008

Hi there.

I have created some scripts that I wish to use in another project, however the import-script facility only allows for the importing of the old-style Script-modules (*.scm) files.

The scripts I wish to import are *.ash & *.asc, but the import dialogue won't allow this. Even if I force the dialogue to display and load *.ash/*.asc files it reports a load error, as it wants *.scm files.

The create-new-scripts option will generate blank *.asc/*.ash files, whilst the import-script option only allows *.scm files. Also, the help documentation states that *.scm is the old way, so I am guessing that the code for the script-importer-dialogue requires an update to accept the newer *.asc/*.ash files.

I can work around this by creating new blank scripts within the second project, and then copy-pasting the code into them, but I thought that you might want to know that the script-importer is a bit broke (or rather, is out-of-sync with the new *.asc/*.ash way of working). However this work-around is getting very fiddly/cumbersome, as I am working over-the-net with somebody else. We are juggling quite a lot of scripts now and this is starting to make our script-sharing get a little messy/complicated.

I believe that I am using the latest Build (3.0.2.44 - June 2008).

Cheers,
Nick

Great stuff, download working fine.

Thanks!


I haven't had chance to rebuild with this, but if the eventhook values are the same then it's strange that my bits are all being drawn behind the sprites, as I was using D3D with the 2.7Beta.  Have the Z-depths of the Backround/Sprites/GUI rendering been changed since 2.7Beta? If so, what Z values should I now be using to interweave between them? (all of my layers are rendered at z-0, maybe this is a problem if you are using different/higher z values for each of your render stages?)


EDIT: I have now rebuilt everything using the latest DLL template as the framework. Everything works perfectly!

Many thanks!

Through some weird glitch, if you right click the link and save file, you get the error message itself zipped under the file name "agsplugin119.zip"! Open the zip file in notepad and you'll see what I mean.

How odd. I've never seen that happen before.

Yeah, I had good dig around but couldn't find it anywhere.

In the meantime, does anybody know where else I may be able to find a working version of the latest plugin-template?

I have had a search about on the net but couldn't find one anywhere.

Cheers,
Nick

[AGSE_PREGUIDRAW]

Hi

The draw order of some things seems to have changed since V2.7 (or I made some kind of error back then, and have only just spotted it when using latest AGS3.02.44 build. Or maybe the DLL template project I was using with 2.7 is now out of sync with the latest AGS build (integer constants for Pre/Post/Sprite/Gui draw interupts/events have possibly changed values since then)?).

All of my 'bits' now get rendered before the game-sprites do, so I am assuming that the following values defined in the header file:

AGSE_PREGUIDRAW
&
AGSE_POSTSCREENDRAW

Have since changed to use new values, and I am now using an out-of-date template, which is no longer compatible with AGS3.02.44.



So to rectify this and update my stuff to be compatible with the latest AGS release, I am trying to grab the latest Plug-in template project and rebuild all of my DLL code into that. However the file can't be extracted and reports a corruption error.
(Error: "The archive is either an unkown format or the file is damaged").

file : http://www.adventuregamestudio.co.uk/agsplugin119.zip

EDIT - Some extra info: I have tried with WinZip, WinRAR & 7-Zip. (All to no avail.)

Maybe it's just the server having a bad day.