AGS 3.3.0 Release Candidate

[Crimson Wizard]

Yeah, I just found it odd that it only started popping up this error message after I put this newest acwin.exe in my AGS directory. I don't recall Windows ever complaining like this about previous versions that I downloaded separately from the web.

I don't know how this works in detail. I just made a test with original 3.2.1 acwin.exe, uploaded it to the file hosting and downloaded back. And it gave same warning on start. I think Windows marks files somehow when they are downloaded like that. Perhaps it does not find them suspicious when they are in larger packages... just a random thought.

[SpeechCenter]

It depends on the software that adds the file, any file can be marked with a different zone which will pop up the security warning if attempting to open it.
See this very thorough answer here http://superuser.com/questions/323933/how-does-windows-security-warning-do-you-want-to-run-this-file-work

[tzachs]

Hmmm and another fatal editor crash to report. This happened when I tried to copy and paste some text from the forum here into an AGS room script.

Yeah, it happened to me too once.
The next version will catch this error so it wouldn't crash the editor.

[Crimson Wizard]

And script window flicker - it is gone! Wooo!

[selmiak]

[AGD2]

Just got this one when I used CTRL+F5 to test the game, and clicked away from AGS to another window while it was compiling (I use a dual monitor setup). I've never seen this happen before, but it seemed to interrupt the compile process somehow, and then returned to the editor with this crash:

Error: The operation was canceled by the user
Version: AGS 3.3.0.1146

System.Exception: The operation was canceled by the user ---> System.ComponentModel.Win32Exception: The operation was canceled by the user
   at AGS.Editor.Tasks.RunEXEFile(String exeName, String parameter, Boolean raiseEventOnExit)
   at AGS.Editor.Tasks.TestGame(Boolean withDebugger)
   at AGS.Editor.InteractiveTasks.TestGame(Boolean withDebugger)
   --- End of inner exception stack trace ---
   at AGS.Editor.InteractiveTasks.TestGame(Boolean withDebugger)
   at AGS.Editor.Components.BuildCommandsComponent.TestGame(Boolean withDebugger)
   at AGS.Editor.Components.BuildCommandsComponent.CommandClick(String controlID)
   at AGS.Editor.GUIController._mainForm_OnMenuClick(String menuItemID)
   at AGS.Editor.MainMenuManager.MenuEventHandler(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripMenuItem.ProcessCmdKey(Message& m, Keys keyData)
   at System.Windows.Forms.ToolStripManager.ProcessShortcut(Message& m, Keys shortcut)
   at System.Windows.Forms.ToolStripManager.ProcessCmdKey(Message& m, Keys keyData)
   at System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Form.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Form.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
   at System.Windows.Forms.Control.PreProcessMessage(Message& msg)
   at System.Windows.Forms.Control.PreProcessControlMessageInternal(Control target, Message& msg)
   at System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(MSG& msg)

[Radiant]

There's a graphical glitch with the Nearest Neighbor filter: it is not applied to characters. If using (e.g.) the 4x NN filter, then each pixel in the game is displayed as a 4x4 block of pixels on the screen. However, characters if zoomed use the full resolution, not 4x4 blocks. It appears the graphical operations are performed in the wrong order: the character is enlarged to 400% first, then reduced from there to account for scaling; whereas it should be the other way around; this discrepancy simply looks odd, as if the characters use a higher resolution than the backgrounds. I haven't checked, but this likely also applies to objects.

[Radiant]

Another graphical glitch: if a GUI button is set to "no clipping" then images can indeed appear bigger than the button itself. However, text will not. When using truetype fonts that are slightly bigger than the button, this looks fine in the editor but is clipped in the game.

Furthermore, vertical alignment of truetype fonts on a button is off: if the the text alignment of a GUI button is set to 'bottom middle', then it is possible for 'tall' letters like the J to extend a few pixels below the bottom of the button (meaning they are clipped, as per above). It appears that vertical alignment looks at the bottom of standard letters like 'a' and 'o'.

[Crimson Wizard]

Another graphical glitch: if a GUI button is set to "no clipping" then images can indeed appear bigger than the button itself. However, text will not.

That's not a glitch, that's a proper behavior; like stated in manual the ClipImage property only control whether image is clipped or not:

bool Button.ClipImage;

Gets/sets whether the button clips its image to the button boundaries.
For example, if the button is sized 30x30, but its Graphic is a 50x50 image, then this property controls whether the image is allowed to spill over the edge of the button.

[selmiak]

i know feature requests are over, but imho this is a really quick fix.
When I have a 320x200 game in ags 3.2.1 and make a new gui the new gui is always only 300 pixels wide on default. This is really annoying. I haven't checked on higher resolutions and afaik there is no way to set the default new gui size in general settings. Just let the new gui width default to 320px and not 300px width. I came to the conclusion I use fullscreen Guis and non fullscreen guis in almost equal amounts. So 50% of the guis I create are fullscreen (fullscreen menu screens, colored guis for fading effects) while I have to change the width for all various widths of non fullscreen guis anyways, and none of them ended up being 300 px wide. Why 300 and not 320 anyways?

[AGD2]

There's a graphical glitch with the Nearest Neighbor filter: it is not applied to characters. If using (e.g.) the 4x NN filter, then each pixel in the game is displayed as a 4x4 block of pixels on the screen. However, characters if zoomed use the full resolution, not 4x4 blocks. It appears the graphical operations are performed in the wrong order: the character is enlarged to 400% first, then reduced from there to account for scaling; whereas it should be the other way around; this discrepancy simply looks odd, as if the characters use a higher resolution than the backgrounds. I haven't checked, but this likely also applies to objects.

Some games use this 'feature' in conjunction with a NN filter as a way to display higher resolution characters while keeping the game backgrounds at 640x400 (we used this trick in both Al Emmo and Mage's Initiation). Disabling it would destroy the pixel artwork in the latter game. So, if this is going to be 'fixed', it would be necessary to make it an optional setting for any games that rely on the current behaviour.

[Radiant]

Very well. In that case, please ignore that suggestion for 3.3.0 and consider it as an optional setting for 3.4.0 instead.

Come to think of it, the vertical font alignment I mentioned would also break backwards compatibility if changed, so please also consider some optional setting for 3.4.0.

[Scavenger]

Very well. In that case, please ignore that suggestion for 3.3.0 and consider it as an optional setting for 3.4.0 instead.

But it is a bug - I can't count how many times it's irked me playing a game and having the character explode into a million subpixels every time they scale. I don't think it looks good at all. I guess there could be an option in the config file if people really want it (hirescharacters=true?), but the regular operation of the nearest neighbour filter shouldn't do things like that.

[Crimson Wizard]

Very well. In that case, please ignore that suggestion for 3.3.0 and consider it as an optional setting for 3.4.0 instead.

But it is a bug - I can't count how many times it's irked me playing a game and having the character explode into a million subpixels every time they scale. I don't think it looks good at all. I guess there could be an option in the config file if people really want it (hirescharacters=true?), but the regular operation of the nearest neighbour filter shouldn't do things like that.

No, no, I believe Radiant is speaking about different thing:

Another graphical glitch: if a GUI button is set to "no clipping" then images can indeed appear bigger than the button itself. However, text will not. When using truetype fonts that are slightly bigger than the button, this looks fine in the editor but is clipped in the game.

The character problem is different, this is something I noticed too in some games, and it looks very weird indeed.

[Crimson Wizard]

Radiant, I am sorry, I found I made the widescreen borders fix wrong, my previous change made it calculate incorrect wanted resolution.

This is an updated version:
http://www.mediafire.com/download/qyejemmk5i50ov7/acwin.7z

Now I was able to test it on my own computer too (because it suggested correct size, that was supported by my driver).

[Snarky]

There's a graphical glitch with the Nearest Neighbor filter: it is not applied to characters. If using (e.g.) the 4x NN filter, then each pixel in the game is displayed as a 4x4 block of pixels on the screen. However, characters if zoomed use the full resolution, not 4x4 blocks. It appears the graphical operations are performed in the wrong order: the character is enlarged to 400% first, then reduced from there to account for scaling; whereas it should be the other way around; this discrepancy simply looks odd, as if the characters use a higher resolution than the backgrounds. I haven't checked, but this likely also applies to objects.

Some games use this 'feature' in conjunction with a NN filter as a way to display higher resolution characters while keeping the game backgrounds at 640x400 (we used this trick in both Al Emmo and Mage's Initiation). Disabling it would destroy the pixel artwork in the latter game. So, if this is going to be 'fixed', it would be necessary to make it an optional setting for any games that rely on the current behaviour.

Like Scavenger says, this is a hideous bug that should be fixed ASAP, and I find the decision to deliberately inflict it on your game deeply disturbing. Plus, relying on players not changing the filter settings?! Madness!

Just make the game in the resolution you want the sprites to be. If you absolutely must have this awful effect, you can scale up the backgrounds from a lower resolution before importing them.

[AGD2]

The issue only becomes visible when the character sprites are scaled down. As soon as pixel art gets scaled smaller at the native resolution, the pixels begin to lose symmetry and the artwork becomes horribly jagged and blocky. So it comes down to a decision between blocky sprites or hi-res ones. In my view, the hi-res ones look much better in regards to keeping the pixel artwork intact.

The only other ways around this are to avoid scaling down the characters completely or to make batches of character animations that are optimized for various pre-set sizes. But I'm afraid that these two approaches aren't feasible (not for a game this size anyway). Of course, players can change the filter setting to "none", and the game will still play. They just won't see the optimal, intended result.

Just make the game in the resolution you want the sprites to be. If you absolutely must have this awful effect, you can scale up the backgrounds from a lower resolution before importing them.

The game has over 70 rooms at 640x400 resolution. scaling up the backgrounds to 1280x800 would increase the filesize dramatically. Why do that when a simple setting to achieve the same effect will suffice?

[Crimson Wizard]

AGS 3.3.0 BETA 10 released (engine version 3.3.0.1148)
-------------------------------------------------------
A very small update, mostly fixing various bugs, both old and new ones.

-------------------------------------------------------
Changes from BETA 9:

Features:
- Speech overlays now support alpha blending; (God, I hope that's the last of them, and I did not miss anything else )
- Windows version will now write crash dump on "out of memory error" to help diagnose the situation if this occured due bug in the engine.

Bug fixes:
- Fixed script window flicker that occured when the script was first time modified and when it was saved (regression);
- Fixed occasional crash that could occur when creating new room (regression);
- Fixed occasional crash that could occur when copy/pasting text in the script;
- Fixed moving room objects with keyboard in Room Editor did not work properly for hi-res games which used low-resolution coordinates setting (regression).
- Fixed DynamicSprite.CreateFromFile() function (regression).
- Fixed superfluous string buffer growth in the engine, that could eat all your memory in some cases (regression);
- Fixed side-borders that were not applied properly at newer (larger) widescreen resolutions;
- Fixed custom dialog options clickable area by correcting its horizontal coordinate range.

Compatibility:
- Fixed <=2.72 games crash that occured if character view missed "Up" loop (unlike 3.+ games, older ones had a fallback to use "Down" loop in such cases).


Download links (also updated at first page):
EXE:
http://www.adventuregamestudio.co.uk/betas/AGS-3.3.0-beta10.exe
ZIP:
http://www.adventuregamestudio.co.uk/betas/AGS-3.3.0-beta10.zip

[Snarky]

The issue only becomes visible when the character sprites are scaled down. As soon as pixel art gets scaled smaller at the native resolution, the pixels begin to lose symmetry and the artwork becomes horribly jagged and blocky. So it comes down to a decision between blocky sprites or hi-res ones. In my view, the hi-res ones look much better in regards to keeping the pixel artwork intact.

The only other ways around this are to avoid scaling down the characters completely or to make batches of character animations that are optimized for various pre-set sizes. But I'm afraid that these two approaches aren't feasible (not for a game this size anyway). Of course, players can change the filter setting to "none", and the game will still play. They just won't see the optimal, intended result.

Just to be clear, we're talking about this kind of difference, right?

[IMGzoom]http://i.imgur.com/w3ge9ld.png[/imgzoom]
Aaaagh it burns!

[IMGzoom]http://i.imgur.com/OtW4Qyi.png[/imgzoom]
Phew that's better!

[AGD2]

Yes, though the effect looks more pronounced on a low-res 320x200/320x240 background than it does on a 640x400/640x480 background.

[imgzoom]http://www.himalayastudios.com/scratch/hi-res_scaling.jpg[/imgzoom]