Messages

Thanks, I made a note about using SetTimer(TIMER_ID, 0) too.

Here

https://adventuregamestudio.github.io/ags-manual/Globalfunctions_General.html#gettimerpos

@Crimson Wizard , I documented this behavior in the docs https://github.com/adventuregamestudio/ags-manual/wiki/Globalfunctions_General#gettimerpos

Ahh, ok, I will change the code to use IsTimerExpired!

I tried to use this function by adding the following in the room script (and properly linking it)

Code: ags

function room_AfterFadeIn()
{
  SetTimer(1, 10);
}

function room_RepExec()
{
  int timeLeft = GetTimerPos(1);
  if (timeLeft == 0)
  {
    System.Log(eLogInfo, "Timer 1 is not running");
  }
  else if (timeLeft == 1)
  {
    System.Log(eLogInfo, "Timer 1 is about to expire!");
  }
}

Now the result of this code is that I get the following log

Code: text

[Main][Alert]: Adventure Game Studio v3.6 Interpreter
Copyright (c) 1999-2011 Chris Jones and 2011-2024 others
Engine version 3.6.2.3, 32-bit LE

[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
[Script][Info]: Timer 1 is about to expire!
...

Yeahp, it goes like this forever. I thought it would give a ton of Timer 1 is not running logs, but actually that branch just never happens. I think there is either a bug in the implementation or I am doing something incorrectly that I can't understand.

Uhm, perhaps it was, I searched for PRs with the word stencil but didn't found anything relevant, so don't remember.

I guess the issue is much higher in the design of the API. Doing DynamicSprites as hardware accelerated is hard - at least in my head there are things I am unsure - but a different API, I think very few commands like in my imgi module would suffice (note it uses Dynamic Sprites, but I was thinking in an abstract world)

https://github.com/ericoporto/ImGi/blob/d5aec7a977adf16e23fa5b3518e083ecef29a7b9/imgi_demo/imgi.asc#L2766

From this, I think only the draw sprite and the stencil would be actually hardware accelerated and the rest would be pushed through the draw sprite itself with an intermediary bitmap drawing. Can't tell if this would actually make things faster.

@Crimson Wizard when you were looking into cameras rotation I think, I remember you saying something about stencil, I don't remember what or exactly the details, but are those like something for a clipping mask?

Thinking a bit on the clipping mask idea, I guess this would be like, you stamp a list of overlays in a buffer and then sample the alpha from this buffer and the colors from a second buffer to then write ove this second buffer which then you use it as texture to something (perhaps an overlay).

Just thinking about this in this way in my head feels like the idea of hardware accelerated drawing sprite.

But in this specific case I agree I would try using copy transparency and see if it is slow for it - my guess is the resolution is low enough and the object is small enough it would just work fine.

For this error specifically, 3.6.2.x has save file pre-scanning added, so one could handle pre-checks and prevent such errors.

I guess one day we will move to SDL3, it has SDL_gpu, which is really new (so probably lots of bugs) but it works with their satellite project SDL_shadercross, which is also very new (probably even more bugs!). The advantage here is that would make one shader language that can then transpile at runtime to other shader languages that then can be compiled by whatever is the graphics driver in use.

The big problem of adding shaders in the engine afaict is that each graphics driver has its own language, which would make harder to run the games later in different platforms. This is why I think making it possible to translate between languages could be an interesting idea. But this is a hard problem that isn't worth to implement in-house, it's better to bring an external library. Then in the case of SDL_gpu it would require also to write a new graphics driver for it, which isn't a small endeavor, since it uses concepts and ideas from newer APIs like vulkan that are much more verbose and complex than the classic ones we currently use.

About SDL_shadercross, it brings dependencies on additional dlls and things that will make AGS bigger and also additional files that needs to be in the folder where the game is, so if there is some other solution it may be interesting to look into them too. Other issue is because it is still experimental it appears to only be compatible with Linux and Windows for now - there is no metal for iOS/macOS yet or anything proper for Android or Web. I think they will get there one day, but just it is not there yet afaict.

Of course there is also an approach to make shaders API give the opportunity for the game dev provide both the D3D and OGL implementation, which would simplify all of this and make it not that hard to get it in the current drivers but it would have to have a careful API that lets the gamedev handle shader compilation failures at runtime in a graceful way. This would in theory not be that much code and the burden would be more in the design of API - I imagine it could start with just attaching a shader to the screen after everything is draw and then add something in the API to let it attach shaders to the game objects (character, room objects, overlays...)

I guess in the end given the current state of everything I would lean to come up with our own solution. Other issue is we don't have either shared graphical property or parent game object class - say with all things that are in an overlay - so if done before this, it would require copy pasting the changes of the shader API across all things.

I think in my head the API would be something with two objects, a ShaderDefinition and a ShaderObject (or just Shader) , and there would be a static ShaderCompiler thing that would take the ShaderDefinition and produce the ShaderObject. Then things like characters, room objects and overlays would be able to get a ShaderObject attached to them. This is all first draft idea.

Aaahh, I didn't knew it was the autocomplete only, I need to make a small test - probably will steal your code there - and look into where it is wrong. Thanks!

This is more to kick the ball on something...

Currently if you have a managed struct that extends another managed struct, and extension methods on the parent managed struct, the struct that extends it doesn't get the extensions from the first.

Should it get? Should it not get? What is the expected behavior here?

Someone somewhere is rediscovering Adventure Games in this article https://www.vice.com/en/article/point-and-click-adventure-games-are-entirely-too-slept-on-but-these-devs-are-keeping-them-alive-and-well/

I thought I had a thread somewhere for adventure games in the media, but I didn't and I guess the thread name here is similar 

More a note for future person doing this, DynamicSprite.Flip supports horizontal, vertical and both as flip possibilities through an enum.

But views traditionally only flip horizontally. This is why in the current graphics drivers (D3D, OGL, Software) only the horizontal flip is implemented. If we want to support all directions of a DynamicSprite.Flip it would require supporting those directions at the graphics driver.

If you ignore different keyboard layouts, ignore anything beyond English, and can do some scripting, you can hack your Game.InputBox like by using the wait functions with their skip reason

https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Wait.html

You can still use the mouse input as skip reason combined with their positions if you also want to accept hits in a keyboard image (say for minimal touch support). Also forget the textbox, use a label and then assemble the text and use the label to present the text.

Anyway, not pretty but can be done without too many lines.

This is merged so it should make into the next 3.6.2.x and 4.0.0.x releases.

I noticed it went unmentioned in last release notes here on the forums but there's an additional fix for the watch pane that could make the engine unresponsive if one "step into" too fast -  this made it hard to use the watch pane, but the latest 4.0.0.11 also fixed this, so now debugging is much smoother.

About the blending modes, the way they are currently implemented relies on DirectX and OpenGL own implementations, and I guess it may require some of those premultiply alpha settings.

They would be less driver dependent if we used shaders, but there is a detail here that the current use of shaders in the engine, for tint (color and lighting) and transparency, only depends on the data in the texture of the sprite itself. With blending modes the shader has to depend on the information "below", but currently, in the gfx drivers the previous drawn sprites aren't "rasterized" (or "flattened"), so it's not clear how one would get the information of the pixels below, I guess once it has to draw a sprite that has a blending effect it would need to "flatten" so that we can pass each pixel info to the shader drawing this sprite. Beyond investigating implementation there would be a need to check performance impacts, if any.

Here is the corresponding github issue https://github.com/adventuregamestudio/ags/issues/2131

I think we never got around to figure a proper new text to add in place, perhaps a copy and paste of https://adventuregamestudio.github.io/ags-manual/Copyright.html, and maybe a minor note on top saying AGS Editor is free software and commercial usage is allowed free of charge, and tell about the copyright info below.

Built for AGS 3.6.2.x from the CI here

https://cirrus-ci.com/task/5442950715408384

As always if you are testing it please backup or test it with a throwaway project.

Some domain problem with the registrar caused itch io to be down. Since a few people here put their games there, just mentioning it here in case you try to load the website and it just keeps failing.

More details on hackernews .

Edit: I guess it is loading again, but haven't seen official communication on it yet.

That is expected, the way it works is you have to disable the textbox you don't want to capture input and enable the ones you want to capture. There isn't anything like focus or selected state in GUI controls.