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

[Dave Gilbert]

The updates are coming fast and furious. THANKS! Dutifully downloading.

edit: or rather, I would be downloading if the link worked.

[Crimson Wizard]

Fixed typo in the link.

[AGD2]

Thanks for the update! These Open GL tint improvements are excellent. Gave it a test and most things seem to be resolved.

I did, however, notice that two issues are still outstanding:

1)

This issue existed in 3.4.0, but I didn't get around to reporting it earlier:  If a queued music piece starts playing while character speech audio is in progress, the music volume will jump back up to the normal volume level (in the middle of speech), rather than adhering to the SetAudioTypeSpeechVolumeDrop value.

This one's still happening. Here's a video demonstrating it.

At around 15 seconds, the female character starts speaking. The currently playing music has almost reached its end, and another music piece has already been queued to play after it. At 18 seconds, the character is still speaking, and the music ends. The new queued piece immediately kicks in and it spikes back up to normal (loud) volume, instead of detecting that speech is still playing and making the new music adhere to the value of SetAudioTypeSpeechVolumeDrop.


2)

The Escape key doesn’t work after you press CTRL. To re-enable the escape key, you need to press any other key in-game, other than CTRL.

I know this was an issue with Allegro 4. So, I just wanted to check if it's been resolved in Allegro 4.4 and whether a possible solution is now available after upgrading AGS to that version?

This has been an irritating quirk for some time in AGS. I presume this one hasn't yet been resolved in Allegro 4.4?

--EDIT--

Oh, and also this one's still an issue:

3)

Another thing I noticed is that pressing the Tilde (~) key to bring up the console results in a blank white console with no text in it. This happens for all three graphics drivers (D3D. OpenGL, and software).

And:

For me, pressing ALT+ENTER to make the game enter full-screen mode doesn't work properly with the Direct3D driver. I just get a black screen. Pressing ALT+ENTER to put the game back to windowed mode makes the game screen visible again. (Note that it DOES work with both the Software and Open GL drivers - only Direct3D has the problem). My video card is a relatively recent ROG STRIX- GeForce GTX 1080 with the latest drivers, so it shouldn't have any issues.

Does fullscreen mode work from the start if you set it in winsetup?
Also, what is your operating system? Earlier we found that D3D may not work well on Windows 10.

Something weird I just discovered when testing this again with the D3D driver, is that even if I run the game from winsetup.exe and leave the checkbox unmarked to run in windowed mode, it launches into the game in full-screen mode and the screen is entirely black from the get go... even without me pressing ALT+TAB to toggle.  This didn't used to happen in previous versions of AGS. Running the game from winsetup.exe would always display properly in with windowed and full-screen mode under D3D, even on Windows 10. Seems that something exclusive to this version has stopped full-screen D3D from working.

[Crimson Wizard]

Another thing I noticed is that pressing the Tilde (~) key to bring up the console results in a blank white console with no text in it. This happens for all three graphics drivers (D3D. OpenGL, and software).

That works for me. But console is printed with the predefined font number (0). What kind of font0 do you have in your game? Have you modified any of the new advanced parameters for it (like line spacing and vertical offset)?
Also, what is your game's color depth (just in case)?



Regarding everything else, I must take a break from AGS now for a couple of weeks. I will be able to look into these only after.

[Alan v.Drake]

- In Direct3D mode, if RenderAtScreenResolution is OFF, the game misses one rightmost column and bottom row of pixels (since it is still stretched to proper rectangle, this might also cause minor image distortion). I know approximately where this bug is coming from, but could not yet find a correct way to fix it.

I tried taking a look, it seems those new SetupViewport() calls are somehow disrupting StretchRect making so it resizes incorrectly only giving 1 pixel on the last column and row.
I don't see why that should happen, I guess I'm missing something, I'm giving up for now...
Wait, I was wrong, the mishap happens somewhere when "OnSetNativeSize()" is called by D3DGraphicsDriver::SetNativeSize()...

- Alan

[Crimson Wizard]

the mishap happens somewhere when "OnSetNativeSize()" is called by D3DGraphicsDriver::SetNativeSize()...

Could you elaborate, please?

I also found that if surface is not stretched at all (game is run in window of native game's size), this problem does not occur. So this is a problem of pixels translating into backbuffer.

I was wondering, if it is particular row and column affected, so I tried increasing native surface by few pixels, but result was practically same, last row of game pixels is drawn as a very thin line. So I am hesitating between surface stretching and sprite rendering on native surface.

There is also such thing as texel-to-pixel translation which is addressed by using "pixelOffset" variables. I noticed that they are used wrongly in case of native surface (they must be equal to 0.5,0.5 always in that case), but fixing that did not fix the problem, so there is something else.

[Alan v.Drake]

the mishap happens somewhere when "OnSetNativeSize()" is called by D3DGraphicsDriver::SetNativeSize()...

Could you elaborate, please?

Try commenting OnSetNativeSize() and see the result, it should look right (check also what happens on fadescreen).
I didn't try on the latest build, I need to update the libraries for the "play_fli_pf" support, I'll give it another try tomorrow.

I can't figure why there should be coordinate translations on a StretchBlt, in theory it should just stretch the surface from a to b. This is way more complicated than it should be.

- Alan

[Crimson Wizard]

I can't figure why there should be coordinate translations on a StretchBlt, in theory it should just stretch the surface from a to b. This is way more complicated than it should be.

Are you referring to how software filter works?... because only that filter uses coordinate translation before calling StretchBlt.
That translation is also applying offset if e.g. image is centered on larger screen. Since same coordinate conversion was used in few places in the engine (also in mouse routines) I decided to pick these conversions out into translation class.

...As for why this conversion is performed on every function call - that is an interesting question... That code is rather old, I wrote it when implementing free display modes. Back then I did not understand everything there well, so I was experimenting, moving functionality between renderer and filter classes, and could leave something silly there by mistake...
All this depends on whether that function may receive differently sized bitmaps and different coordinates in arguments. If they are always guaranteed to be of same size and position, then it is better to use precalculated rectangles instead.

Try commenting OnSetNativeSize() and see the result, it should look right (check also what happens on fadescreen).

But I can confirm that not calling OnSetNativeSize() makes the issue go away. Cannot understand why yet though.

EDIT: Ummmm.... actually.... it "works" because when you comment OnSetNativeSize out, Direct3D fails to initialize, and one of the other renderers initializes instead (OpenGL has priority in the latest build), which do not have same problem.
OnSetNativeSize sets _srcRect variable which is important for successful work of a renderer.


UPD: There is either something wrong with direct3ddevice->StretchRect call, or the complex issue which depends on several effects.
For example, if I make it always stretch to same native size (1:1) then it draws it correctly with no pixels missing.
The fraction of "lost" pixel also varies. If stretching is 1:2, then mistake equals to half of pixel, if it is 1:3 and higher, then it's more (until only a tiny part of pixel remains).

[AGD2]

That works for me. But console is printed with the predefined font number (0). What kind of font0 do you have in your game? Have you modified any of the new advanced parameters for it (like line spacing and vertical offset)?
Also, what is your game's color depth (just in case)?

Font 0 is a pretty small TTF font, but it's there. In previous versions, I'm sure it used the larger Font 3 (TTF), which is the same font I had set up in the editor for the "Custom text-window GUI" setting. I haven't since modified any of the new advanced font parameters. Maybe having a way to set the console font independent of any other font would work best? The color depth is 32-bit.

Regarding everything else, I must take a break from AGS now for a couple of weeks. I will be able to look into these only after.

No worries!

[Alan v.Drake]

EDIT: Ummmm.... actually.... it "works" because when you comment OnSetNativeSize out, Direct3D fails to initialize, and one of the other renderers initializes instead (OpenGL has priority in the latest build), which do not have same problem.
OnSetNativeSize sets _srcRect variable which is important for successful work of a renderer.

Well, back to square one then. This stuff used to work, so the answer lies here somewhere

- Alan

[monkey0506]

This stuff used to work, so the answer lies here somewhere

[Crimson Wizard]

Well, back to square one then. This stuff used to work, so the answer lies here somewhere

Can you point out a commit where it was working? Or was it your Draconian edition? I did not have time to look much back in history yet.

E: I am using this room background to test this issue (it also helped to see pixel distortion when I was working on OpenGL):

Spoiler: ShowHide

Also, I suggest moving the technical discussion to Engine development forum, or Github issue tracker; this place is to announce releases and receive user feedback.

[Dave Gilbert]

Another thing I noticed is that pressing the Tilde (~) key to bring up the console results in a blank white console with no text in it. This happens for all three graphics drivers (D3D. OpenGL, and software).[/b]
always display properly in with windowed and full-screen mode under D3D, even on Windows 10. Seems that something exclusive to this version has stopped full-screen D3D from working.

This works fine for me on all drivers, but stab in the dark idea. Is it somehow possible to accidentally set the text color of the console window text to WHITE?

[Crimson Wizard]

This works fine for me on all drivers, but stab in the dark idea. Is it somehow possible to accidentally set the text color of the console window text to WHITE?

That was my first guess, but it looks like it has hardcoded black-on-white colors.

[Dave Gilbert]

Unsure if this is the right place to post this, but I discovered an issue with the OpenGL driver and the current Steam plugin. While the Steam overlay runs fine, the usual popups do not appear.

Here's an example of what I mean. This is my opening splash screen running in Direct3D mode:


(full sized version here)

It's hard to see in this image, but the popup in the lower right is what Steam users expect to see when they launch a game. Achievements also appear the same way. With the OpenGL driver enabled, it doesn't appear.

I will also point Michael Rittenhouse to this post, since he wrote the steam plugin!

[Crimson Wizard]

Unsure if this is the right place to post this, but I discovered an issue with the OpenGL driver and the current Steam plugin. While the Steam overlay runs fine, the usual popups do not appear.

This depends on whether this overlay is drawn upon AGS window, or in its own overlaying window. In the first case plugin may be responsible for this, but guess only plugin author can tell.
In the second case that may be an issue with windows Z-order.

[monkey0506]

AGSteam doesn't do anything special in showing the overlay/pop-ups, that is handled entirely by the Steamworks backend. You may check how GOG Galaxy draws its overlay, though honestly I have no idea if it's the same as Steam (the Steamworks API doesn't include access to the sorce code, just the interface). That said, if it works on one DirectX, I don't see why it shouldn't work on OpenGL. Tons of Steam games use OpenGL. I'll ask about it in the private Steamworks dev forums and see if anyone has had similar symptoms.

P.S. Dave, to clarify, the overlay itself still works, just not the pop-ups?

[Dave Gilbert]

Huh. I loaded up my game this morning to check and... it works perfectly now? I double checked and it IS in openGL mode. This seems to be a recurring issue with me. Maybe my computer just needed a reboot. Very strange. Sorry to waste your time with this.

[monkey0506]

Glad to hear that it's working, but "intermittent" is the bane of my existence. Let me know if it resurfaces.

[Crimson Wizard]

Hello, just wanted to say that I got very much distracted from AGS in this month. I will be back to finish this beta starting from this week, and hopefully that won't take much. I recall there were just couple of bugs I wanted to look into, need to remember what they were first.