Messages

I found and fixed another mistake, it only affected player character view, because it was precached before the "smooth sprites" option was initialized properly.

Here's the link to the next test build:
https://cirrus-ci.com/task/6171769649758208

No problem! Can I DM you a link on Discord?

I can't get to discord at the moment, could you PM me on forums instead?

Is it possible to get the compiled game, in case it differs from my test?

I tried it and the pink pixels are still there.

Are you sure that you rebuilt and ran with that new version? I compared the one before and this new one, and earlier had pink pixels, while I do not see any with the one linked above.

A room change command (such as ChangeRoom) is not executed right away, but is scheduled and executed when the current script ends. If SetAsPlayer triggers a room change, then the room change is also scheduled and executed after your script.

You need to stop your script right after cNPC.SetAsPlayer(); and perform the rest of commands in that room's "After fade in" event.

What happens if you swap cNPC with Player in the rest of the commands after SetAsPlayer?

Nothing will be different, as using "player" and a player character's name produce equivalent results.

Sorry, I screwed up something in the build server, ordered a new build while the previous was not ready yet. There will be a new build after a while here:
https://cirrus-ci.com/task/5264716513148928

@Honza, alright, this appeared to be simply a messed up setting inside a renderer. The mistake occurs with the following combination of options:
- nearest neighbour filter (not with linear one)
- smooth scaled sprites on

Please try the following temp build and see if it fixes all occurrences of pink pixels:
https://cirrus-ci.com/task/5264716513148928

I did not mean that your game is a mess, it's the engine is a mess in some places.

The GUI that is causing this is a fullscreen GUI called "gInterface". I noticed that it's in users habit to create fullscreen transparent GUIs with only couple of items on them on the edge. Unfortunately, engine cannot detect that its made of transparent pixels, so it thinks that it covers whole screen. It has a rule which makes it ignore such GUIs when adjusting speech text, and that rule got somehow broken in this release.

Anyway, it turned out that the mistake was just a math error.
The fixed build may be downloaded here:
https://cirrus-ci.com/task/6198851733815296
(it may be ready in 10-20 minutes after i posted this)

@lafouine88 I confirmed that this is because AGS is trying to move the speech position away from GUIs, but the logic there is a strange mess and has unexpected results.

In 3.6.2 I have corrected one weird condition that was only meant to work in 320x200 games, making it work similar in any resolution. Apparently, this affects your game now.

I will need to rethink the rules of this adjustment and fix this.

So, this is a HLSL shader, and it needs a "<shadername>.d3ddef" file in case you are using custom constants. This is explained in the first post.

Example of d3ddef file for your shader:

Code: ags

[constants]
iTextureDim = 2
iAlpha = 3
iOutputDim = 4
iScanlineIntensity = 5
USE_XBR = 6
USE_CRT_SCANLINES = 7
USE_SUBPIXEL_AA = 8

Then, you do not need a SCALE_FACTOR for the full-screen shader, instead use "iOutputDim" built-in constant - it tells final resolution of the fullscreen texture.

I tried to had a function like this but it didnt work:

Please post the shader code itself. I cannot tell what's the link is pointing to, because unfortunately it returns error to me.

Shader compilation results are written into the engine logs. These may be seen in Log Panel when you run from the Editor (you have to setup Main message group output to Debug in order to see these).

Built-in shader constants, such as "iTextureDim" and "iAlpha" are set by the renderer automatically based on the sprite/texture parameters or game state. You should not be setting these yourself, as their values will be overwritten anyway.

I'd like to encourage users to upload their test games with shaders and post links here, preferably with shader scripts. This may be used as a demonstration for those who are curious, and those who do not know shaders well.

For the reference, shader scripts do not have to be packed inside the game of course, they may also be placed just in the game's folder (or subfolder) and loaded from there at runtime. This makes them more visible (better serving demonstration purpose).

Could you upload a single sprite that has this issue for us to try in both old and new versions?

I would argue that, whenever possible, a cutscene should be wrapped in its own function.
(That does not mean that all the cutscene code should be inside same function, it may be split into multiple functions, but they all called from a "central" function).

Indeed, anything occuring during a blocking action will be coded in repeatedly_execute_always, but the action itself can be controlled from the "cutscene" function.


About room changes: If your cutscene is played across multiple rooms, then use "if (Game.SkippingCutscene())" condition to skip to the final room instantly. That will save engine from doing alot of redundant work loading and unloading rooms, and also will make the skipping much faster.

That is unless you follow a previous suggestion by Snarky and want to divide cutscene into multiple parts, each in its own room.

If I attach a shader (eg. to Screen.Shader) then I can't assign another shader to it? I am passing the shader to null before assign it a new one but it doesn't seems to be working, i might be doing something wrong.

I tried this, and it works correctly when I switch Screen.Shader to another shader instance. Please post the code that you are using.

If I attach a shader (eg. to Screen.Shader) then I can't assign another shader to it? I am passing the shader to null before assign it a new one but it doesn't seems to be working, i might be doing something wrong.

Maybe there's some mistake in the engine, i will double check that.

Also for some reason if i run the game from the exe i don't see any shaders at all but its working fine in the editor.

There may be 2 reasons:
- you forgot to do Build EXE, and the exe in compiled folder remains an older version without shaders.
- somehow the exe uses a different config with another gfx driver set (that's unusual, but may happen in theory).

There's no way to directly access other room. The usual way is to make a global variable, set it in room 2 and check in room 1's "before fade in" event, and setup the object accordingly.

Also, there's no need to use "object[1]", room objects can be given explicit script names and addressed using these names in script, like oPizza.Visible = true.

About GUI's I have many on screen. All lifebars buttons etc. plus one that I just use for tests which is the yellow,red,blue,green and black lines to the right. I tried deactivating this one plus some others that could have interfered. But none of them seem to be the cause.

I'll try some more things tonight and let you know if I find something. Still, this whole thing is pretty weird, especially if I'm the only one getting this problem^^

If you could PM me the compiled game, then I would run this under debugger and see what's engine is doing there.

In regards to the above problem, I got a PM from lafouine88 with more screenshots, it did not answer all the questions I had, but gave me an idea that this may be related to how GUIs are positioned on screen, and AGS trying to adjust the speech position because of GUI. Possibly something was broken in that logic. Unfortunately I was not able to reproduce this so far, it may require very specific combination of GUIs on screen. I'll keep looking.

Issue: error when hitting Enter key in the open text parser window in the editor while no list item is selected:

• Open Text Parser window from the project panel
• Have no list item selected
• Hit enter key
• 'Object reference not set' Error

The error msg:
Error: Object reference not set to an instance of an object.

Looks like this bug is present at least since AGS 3.2.1.