Topic: AGS 3.4.1 - RC 3 (new release candidate)

[Crimson Wizard]

Also, I just realized a terrible thing. When AGS reads a savedgame it also checks for the colour depth the game was running on, because DynamicSprites and some other things may depend on active color depth.
Since now Direct3D and OpenGL always run in 32-bit, 16-bit games have different saves depending on whether they were run with Software renderer (which still in mode matching game's original color depth) or Direct3D/OpenGL, and you cannot read your own saves if you switch renderer.

This is actually a critical issue that must be solved, I cannot make a release this such problem.

At first it should be found it if DynamicSprites really should rely on renderer's color depth, and not native game's one. This logic was carried over from older AGS, and maybe had sense for software renderer, but since Direct3D/OpenGL convert native gfx to their 32-bit textures anyway, a different approach may be required; that is - distinct native color depth (in which all scripted drawing is performed) and rendering color depth.

To think more about this, this had to be done in the first place, because now running 16-bit game on Direct3D (which runs 32-bit) may cause some scripted 16-bit drawing operations produce different results...

Looks like I was too hasty when making this change, there's whole layer of issues in there that I did not notice.

[Dave Gilbert]

Is it even worth maintaining 16 bit mode to begin with? Speaking as a commercial developer, releasing a 16 bit game in 2017 is kind of laughable. Copying the LOOK and FEEL of a 16 bit game is one thing, but making an actual/literal 16 bit game is just asking for compatibility trouble. I know that we had no end of issues when we released the 16 bit Gemini Rue even back in 2011. Maintaining this just seems like a lot of effort for something that fewer and fewer people are using.

[Crimson Wizard]

Is it even worth maintaining 16 bit mode to begin with?

Running old games, that was always about running old games. It is still supported in this engine.
Also, if AGS will ever be running 8-bit games properly in Direct3D, it will meet same issue.

[Dave Gilbert]

By running old games, you really mean COMPILING old games, right? It will still be a 16 bit game no matter what, which will still run into the same compatibility issues above. And can't the latest version of AGS convert 16 bit graphics to 32 bit anyway? Or am I misremembering?

Edit: To expand on what I mean; I recently took the 16 bit Gemini Rue, imported it into the most recent version of AGS, changed the color depth in "general settings" to 32 bit, and recompiled. Does that make the game 32 bit? I know that I no longer have the same compatibility issues that the game used to have.

[Crimson Wizard]

By running old games, you really mean COMPILING old games, right?

No, I meant running old games with the new engine. But that could be compiling old games too, if you like.

[Crimson Wizard]

Looks like we are talking about different things. I cannot follow you.

I was speaking about ENGINE running 16-bit games. Not Editor.

[Dave Gilbert]

Sorry CW! As always I approach these things from a commercial dev perspective, so what seems obvious to me might not be obvious to everyone else. My question is basically why bother supporting 16 bit games to begin with, since games are no longer made that way (and haven't since 2004) and barely run on modern computers. Wouldn't it be easier to just drop 16 bit support altogether? If we draw a line under that and just make every game 32 bit (or make all games compile to 32 bit), then this ceases to be an issue. Unless there's a reason for this that I'm totally missing.

[Crimson Wizard]

Sorry CW! As always I approach these things from a commercial dev perspective, so what seems obvious to me might not be obvious to everyone else. My question is basically why bother supporting 16 bit games to begin with, since games are no longer made that way (and haven't since 2004) and barely run on modern computers. Wouldn't it be easier to just drop 16 support altogether? If we draw a line under that and just make every game 32 bit (or make all games compile to 32 bit), then this ceases to be an issue. Unless there's a reason for this that I'm totally missing.

I don't know why??? I was not going to myself at first, but been doing old games support for 4+ years, because since JJS left, Linux people were asking me to make engine run them. Because they wanted to run old AGS games on Linux without using windows versions.

[Dave Gilbert]

Fair enough! Like I said, my perspective is different. If people are actively asking for it and genuinely want it, then that answers my question.

[Crimson Wizard]

I don't know how I am going to fix this. The whole system is messed up. If software renderer is running 16-bit game in 16-bit and creates 16-bit dynamic sprite, but for example OpenGl renderer runs 16-bit in 32-bit mode it will create 32-bit dynamic sprite... If I will make dynamic sprite conversion when restoring save, may that screw things up, like change the looks of the game if a person switches renderer during play?

To think of this, even the idea of choosing different depth of dynamic sprite depending on display mode is bad, because game may be scripted having one range of colors in mind, and instead gets another range.



UPD: Maybe I could actually make Software renderer run in 32-bit mode too for both 32-bit and 16-bit games. I guess there's hardly a system that cannot do that.
It's just that I am not sure how well that will work with 16-bit gfx, and it will have to do all the conversions on fly while being slower renderer already.
Also, plugins like SnowRain may break again...



EDIT: I will see if what will happen if engine will do dynamic sprite conversion on save game restore first. Code-wise that should be easiest path, unless I am missing something else.
If the results are visually acceptable, I could leave it like that.

(Although the whole thing about DynamicSprites being created in non-native color depth is still absolutely wrong. But changing that would require bigger rewrite I would not like to do now)


EDIT2: The ridiculousness of this is that with 16-bit games run in 32-bit mode you can even create dynamic sprites with alpha transparency in 16-bit games (because AGS checks for display mode, not native property).

[m0ds]

A +1 for "goodbye" to 16 bit. Maybe put it in some other version but eradicate it from the main public one. Among the reasons Windows 8 and 10 don't like 16 bit, and it's always good to kill things players might complain about at their source, the Steam API won't work with a game set to 16 bit (notification window doesn't work in 16 bit).

It's a breeze to update from 16 bit to 32 bit over newer engines (if you've got a 16 bit game in an older iteration of the engine). Going forward though I agree with Dave, it's dodgy supporting it out to end users, except in perhaps very special cases (I wouldn't know what they are, surely you can emulate 16 bit within 32 bit graphics if you must).

With all that said, the most recent winsetup is pretty good! But I wanted to ask, I have dead space in fullscreen mode because my game is 320x200. Dead space I mean black bars at top and bottom. Now, the Steam notification thingy, cannot write into that space (or whatever it does, to clear its notifications) because it's not game (being drawn) space. I was wondering if the "Enable Borders" might help, if it in effect is creating a draw area (not too sure how to describe this sorry), but it is gone from winsetup now. Of course, I can stretch my game out nicely to resolution with winsetup, so the game draw space fills entire screen and the Steam notifications clear away fine. But game looks nasty and I don't think I can update the build resolution at this late stage.

Could there be another way to... well I don't know how to describe it... Have black bars that are refreshing like the game draw area does? Or any other solution for this effect of Steam notifications not clear away? I realize this may be tied to monkeys dll HOWEVER I've seen this in numerous engines when you play letterbox. I have a feeling Unity have recently done something to prevent it happening, I have no idea what but after updating game in a new version of Unity, I can play letterbox and they now disappear (they didn't used to). So wondering what solution we might find for AGS which also suffers it?

[Danvzare]

A +1 for "goodbye" to 16 bit. Maybe put it in some other version but eradicate it from the main public one. Among the reasons Windows 8 and 10 don't like 16 bit, and it's always good to kill things players might complain about at their source, the Steam API won't work with a game set to 16 bit (notification window doesn't work in 16 bit).

While I'm also ok with killing 16-bit, since nowadays it seems to serve no purpose other than to cause problems for people who didn't think about setting their game to 32-bit when they started making their game. I can't help but feel that we might be shooting ourselves in the foot if 16-bit was just straight up removed. Why? Well we thought about removing DirectDraw, but for some strange reason it's become more compatible than Direct3D within recent years, so it was a damn good thing that we didn't remove it.

Perhaps having 32-bit as the default, and having the engine strongly recommend against setting it to 16-bit might be the better option. Unless everyone here is in agreement that removing 16-bit will have no negative side effects now or in the near future.

[Crimson Wizard]

Danvzare, do you realize that option to set game's color depth in the editor 16-bit and engine running the game in 16-bit are different things?

Dave Gilbert above was probably talking about removing game's 16-bit option. I was talking about runtime display mode. Not sure which one MJL was talking about, maybe both.

Removing 16-bit option from the game settings will make people use 32-bit gfx, but it does not mean that the game cannot be run in 16-bit mode. Even today you can force engine to run 32-bit games in 16-bit mode at the cost of decreasing graphics quality (there is such option in config).

[Dave Gilbert]

If you removed the 16-bit option from the settings, why would there even be an option to run the game in 16-bit mode in the first place? <hides>

Danzvare: I think 32-bit color depth is the default now. At least, it was the default when I just did a test.

[Crimson Wizard]

If you removed the 16-bit option from the settings, why would there even be an option to run the game in 16-bit mode in the first place?

It does not have to be, but it is technically possible to have one. For example, AGS still have enforced 16-bit mode, probably to run games on slow machines with ancient graphics cards.
I am trying to say that even if games are made with 32-bit graphics, the engine may still be running them in 16-bit mode if that would be required on some systems.
In other words, removing 16-bit setting from the Editor does not prevent from having a 16-bit runtime mode, if such unusual need will appear.

[NicolaGs]

I believe I found a bug related to the translation file.

My project was done with 3.4.0 untill now.
I installed RC2.
I "cleaned" my project folder by deleting the "compiled" folder.
I compiled my project with the RC2 : compilation failed and got an error message : "..\compiled\English.tra" not found.

Full error message :

Spoiler: ShowHide

Code: Adventure Game Studio

1. Error: Impossible de trouver une partie du chemin d'accès (= "impossible to find a part of the access path") '***my_path***\I_want_out!\Compiled\Data\English.tra'.
2. Version: AGS 3.4.1.9
3.  
4. System.IO.DirectoryNotFoundException: Impossible de trouver une partie du chemin d'accès '***my_path***\I_want_out!\Compiled\Data\English.tra'.
5.   à  System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
6.    à  System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
7.    à  System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
8.    à  AGS.Editor.Components.TranslationsComponent.CompileTranslation(Translation translation, CompileMessages errors)
9.    à  AGS.Editor.Components.TranslationsComponent.AGSEditor_PreCompileGame(PreCompileGameEventArgs evArgs)
10.    à  AGS.Editor.AGSEditor.PreCompileGameHandler.Invoke(PreCompileGameEventArgs evArgs)
11.    à  AGS.Editor.AGSEditor.CompileGame(Boolean forceRebuild, Boolean createMiniExeForDebug)
12.    à  AGS.Editor.Components.BuildCommandsComponent.CompileGame(Boolean forceRebuild)
13.    à  AGS.Editor.Components.BuildCommandsComponent.CommandClick(String controlID)
14.    à  AGS.Editor.GUIController._mainForm_OnMenuClick(String menuItemID)
15.    à  AGS.Editor.MainMenuManager.MenuEventHandler(Object sender, EventArgs e)
16.    à  System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
17.    à  System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
18.    à  System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
19.    à  System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
20.    à  System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
21.    à  System.Windows.Forms.ToolStripMenuItem.ProcessCmdKey(Message& m, Keys keyData)
22.    à  System.Windows.Forms.ToolStripManager.ProcessShortcut(Message& m, Keys shortcut)
23.    à  System.Windows.Forms.ToolStripManager.ProcessCmdKey(Message& m, Keys keyData)
24.    à  System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
25.    à  System.Windows.Forms.Form.ProcessCmdKey(Message& msg, Keys keyData)
26.    à  System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
27.    à  System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
28.    à  System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
29.    à  System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
30.    à  System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
31.    à  System.Windows.Forms.ContainerControl.ProcessCmdKey(Message& msg, Keys keyData)
32.    à  System.Windows.Forms.Form.ProcessCmdKey(Message& msg, Keys keyData)
33.    à  System.Windows.Forms.Control.ProcessCmdKey(Message& msg, Keys keyData)
34.    à  System.Windows.Forms.Control.PreProcessMessage(Message& msg)
35.    à  System.Windows.Forms.Control.PreProcessControlMessageInternal(Control target, Message& msg)
36.    à  System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(MSG& msg)

The only way I found to be able to compile was :
- making a back-up of my .TRS file
- deleting the translation in the editor
- creating a new translation (with the same name) in the editor
- replace the newly created .TRS file with my backup
- compile

But, each time I delete the compiled\data folder, or just the .TRA file... the message comes back.

Version 3.4.0 was able to re-create TRA file each time if needed.

[NicolaGs]

I found another issue :

If you set the Graphic Driver in the editor (in Default Setup) to be OpenGL, it sets "driver=OpenGL" in the acsetup.cfg file, whereas it should be "driver=OGL" to work correctly.

EDIT :
In the same department :
Sprite cache size is not correctly written : editor writes "cachemax=128" instead of "cachemax=131072" (MB vs KB).
This has direct consequences on the game performance... (in my game, it dropped the frame rate from 60 to around  30).

[Radiant]

Unfortunately, I made mistake to participate in MAGS this month, and need to focus on one task at time.

I for one think it's great that you're working on a game in the engine you've spent so much time on. Go for it!

[Crimson Wizard]

@NicolaGs, please try this update: https://www.dropbox.com/s/enevvalninme7cn/ags-editor-3.4.1--pre-rc3.zip?dl=0
Translation error was related to "Data" subfolder not created in time.
Also fixed config problems.

Unfortunately, I made mistake to participate in MAGS this month, and need to focus on one task at time.

I for one think it's great that you're working on a game in the engine you've spent so much time on. Go for it!

Yeah, well, working on the game is one thing, but competition with a deadline had messed up my normal routine.

[NicolaGs]

@NicolaGs, please try this update: https://www.dropbox.com/s/enevvalninme7cn/ags-editor-3.4.1--pre-rc3.zip?dl=0

I confirm that both issues have been fixed! Good job Thanks...