AGS 3.0 Final - it's been a long road

Started by Pumaman, Sun 10/06/2007 18:24:35

Previous topic - Next topic

Pumaman

I've done some research on this and it looks like the AGS Editor might not work on 64-bit Windows at the moment. Is anyone else using a 64-bit version of Windows and managed to run it successfully?

I'll look into it and see if I can fix it for the next beta.

JD

Quote from: VK Dan on Sun 25/11/2007 00:49:58
It looks to me like it can't find AGS.Native.dll. Try re-extracting AGS, and make sure you get all the files. ;)

All files are there, so I guess it's what Chris said. Thanks for looking into it Chris.

Electroshokker

#642
I got this weird crash when clicking near the edge of the screen:



I've just imported a walkbehind mask and moved the room's edges, though I dunno if that's relevant.

EDIT: the bug appears when clicking randomly.

after adding more character animation frames (there were a few missing), the bug doesn't seem to occur anymore. I think it might have something to do with animations.

Pumaman

Quote from: Electroshokker link=topic=31519.msg427453#msg427453after adding more character animation frames (there were a few missing), the bug doesn't seem to occur anymore. I think it might have something to do with animations.

How do you mean? Were there whole loops missing, or did you just randomly add a couple of walking frames?

Def, could you see if RC 1 works on your 64-bit system?

Ghost

#644
Again, when using 800x600: When working on views, clicking on "create new frame" in any loop causes the whole view panel to snap back so that is displays the first loop. That means that, when editing anything from loop 3 on, you "lose focus" and have to scroll down to that loop.

Bug: In save game screenshots,  characters/GUI/Objects do not show up; only the room background. I use the standard method to save those shots (as described in the manual).

IMPORTANT:
If you provide ony the first frame in walking loops, the character doesn't move! This should be altered.

JD

Quote from: Pumaman on Sun 25/11/2007 17:55:17

Def, could you see if RC 1 works on your 64-bit system?


It works. It starts up at least, havn't had time to test it fully but I guess it should be ok. Thanks for the quick fix Chris!

Shane 'ProgZmax' Stevens

QuoteAnd, depending on the image, this effect can range from minor banding in dark areas to fairly extreme banding in images with low contrast. Overall, it's something I'd rather avoid.

Save your images as 16 bit then, Fish! :D


AGS 3 is looking great so far, Chris.  Just needs that old view move into/out of folders and folder deletion chestnut and I'm sold!

Perhaps now I will invest some effort into an alternate dialog editor, or is that something you plan to revamp yourself in the future?  I'd need to know if certain things I have planned are even possible within the editor/engine constraints first, at any rate.

GarageGothic

#647
I've run into a strange problem that I've been trying to troubleshoot, and although it behaves a bit inconsistently, I've narrowed it down to this:

I'm using a GUI as an effect overlay (for rain etc.), and while converting some of my old functions to use the new DrawingSurface routines, I tried applying a DynamicSprite as the GUI background in the repeatedly_execute_always. This works fine, until I bring up other (tried normal as well as pop-up mode) GUIs on the screen. For some reason, this freezes the animating overlay, BUT whenever the newly opened GUI updates in some way (mouseover buttons, updating label text), my animating GUI background is also allowed to update for one frame.

As far as I can tell, the problem is that while the other GUIs are visible the GUI.BackgroundGraphic isn't actually updated, possibly due to some kind of engine optimization, because I pass the same DynamicSprite.Graphic to it every frame. If I pass a random sprite number instead, it updates correctly.

To rule a couple of other things out: The DynamicSprite IS being redrawn every frame, I've confirmed this by RawDrawing the same sprite to the screen within the same function for debug purposes, and the function IS running every frame, since the background RawDrawing updates correctly no matter what GUIs are open (and even if the game is paused).

Edit: I just tested that this is independent of whether the DirectX or Direct3D engine is used.

Edit 2: Blocking events such as Say also freezes the animating GUI.

Edit 3: I found a workaround. Now I'm forcing the GUI to update by changing GUI.BackgroundGraphic to 0 before resetting it to the DynamicSprite.Graphic.

GarageGothic

(Sorry for double posting, but this is another bug (in the editor) totally unrelated to the above, and I didn't want to confuse things)

A minor issue, but if you create custom cursor modes, their events in the room editor's Object Event pane will refer to "hotspots" instead of "objects".

Electroshokker

Quote from: Pumaman on Sun 25/11/2007 17:55:17
Quote from: Electroshokker link=topic=31519.msg427453#msg427453after adding more character animation frames (there were a few missing), the bug doesn't seem to occur anymore. I think it might have something to do with animations.

How do you mean? Were there whole loops missing, or did you just randomly add a couple of walking frames?

I had an empty loop and others with only one frame.

SupSuper

Quote from: Pumaman on Sun 10/06/2007 18:24:35
* Editor plugin API new event BeforeShowContextMenu on the ProjectTree to allow you to intercept context menus and add extra items to them (you must create any extra items using GUIController.CreateMenuCommand method)
I can't seem to get that right. I added an event handler for BeforeShowContextMenu that tries to add a menu with: _editor.GUIController.CreateMenuCommand(evArgs.Component, CONTROL_ID_CONTEXT_MENU_OPTION, "Simple edit");
Which does... nothing. I also tried using AddMenu but that just ends up adding an option to the Editor's main menu. Clearly I'm clueless. :P

And since we've reached RC stage, I think it's time I get picky. The new AGS Editor icon looks awful on my desktop. The old one went up to 48x48px. The new one doesn't. It makes me sad. Why, Chris, why?!? :(
Programmer looking for work

smiley

try this:
Code: ags

MenuCommand mc = _editor.GUIController.CreateMenuCommand(evArgs.Component, CONTROL_ID_CONTEXT_MENU_OPTION, "Simple edit");
evArgs.MenuCommands.Commands.Add(mc);

Pumaman

#652
QuoteAgain, when using 800x600: When working on views, clicking on "create new frame" in any loop causes the whole view panel to snap back so that is displays the first loop. That means that, when editing anything from loop 3 on, you "lose focus" and have to scroll down to that loop.

Ah, this seems to happen when the focus moves from one loop to another. I'll look into it.

QuoteBug: In save game screenshots,  characters/GUI/Objects do not show up; only the room background. I use the standard method to save those shots (as described in the manual).

Are you using DX5 or D3D driver? Does the problem happen with the other driver?

QuoteIf you provide ony the first frame in walking loops, the character doesn't move! This should be altered.

I think this might be design, I'll check into it.

QuoteIt works. It starts up at least, havn't had time to test it fully but I guess it should be ok. Thanks for the quick fix Chris!

Glad to hear it!

Quote
Perhaps now I will invest some effort into an alternate dialog editor, or is that something you plan to revamp yourself in the future?  I'd need to know if certain things I have planned are even possible within the editor/engine constraints first, at any rate.

I'm still not sure what to do with the dialog editor. It is on my re-vamp list but I've no firm plans for it at the moment.

QuoteAs far as I can tell, the problem is that while the other GUIs are visible the GUI.BackgroundGraphic isn't actually updated, possibly due to some kind of engine optimization, because I pass the same DynamicSprite.Graphic to it every frame. If I pass a random sprite number instead, it updates correctly.

This sounds plausible, if you change the image in the dynamic sprite it might well not refresh the GUI... there are probably other similar issues with using dynamic sprites in various places and then changing their content. Anyway, I'll get this one fixed.

QuoteA minor issue, but if you create custom cursor modes, their events in the room editor's Object Event pane will refer to "hotspots" instead of "objects".

I'll look into it.

QuoteI had an empty loop and others with only one frame.

Thanks, I'll see if I can reproduce it.

Quote
can't seem to get that right. I added an event handler for BeforeShowContextMenu that tries to add a menu with: _editor.GUIController.CreateMenuCommand(evArgs.Component, CONTROL_ID_CONTEXT_MENU_OPTION, "Simple edit");
Which does... nothing.

You need to create the command with CreateMenuCommand, but then add it to the Commands collection in the EventArgs, as smiley has demonstrated.

Quotetry this:

MenuCommand mc = _editor.GUIController.CreateMenuCommand(evArgs.Component, CONTROL_ID_CONTEXT_MENU_OPTION, "Simple edit");
evArgs.MenuCommands.Commands.Add(mc);

Be careful here! The component that you supply to CreateMenuCommand will be the component that gets notified when the command is clicked. Thus, for adding your own commands you need to pass your component rather than the one that created the menu.

So the code you might want could be this:

Code: ags

MenuCommand mc = _editor.GUIController.CreateMenuCommand(this, CONTROL_ID_CONTEXT_MENU_OPTION, "Simple edit");
evArgs.MenuCommands.Commands.Add(mc);


depending on which class that code is in.

QuoteAnd since we've reached RC stage, I think it's time I get picky. The new AGS Editor icon looks awful on my desktop. The old one went up to 48x48px. The new one doesn't. It makes me sad. Why, Chris, why?!?

Hehe, I'll look into this one!!

GarageGothic

#653
Quote from: Pumaman on Mon 26/11/2007 23:02:37This sounds plausible, if you change the image in the dynamic sprite it might well not refresh the GUI... there are probably other similar issues with using dynamic sprites in various places and then changing their content. Anyway, I'll get this one fixed.

Thanks, as I said in my edit above, I found the workaround of resetting the GUI.BackgroundGraphic to 0 before setting it to the DynamicSprite.Graphic, and that seems to do the trick, but this behaviour was a bit surprising. Though it's cool to discover that the GUIs are optimized not to update unless any value changes.

A minor thing, which I'm sure nothing can be done about: DynamicSprite.CreateFromScreenshot is horribly slow in windowed mode under the Direct3D drivers. Full screen is not a problem at all, though slightly more sluggish than DirectX mode. But in windowed mode it takes a second and half to open my savegame menu just because it's grabbing a 80x60 thumbnail screenshot.

Edit: The framerate drops by 5-10 fps when I run Direct3D in windowed mode anyway, so maybe it's just my graphics card.

Shane 'ProgZmax' Stevens

#654
QuoteI'm still not sure what to do with the dialog editor. It is on my re-vamp list but I've no firm plans for it at the moment.

To my mind, the best way of handling it would just be to have each dialog topic call a new script with the same functionality as, say, a room script.  That way you could call any of the say commands to handle dialog and do more complex things if you like without ever calling run script (walk, change room, etc).  The scripts would still need to handle return/stop/and goto in some form (it could auto generate a return at the end so as not to break anything I guess?) so I'm not sure how feasible it would be, since to make it all work together the script-only options would probably need to be made into function calls like ddialog.return, ddialog.stop and so on.  The added bonus here, though, would be not having to relay between your global script and the dialog script (dialog_request would be obsolete).

subspark

Oh man there are so many ways to improve the dialog editor. It would be beneficial to start a suggestion thread for the dialog editor at some stage. Your priority list might be extremely flooded right now Chris but I do believe at some point we should all discuss our options for it as a community.

Cheers,
Paul.

monkey0506

#656
Quote from: GarageGothic on Mon 26/11/2007 23:54:01I found the workaround of resetting the GUI.BackgroundGraphic to 0 before setting it to the DynamicSprite.Graphic, and that seems to do the trick, but this behaviour was a bit surprising. Though it's cool to discover that the GUIs are optimized not to update unless any value changes.

Aha! I think I have encountered exactly the same error while working on Beta 3 of my Flashlight module (already released). The way I got around it was by completely destroying the dynamic sprite altogether before rebuilding it and setting the GUI's background to the DynamicSprite.Graphic property. It took me a while to figure out how to get it to start updating properly. :=

Edit: Actually I also set the background graphic to 0 as well. So I deleted the sprite and set the GUI's background to 0. Yes...that made it update. :)

Quote from: monkey_05_06 on Wed 21/11/2007 22:16:38As in the previous example, if I wanted to merge multiple sprites together into a single DynamicSprite which had been created using DynamicSprite.Create(WIDTH, HEIGHT, true) then the alpha channel wouldn't be copied onto the destination image where (it would seem IMO) appropriate.

Actually I've just worked around this by using DynamicSprite.ChangeCanvasSize and then drawing the additional items onto the sprite where applicable instead of drawing everything onto a new sprite.

Ghost

Quote from: Pumaman on Mon 26/11/2007 23:02:37
Are you using DX5 or D3D driver? Does the problem happen with the other driver?

The problem I described happens when using the default DirectDraw5 drivers.
Using Direct3D9 seems to save the GUI at least, but the image's totally screwed (mismatched colours, striped running across screenshot).

Other than that I can report no other issues (apart from those already adressed); RC1 runs smooth and stable on my PC.

Pumaman

QuoteA minor thing, which I'm sure nothing can be done about: DynamicSprite.CreateFromScreenshot is horribly slow in windowed mode under the Direct3D drivers. Full screen is not a problem at all, though slightly more sluggish than DirectX mode. But in windowed mode it takes a second and half to open my savegame menu just because it's grabbing a 80x60 thumbnail screenshot.

This is a "feature" of Direct 3D. Basically, 3D hardware is designed to be very fast for copying data from main memory into the video memory, but is very slow at copying it back. With windowed mode the effect is worse because what actually happens is that it takes a screenshot of your entire desktop (eg. at 1280x1024 resolution) and then trims it down to the size of the game window -- thus the reason why it's slower in windowed mode than full screen.

QuoteTo my mind, the best way of handling it would just be to have each dialog topic call a new script with the same functionality as, say, a room script.

One potential approach would be some sort of  Dialog.DisplayOptions command that would allow the player to select an option, and then return which one was clicked, thus making it easier to implemnet custom dialog scripts.

But, any changes here will not be in 3.0 so could we please leave them for another day.

QuoteThe problem I described happens when using the default DirectDraw5 drivers.
Using Direct3D9 seems to save the GUI at least, but the image's totally screwed (mismatched colours, striped running across screenshot).

I'll look into this.

SupSuper

Quote from: Pumaman on Mon 26/11/2007 23:02:37
Quote
can't seem to get that right. I added an event handler for BeforeShowContextMenu that tries to add a menu with: _editor.GUIController.CreateMenuCommand(evArgs.Component, CONTROL_ID_CONTEXT_MENU_OPTION, "Simple edit");
Which does... nothing.

You need to create the command with CreateMenuCommand, but then add it to the Commands collection in the EventArgs, as smiley has demonstrated.

Quotetry this:

MenuCommand mc = _editor.GUIController.CreateMenuCommand(evArgs.Component, CONTROL_ID_CONTEXT_MENU_OPTION, "Simple edit");
evArgs.MenuCommands.Commands.Add(mc);

Be careful here! The component that you supply to CreateMenuCommand will be the component that gets notified when the command is clicked. Thus, for adding your own commands you need to pass your component rather than the one that created the menu.

So the code you might want could be this:

Code: ags

MenuCommand mc = _editor.GUIController.CreateMenuCommand(this, CONTROL_ID_CONTEXT_MENU_OPTION, "Simple edit");
evArgs.MenuCommands.Commands.Add(mc);


depending on which class that code is in.
Thanks. :)

Some other issues with the plugin API:
- Room scripts don't seem to be reachable through the Scripts class. Doing something like "_editor.CurrentGame.Scripts.GetScriptByFilename("room1.asc")" will bring up an exception.
- Games saved with plugins will bring up warnings if those plugins aren't found, even if said plugins don't save any custom data.
Programmer looking for work

SMF spam blocked by CleanTalk