AGS 3.6.1 - Release Candidate (RC 6)

[Crimson Wizard]

There's a problem found in the most recent update, RC4, which causes crash on startup under following conditions:
- OpenGL graphics driver
- Your computer has a ATI graphics card.

Following is a temporary build with a fix:
https://cirrus-ci.com/task/5996131579068416

[Dave Gilbert]

Oh thank you! A number of testers complained that the game crashed when using OpenGL but I always assumed it was something dumb on my end! I incorpoerated this into the recent build and I'll let you know if anyone has the same issue.

[Crimson Wizard]

Oh thank you! A number of testers complained that the game crashed when using OpenGL but I always assumed it was something dumb on my end!

The crash with "Unhandled exception" error is always engine's fault. Please report all of these!

[Crimson Wizard]

Updated to RC5
(Please use download links in the first post)

Updated to have all fixes from v3.6.0 - P10.

Other changes:

Editor:
- Fixed in room editor character and object sprites drawn without transparency.

Engine:
- Fixed a crash when trying to initialize OpenGL renderer, specific to systems with AMD/ATI video cards.

[vga256]

Just upgraded a 3.6.0.51 project to 3.6.1.20. It ran correctly and without errors in 3.6.0.51, but now it is crashing and throwing an error at startup with 3.6.1.20.

For context: The game involves a lot of procedural generation at startup, which is probably where it is generating the crash.

---------------------------
Illegal exception
---------------------------
An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x004210E9; program pointer is +3, engine version 3.6.1.20, gtags (379,16)
------------


Crashdump is available if that helps. I can also provide you with the entire project source if you prefer. About one out of 20 times running the game, it yields an 'out of bounds' array index of -1 in one of my function calls. This is strange, because I am not able to replicate that bug in my scripts using 3.6.0.51.

[Crimson Wizard]

Crashdump is available if that helps. I can also provide you with the entire project source if you prefer. About one out of 20 times running the game, it yields an 'out of bounds' array index of -1 in one of my function calls. This is strange, because I am not able to replicate that bug in my scripts using 3.6.0.51.

Yes, please, either a Crashdump or a compiled game would be necessary.
Also, could you elaborate, does it crash all the time or not, and if yes, then when does the "out of bounds" happen?

[vga256]

Yes, please, either a Crashdump or a compiled game would be necessary.
Also, could you elaborate, does it crash all the time or not, and if yes, then when does the "out of bounds" happen?

It crashes every time time after running, and only about 5% of the time (or less - I'm just guessing the frequency) does it trap an out of bounds error and halts execution before a crash can happen. I can't tell if the two are related, or coincidental. (Link to compiled game and crashdump sent via PM.)

[Crimson Wizard]

It crashes every time time after running, and only about 5% of the time (or less - I'm just guessing the frequency) does it trap an out of bounds error and halts execution before a crash can happen. I can't tell if the two are related, or coincidental. (Link to compiled game and crashdump sent via PM.)

The crash happens with Software renderer. Other renderers make it run, it seems, but then the script mistakes may or not happen (it actually opened a game few times).

The crash with Software renderer is occuring within a call to Display, inside "game_start" (specifically it is displaying text "x 11 y 10 currentMapWidth 64", if that matters). It looks like engine is trying to draw room viewport for some reason, although the room is not loaded yet, and this where it crashes because some data is not initialized yet. I would need to investigate this, but most likely it's simply should be skipping certain steps when the game is drawn without any loaded room.

EDIT: yes, it's confirmed, in 3.6.1 calling Display in game_start crashes the game if using Software renderer.

[vga256]

The crash with Software renderer is occuring within a call to Display, inside "game_start" (specifically it is displaying text "x 11 y 10 currentMapWidth 64", if that matters). It looks like engine is trying to draw room viewport for some reason, although the room is not loaded yet, and this where it crashes because some data is not initialized yet. I would need to investigate this, but most likely it's simply should be skipping certain steps when the game is drawn without any loaded room.

EDIT: yes, it's confirmed, in 3.6.1 calling Display in game_start crashes the game if using Software renderer.

Interesting. I added that Display call in game_start, just before I uploaded the binary, just to see if I could trace the source of the 'out of bounds' -1 index error.
UPDATE: just confirmed - yep, I had a second Display call buried in my initialization code that was triggering the crash. It is definitely caused by Display in game_start by the software renderer.

[Crimson Wizard]

@vga256 here's a temp build with a fix:
https://cirrus-ci.com/task/5204100904648704

Clarifying, this fixes Software renderer for any case when the game is drawn before the first room was loaded, for any reason (called Display in game_start, or else).

[vga256]

CW - Thanks for figuring this out and the fix. Confirmed working on my end.

[imagazzell]

My apologies if this has been addressed elsewhere that I couldn't find (I did search), or if this is the wrong place to be asking, but has the Sprite Cache size limit been increased at all in either 3.6.0 or this new build, or is it still capped at 512 MB, as in 3.5.1?

My game is hi-res and has a number of big (both in dimensional size and length) animations, and runs like a slug on some systems. I imagine a larger cache size limit (at least 1 GB / 1024 MB), in addition to the other performance enhancements you guys have been working on, could help.

If this has not been implemented, I'd humbly request it to be considered, if anyone else would also find it helpful.

[Crimson Wizard]

My apologies if this has been addressed elsewhere that I couldn't find (I did search), or if this is the wrong place to be asking, but has the Sprite Cache size limit been increased at all in either 3.6.0 or this new build, or is it still capped at 512 MB, as in 3.5.1?

Hello. The Sprite Cache size was never capped in the engine. What is limited is the numbers shown in "setup" program, which are chosen arbitrarily, judging by the average AGS games demand. But it's still possible to set your own value in the "Default Setup" pane in the editor, or config file directly.

Another thing to keep in mind is that AGS engine was a 32-bit program, and could not exceed 2 GB of total memory on Windows.

My game is hi-res and has a number of big (both in dimensional size and length) animations, and runs like a slug on some systems. I imagine a larger cache size limit (at least 1 GB / 1024 MB), in addition to the other performance enhancements you guys have been working on, could help.

There are few things to mention here about 3.6.1 version.
1. The selection in setup program has been increased to 1 GB for a 32-bit engine and 2 GB for a 64-bit engine.
2. Besides sprite cache, there's now a "texture cache" that speeds up game run with Direct3D/OpenGL renderers, and for those renderers it's now more important than the sprite cache. Often it's better to keep texture cache at high values (if you have enough system and video card memory), and sprite cache at moderate levels.
3. OTOH, caches help when images and animations repeat. But they don't help when animation or image is shown for the first time, because loading takes time. For this purpose we added experimental functions called Game.PrecacheSprite and Game.PrecacheView. These are meant to be cache number of sprites or views prior to certain scene, e.g. during some "loading" screen.
4. The 32-bit engine for Windows is now built with a certain flag, which lets it use up to 4 GB of RAM. In theory one may also use 64-bit engine that can use even more than that, but we do not distribute it along with AGS Editor at the moment, there are some remaining organizational issues. Maybe we eventually will do this.


All that said, I usually advise to also look for opportunities to optimize the game. There may be ways to reduce amount of memory an animation requires, thus reducing time it is loaded and prepared for display, and increase number of animations which may be loaded into a cache.

[imagazzell]

Thanks for all the info, CW!

Yes, sorry, I meant the limit in the setup program. I should have been more clear about that. I'm glad to hear that limit has been raised.

But it does sound like I would probably benefit more from the new precache functions you mentioned, as the lag seems to be its worst the first time an animation is run. Has the local Help file been updated to explain how to use these new functions?

I also get lag and stuttering when playing .ogv cutscenes, but I'm guessing that's related to something else (perhaps just general slowness of the test system involved). I wonder if any of the other new enhancements may help with that at all.

I will also try to optimize my animations, as you suggest, by seeing where I can crop out any excess transparent pixels, etc.

[Crimson Wizard]

In regards to the 3.6.1 release progress. Given there's not many serious bugs found recently in 3.6.1, I maybe won't be releasing any more "RC" updates, but wait for 1-2 weeks and release a final 3.6.1 (unless something serious is found in the meantime, of course).

I also get lag and stuttering when playing .ogv cutscenes, but I'm guessing that's related to something else (perhaps just general slowness of the test system involved). I wonder if any of the other new enhancements may help with that at all.

It's difficult to tell without knowing specifics. But in general, firstly, PlayVideo adjusts game's FPS for the duration of video playback. Secondly, iirc there's no buffering implemented at all, meaning it has to decode and prepare a new frame synchronously with the game update. If this is a HD video, that will take roughly as much time as would a full-screen sprite.

[imagazzell]

I want to give a big "thank you" to you guys for the performance enhancements. 3.5.1 builds of my game ran like a snail on my household's other system. I'm not sure if it was the new PrecacheView function (which I made good use of), the enlarged cache sizes, other changes you've made, or all of the above, but it runs great now. View animations, OGV playback, even simple dialogue exchanges are all noticeably snappier and smooth now. So THANK YOU! Well done.

I do have a couple quick questions:

1. Was something changed about either room_load or the fade scripts since 3.5.1? In upgrading to 3.6.1, I needed to move my FadeIn commands from the end of room_load, where I used to have them and they worked fine, to the beginning of the "after fade in" function (which seems backward to me). Otherwise, my pre-fade commands (characters moving into position, etc.) were now happening after the fade.

2. I don't know if this issue is new to 3.6.1, but some of my default setup choices are not sticking in the "winsetup" program after compiling. Most notably for me right now is the scaling method. I selected "linear interpolation" in the default setup pane, but after compiling, it reset to "nearest-neighbour". Is there some reason Windows would make this selection by default, or should that setting be keeping? I noticed something similar previously with the driver mode resetting to OpenGL even though I had Direct3D 9 selected in default setup, but this seemed to be fixed after de-selecting and re-selecting it. The same solution didn't seem to work for the scaling method though...

[Crimson Wizard]

1. Was something changed about either room_load or the fade scripts since 3.5.1? In upgrading to 3.6.1, I needed to move my FadeIn commands from the end of room_load, where I used to have them and they worked fine, to the beginning of the "after fade in" function (which seems backward to me). Otherwise, my pre-fade commands (characters moving into position, etc.) were now happening after the fade.

Normally you should not run anything blocking, that requires "wait", or any visual effects in "room_load" (aka before fade-in) because room is not supposed to be drawn at this time. I do not know exactly why it worked in 3.5.1 or earlier, but maybe it was not entirely consistent in this regard. The correct way is to have only starting room setup in "room load" and run any effects, animations or cutscenes in "after fade in".

The "fade in" in these events is referring to the built-in AGS transition. If you are using custom transition, then normally you should set built-in transition style to "Instant", and run your own transition in "after fade-in" event. This recommendation may be found on AGS forums too.

If AGS had a mechanism to let user override transition effect, and had some kind of a "transition state" that user could handle in script, then things would sound more logical, but it does not have this now.

EDIT:
But because new version in 3.* branch must be backwards compatible, I would need to fix the FadeIn command not working in room load, since it worked before.

2. I don't know if this issue is new to 3.6.1, but some of my default setup choices are not sticking in the "winsetup" program after compiling. Most notably for me right now is the scaling method. I selected "linear interpolation" in the default setup pane, but after compiling, it reset to "nearest-neighbour".

Winsetup displays a configuration merged from at least 2 sources: default config file found in the game's directory (this is what you set in Default Setup), and player's config found in game's save folder. If you want to see what the default config looks like in winsetup, then delete config file from save folder.
You may refer this article for more information:
https://adventuregamestudio.github.io/ags-manual/EngineConfigFile.html

[imagazzell]

EDIT:
But because new version in 3.* branch must be backwards compatible, I would need to fix the FadeIn command not working in room load, since it worked before.

I wouldn't want you to have to go through whatever work that would entail just because of me and my freakishly unorthodox game. Please only make that change if you can confirm that 3.5.1 works that way on your end as well.

Winsetup displays a configuration merged from at least 2 sources: default config file found in the game's directory (this is what you set in Default Setup), and player's config found in game's save folder. If you want to see what the default config looks like in winsetup, then delete config file from save folder.
You may refer this article for more information:
https://adventuregamestudio.github.io/ags-manual/EngineConfigFile.html

So then, if I'm following correctly, if I were to launch the program on a new system with no prior save data, or delete the entire save folder beforehand, shouldn't the configuration take on the settings I made in Default Setup? Because it's not (at least the scaling method isn't; it always resets to "nearest-neighbour" on a fresh launch). Even on my primary system, where I had previously set the configuration (both in AGS and the player config) to linear interpolation, a new build has nearest-neighbour selected.

EDIT:
Interestingly, if I open the compiled acsetup.cfg file (the one in the installation directory, not in the save folder) with Notepad, it does show "filter" set to "linear", but winsetup still shows "nearest-neighbour" upon each new build. Does winsetup only take effect if the user makes changes and hits Save, or should it be matching what's in the default acsetup.cfg from the get-go? In other words, would a fresh launch of the game on a system with no prior AGS configurations be following the settings in acsetup.cfg, regardless of what winsetup may show?

[imagazzell]

Unrelated (possible) UI bug, regarding the new Log Panel:

I can open and close it repeatedly from the "Window" dropdown menu just fine. If, however, I close it with the "X" on the log panel itself, it won't re-open again until I restart AGS.

[Crimson Wizard]

So, I fixed few mistakes reported lately, and here's a AGS update that may be downloaded from our build server:
https://cirrus-ci.com/task/6526915163455488

- fixed characters and objects not visible on screen if FadeIn() is called in "room load" event.
- fixed graphic filter not selected correctly on winsetup launch.
- fixed LogPanel cannot be restored after closing it by pressing "x" button.

there are few more, but they are related to obscure and deprecated features.

I will likely release a new proper RC update soon, given there have been a bunch of fixes made in the last several days; so I want to give users an opportunity to test the newest version.