AGS 3.4.1 - RC 3 (new release candidate)

Started by Crimson Wizard, Sun 09/04/2017 22:02:10

Previous topic - Next topic

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

#101
Fixed typo in the link. :tongue:

AGD2

#102
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.

https://youtu.be/Oe0UlOpH6po

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:

Quote from: Crimson Wizard
Quote from: AGD2For 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

#103
Quote from: AGD2 on Wed 28/06/2017 04:11:10
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

#104
Quote from: Crimson Wizard on Tue 27/06/2017 16:20:24
- 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

#105
Quote from: Alan v.Drake on Wed 28/06/2017 21:47:28
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

Quote from: Crimson Wizard on Wed 28/06/2017 22:40:29
Quote from: Alan v.Drake on Wed 28/06/2017 21:47:28
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

#107
Quote from: Alan v.Drake on Wed 28/06/2017 23:17:41
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.


Quote from: Alan v.Drake on Wed 28/06/2017 23:17:41
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

QuoteThat 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.

QuoteRegarding 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

Quote from: Crimson Wizard on Wed 28/06/2017 23:38:47
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


Crimson Wizard

#111
Quote from: Alan v.Drake on Thu 29/06/2017 07:45:57
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
[close]

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

Quote from: AGD2 on Wed 28/06/2017 04:11:10
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

Quote from: Dave Gilbert on Thu 29/06/2017 14:46:10
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

#114
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

#115
Quote from: Dave Gilbert on Sat 01/07/2017 00:15:26
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. :-X 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.

SMF spam blocked by CleanTalk