AGS 3.0 Final - it's been a long road

[Shane 'ProgZmax' Stevens]

Some nice rawdraw functions would include realtime (manual) scaling and rotation. 

As far as views go it wouldn't really matter if a deleted view left a slot empty, you could always have the engine check for the first empty slot when a new view is created and toss it there, like if you delete view 2 of 6 views and create a new view it would automatically toss the new view into the second slot.  This sort of thing should really be transparent from the user anyway, since view names are all that's really needed to reference views.
Also, is there any reason why you can't make the #'s of objects and such dynamically created/destroyed instead of just numerically bumping up their maximum limits?  If you're going to make sweeping improvements, the best ones I can think of would be getting rid of static limits altogether because it benefits both the makers of small games and people who need a huge amount of things (it would also put an end to requests to have 1 extra hotspot or 10 more inventory items because hell, they can make as many as needed)!

[GarageGothic]

Some nice rawdraw functions would include realtime (manual) scaling and rotation.

I don't understand how this is different from scaling/rotating a DynamicSprite and then RawDrawing it or displaying otherwise? What do you mean by "realtime"?

[subspark]

One small thing that annoys me is when I have the name of a GUI control selected and then hit DEL (not backspace) it deletes the control rather than the text. It would be good if AGS could run a check to see if text in a field is selected first before wiping my object from the screen. 

EDIT: I think its time that views can be flipped horizontally AND vertically. Can this be done, Chris?

Cheers,
Paul.

[monkey0506]

2) Not quite RawDraw, but DynamicSprite.Tint as someone suggested in another thread would be great.

Yes. BTW, nice use of the number 2 for both your second and third points.

Something else that I would actually find useful (although again, not a "RawDraw" function) would be some type of function to increase the "canvas" size of a DynamicSprite. Actually it would probably be even more useful if the function could accept top, left, bottom, and right parameters and pad the image out with X pixels on side Y. Something like DynamicSprite.Pad(int top, int left, int bottom, int right) that would increase the transparent "background" of the sprite. The reason for something like this would of course be to increase the size of the DrawingSurface in case we want to actually draw something outside the sprite's normal area. Uh...it's like the inverse operation of DynamicSprite.Crop?...please don't kill me! It was only a suggestion!

[GarageGothic]

BTW, nice use of the number 2 for both your second and third points.

Well, I thought it might make me seem less demanding

[subspark]

Hehehehe!   

[Charity]

Admittedly, I don't know how useful it would be for anyone or how difficult to implement, but a brainstorm I think worth mentioning:

RawDraw functions for Walkable Areas/Regions/Hotspots/Walk Behinds?

I imagine they would be somewhat unintuitive and of limited use in a program that deals primarily with prerendered backgrounds, but I still think they could produce some really interesting effects, as well as simplify SOME scenarios in which a creator needs to use many small areas that are constantly switched on and off.

And on a tangentially related subject, what about a z-baseline for Walk Behinds(Walk Belows?)?

[WackyWildCard]

I was very excited to see the new Beta release available - so, with great haste, I downloaded and installed it on my Windows XP Home Edition Computer. This Error message and a nasty warning sound erupted:


AGSEditor.exe - Application Error
X The application failed to initialize properly (0xc0000135). Click on OK to terminate the application.

OK


Did I do something wrong? HELP!


WackyWildCard

[LimpingFish]

Do you have Microsoft's .NET Framework 2.0 installed?

[WackyWildCard]

 ???Perhaps it's been awhile that I have not updated my XP

I'll keep you guys updated when I have some time to test it.

[subspark]

And on a tangentially related subject, what about a z-baseline for Walk Behinds(Walk Belows?)?

I like the sound of that. Walk belows? Thats brilliant. In fact I think we need to hand over the overall baseline control to polygons rather than a static straight line. It would surely solve a lot of problems with complex scenes.

AGS would basically push vertices in the Z direction the higher up from the bottom of the viewport you click them in. Then, in a small top down preview window, you could fine-tweak them to suite your background art.

Cheers,
Paul.

[Pumaman]

Again the "Michi" problem: it seems to be a problem with the dialog I will start. Each time the dialog shoud start I get a crash. If I change the global script to start another dialog it will work.

Is there something wrong with my diaolg script?

---------------------------
Adventure Game Studio
---------------------------
An internal error has occurred. Please note down the following information.
If the problem persists, contact Chris Jones.
(ACI version 2.80.948)

Error: Out of memory: failed to allocate -120586240 bytes (at PP=77)

Hmm that's strnage, your script looks fine. Would you be able to upload your game for me to take a look at?

when I import a module script, I think the script name in module information should also be used in the list pane window instead of 'module'.

The name in the list pane is the filename of the .SCM file that you imported it from. I don't see any reason to change this, it means that the script file name will be as intended by the module author.

Would be great if there were an option to show objects while creating walkable areas. If you have objects witch affect to the walkable area, you have to alternately click 'show objects' and 'show walkable areas' all the time to set the area right.

I like that idea, I'll look into it.

I don't know if anyone has asked this before but it would be really nice for AGS 2.8 to be able to combine the lighting amount with color tinting for regions. This makes a lot of sense particularly if your game is set in dark moody places like mine. I use a lot of greens and blues and I'm simply desperate to make the light color affect the character along with the light amount without having to use different character sprites for each room. Can we unify this system, please?

I'm not really sure why regions don't allow you to specify the light level, since you can do it with ambient tints, etc. However, this probably isn't something I'll do for 2.8 since I want to try and release it sooner rather than later.

1) Copying the transparency map (either single color or alpha channel) from an existing sprite to a DynamicSprite of the same size. To support alpha channels, it would of course be necessary for DynamicSprites not to automatically remove the alpha channel (but this should probably be an optional, since that also has it's uses).
2) Not quite RawDraw, but DynamicSprite.Tint as someone suggested in another thread would be great.

Interesting ideas, I'll look into these.

3) It would also be great to be able to set linewidth for the RawDraw routines to only draw a single pixel in hi-res mode. Currently I use all kinds of workarounds (drawing double scale, then resizing) for this.

In the next beta I'm adding a UseHighResCoordinates property to the DrawingSurface, and a Thickness parameter to DrawLine, which should allow you to do this easily.

I tried to implement this in my shadow module, but it turned out to be too slow, so I do support an engine function to do it. I think a geometrical deformation of a rectangle to a shape where you specify new coordinates for each of the four corners (similar to Photoshop's 'Distort' transformation) should do the trick.

I'm not sure about this one, but I'll have a think. It won't make it into 2.8.

Also, is there any reason why you can't make the #'s of objects and such dynamically created/destroyed instead of just numerically bumping up their maximum limits?

This depends on the type of thing that we're talking about. I've already removed the limits on views and GUIs because it was relatively simply to do; however with room-specific things like objects there is more to consider, such as how the data is stored when you leave the room. It's not impossible, just more complex (and potentially slower for saving/restoring games) to have a truly dynamic memory allocation here.

One small thing that annoys me is when I have the name of a GUI control selected and then hit DEL (not backspace) it deletes the control rather than the text

Hehe oh yeah that is annoying, I'll fix it.

I think its time that views can be flipped horizontally AND vertically.

For what purpose would you use a top-to-bottom flip? The left-to-right flip feature is there because of the very common use of having identical left and right walking frames... but this doesn't really apply to up/down frames.

Something else that I would actually find useful (although again, not a "RawDraw" function) would be some type of function to increase the "canvas" size of a DynamicSprite.

Interesting idea, I'll look into it.

RawDraw functions for Walkable Areas/Regions/Hotspots/Walk Behinds?

I imagine they would be somewhat unintuitive and of limited use in a program that deals primarily with prerendered backgrounds, but I still think they could produce some really interesting effects, as well as simplify SOME scenarios in which a creator needs to use many small areas that are constantly switched on and off.

Hmm, I'm not sure about this. Technically it could be possible, would anyone find this useful?

[mchammer]

I got this when set (by accident) gui background image number to 44444:

Error: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Version: AGS 2.8.0.11

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at drawGUIAt(Int32 , Int32 , Int32 , Int32 , Int32 , Int32 , Int32 , Int32 )
   at drawGUI(Int32 hdc, Int32 x, Int32 y, GUI guiObj, Int32 scaleFactor, Int32 selectedControl)
   at AGS.Native.NativeMethods.DrawGUI(Int32 hDC, Int32 x, Int32 y, GUI gui, Int32 scaleFactor, Int32 selectedControl)
   at AGS.Editor.GUIEditor.bgPanel_Paint(Object sender, PaintEventArgs e)
   at System.Windows.Forms.Control.OnPaint(PaintEventArgs e)
   at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs)
   at System.Windows.Forms.Control.WmPaint(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[SupSuper]

Issues with AGS 2.8: Change of behavior in "interaction > code" conversion.

function room_AfterFadeIn()
{
dialog[0].Start();
player.ChangeRoom(2, -10, 190);
}

As interaction (2.72), this was the behavior:
- Game runs dialog
- After dialog finishes, game switches rooms and changes character position

As the now-converted code (2.8), this is the new behavior:
- Game changes character position
- Game runs dialog
- After dialog finishes, game switches rooms

Issues with DirectDraw mode: Room fades don't match the room resolution (in my case, the rooms switch from 320*200 to 320*240 while fading)

Issues with Direct3D mode: 320*200 won't work on it:

---------------------------
Adventure Game Studio
---------------------------
There was a problem initializing graphics mode 320 x 200 (16-bit).
(Problem: 'Failed to create Direct3D Device: 0x8876086A')
Try to correct the problem, or seek help from the AGS homepage.

Possible causes:
* your graphics card drivers do not support this resolution. Run the game setup program and try the other resolution.
* the graphics filter you have selected does not work. Try another filter.
---------------------------
OK   
---------------------------

[Pumaman]

I got this when set (by accident) gui background image number to 44444:

Hmm that's quite bad, I'll see if I can handle that better.

As interaction (2.72), this was the behavior:
- Game runs dialog
- After dialog finishes, game switches rooms and changes character position

As the now-converted code (2.8), this is the new behavior:
- Game changes character position
- Game runs dialog
- After dialog finishes, game switches rooms

It's a good point, but realistically I'm not sure if there's anything that can be done about it. Perhaps it just needs to be made clear in the Upgrading to 3.0 guide to watch out for situations like this.

Room fades don't match the room resolution (in my case, the rooms switch from 320*200 to 320*240 while fading)

Hmm, are you running in letterbox mode?

Issues with Direct3D mode: 320*200 won't work on it:

Looks like this is a limitation of your graphics drivers that they don't support 320x200 with D3D. I don't think it's a bug in AGS.


Anyway, beta 12 is now up. I've now renamed it from 2.8 to 3.0, because I think this is as close as we're ever going to get to a full rewrite, and the new editor and D3D engine are quite good justification for making the leap. And yes, I know the splash screen still says "2.8 beta version", but that'll be gone before long

I think I've fixed that crash that people were getting occasionally when loading a room, please let me know if you get it again with beta 12.

[monkey0506]

Man Chris you're brilliant. DynamicSprite tinting and canvas resizing! I love you. And I have to go to work. Hell!!!

But first I want to take a look around the new manual.

Oh...BTW...I like the "3.0" change. I've always been a bit confused about the history, but this is the third official complete editor revision isn't it?

Love the changes. Just curious though...how feasible might it be to implement some properties like Game.CursorModeCount and Game.FontCount? I would find properties like this rather useful. I was also wondering if we might find UseHighResCoordinates properties available in other places as well.

[khnum]

I'm pretty sure this has been asked before, but there's some chance to implement antialias on alpha blended images with D3D?

[Pumaman]

how feasible might it be to implement some properties like Game.CursorModeCount and Game.FontCount? I would find properties like this rather useful. I was also wondering if we might find UseHighResCoordinates properties available in other places as well.

CursorModeCount and FontCount would be very easy to add, I don't think anyone's asked for them before.

As for UseHighResCoordinates, the DrawingSurface provides a convenient separate place to implement this as a trial. If it proves useful, then I can certainly look into expanding it further.

I'm pretty sure this has been asked before, but there's some chance to implement antialias on alpha blended images with D3D?

This should already work, if you tick the "Smooth scaled sprites" option in Setup when using the D3D driver.

[GarageGothic]

Thanks for the great addition. One small request:

*DynamicSprite.CreateFromExistingSprite now preserves alpha channel

Could it please be made optional whether to keep or remove the alpha channel (with an optional bool at the end of the function perhaps)? I need to use transparency on shadows created from character sprites, and anti-aliased sprites don't support transparency.

[Shane 'ProgZmax' Stevens]

It's not impossible, just more complex (and potentially slower for saving/restoring games) to have a truly dynamic memory allocation here.

I'm not sure I agree; in fact, for those who use fewer than the current preset limits it could actually be faster and have a smaller runtime size, and for those who need more it's there without the hassle of you increasing the limits every so often.  I'm sure people with a massive number of objects/hotspots in a room would encounter some performance issues, but then they should already know what they're getting into with that, right?  The way I see it there are only benefits -- both to you and to the users of ags -- to doing away with static limits.  People who construct a tiny game that uses very few resources will compile to a smaller size (it might not be a massive difference but it will be there) and those who need more than x objects for, say, one specific room have it if necessary, with the added bonus of you only needing to implement it once .  You could, naturally, suggest some upper limit for reasonable gameplay in the help file for the objects/hotspots/everything else.  Just a thought!