AGS High-Priority Improvement Needs

Started by fernewelten, Wed 26/05/2021 12:44:10

Previous topic - Next topic

fernewelten

Quote from: FormosaFalanster on Tue 25/05/2021 07:17:49
It still means that, besides Unity, then AGS is the only one which was used by more than 2 games. Not trying to trumpet AGS here, just trying to get a picture of the situation. In short, AGS is dwarfed by Unity, but it's the only one else that gathered more than a couple users.

In Thinker downloads, 6-7 % were for Linux so far (converting to a proportion of 1 for every 15 downloads). All the others were for Windows. A large proportion of the Facebook viewers came from mobile Facebook (m.facebook.com). So I suspect that there might also be quite a lot of mobile users among the non-Facebook viewers, and all those mobile users might have been very interested in a mobile Thinker but were foiled. But I compiled with 3.5.1 which doesn't offer Android out-of-the-box.

Modern IT distribution being what it is (Windows retreating, Android and iOS coming), game writers might possibly prefer Unity over AGS if it is easier to provide mobile builds with Unity than with AGS.

Crimson Wizard is implementing Object turning functionality, which would let AGS do roughly the same animations easily that you could do with PowerPoint (in combination with Object resizing and the tweening module). That's great to have. I suspect that other adventure building systems have already been able to do this and we are only catching up in this respect. This might also be a reason that coders prefer Unity over AGS.

I think I heard the sentiment that AGS was “good enough” for hobbyist projects but if you want to go professional you need to switch sooner or later (I think from the developers of “Kathy Rain”). That would put AGS into a bad position because then many coders would think it wise to bypass AGS and start with an “adult” system right from the get-go.

AGS doesn't need to lose this particular competition, however: Almost everything within the AGS universe has always been free for professional use ever since Chris Jones' time. You do not automatically lock yourself into remaining a hobbyist if you start with AGS as a hobbyist. But I suspect that over the decades, some very specific issues might have come up that professionals can't do without and if AGS doesn't provide those specific things, then coders will shun all of AGS even if they only tentatively think of turning professional one day.

In any case, being the #2 is still a comfortable position. It is said that in every area with competition only the #1 and #2 survive in the long run. That would still garner AGS a place on the rostrum.

Snarky

Off topic, but…

Quote from: fernewelten on Wed 26/05/2021 12:44:10
Crimson Wizard is implementing Object turning functionality, which would let AGS do roughly the same animations easily that you could do with PowerPoint (in combination with Object resizing and the tweening module). That's great to have. I suspect that other adventure building systems have already been able to do this and we are only catching up in this respect. This might also be a reason that coders prefer Unity over AGS.

I think I heard the sentiment that AGS was “good enough” for hobbyist projects but if you want to go professional you need to switch sooner or later (I think from the developers of “Kathy Rain”). That would put AGS into a bad position because then many coders would think it wise to bypass AGS and start with an “adult” system right from the get-go.

AGS doesn't need to lose this particular competition, however: Almost everything within the AGS universe has always been free for professional use ever since Chris Jones' time. You do not automatically lock yourself into remaining a hobbyist if you start with AGS as a hobbyist. But I suspect that over the decades, some very specific issues might have come up that professionals can't do without and if AGS doesn't provide those specific things, then coders will shun all of AGS even if they only tentatively think of turning professional one day.

Yeah, AGS has some significant holes and weaknesses as an engine (some of which are currently in the process of being addressedâ€"in particular ScummVM support and eri0o's web engine will really change the game when it comes to AGS's platform support problem), but I don't believe Object rotation is one of them. You already had rotation capability via DynamicSprite.Rotate() (though it was limited to 1-deegree increments), and you still won't be able to do the kind of animation you're talking about at high quality because you'd need things like sub-pixel positioning. (Personally I think a more powerful sprite manipulation API via DynamicSprite and DrawingSurface â€" or perhaps support for shaders â€" would provide more value than implementing a completely separate set of transforms for Objects and Characters and Cameras, but that's just me.)

I would say the main things that need to be resolved to qualify as a "serious" engine are:

-Better platform support (particularly on mobile, including things like touch gestures)
-Increased compatibility with professional dev processes (source control, automated builds, division of responsibilities, tests, etc.)
-Better performance for certain graphical operations (and any support for others)
-Better support for saves that don't break when a game is updated
-Unicode support

I know at least some elements of the first two are being actively worked on. I think the last two are currently backlogged.

Laura Hunt

Quote from: Snarky on Thu 27/05/2021 14:42:37
I would say the main things that need to be resolved to qualify as a "serious" engine are:

-Better platform support (particularly on mobile, including things like touch gestures)
-Increased compatibility with professional dev processes (source control, automated builds, division of responsibilities, tests, etc.)
-Better performance for certain graphical operations (and any support for others)
-Better support for saves that don't break when a game is updated
-Unicode support

+ Removing (or at least increasing) the 8 audiochannel limit.

Crimson Wizard

#3
Quote from: Snarky on Thu 27/05/2021 14:42:37
-Better performance for certain graphical operations (and any support for others)

This IS what object rotation was for. DynamicSprite and DrawingSurface operations are using software functions over a raw bitmap, but object rotation is hardware accelerated, and also allows subpixels in certain display mode.
Besides that, you get rotation on all the object's visuals regardless of how many graphical parts or frames there are. With DynamicSprite.Rotate you would have to rotate, save in memory and apply each single frame in animation. That is not the equivalent to Rotate propery in object.

Not sure what do you mean by "completely separate set of transforms". They are one set of transforms, it's just that script API does not have a base class to allow sharing them between all objects. And internal implementation is similarly disjointed. But principally this is all same thing.

What other graphical operations, or sprite manipulation API are you refering to?

Unicode support is among the priorities for ags4, it's just that we don't have a proper ticket for this yet, but we will.

The support for non-breaking saves is only possible if we remove reliance on global object arrays and enforce a globally unique name for each object. Then it will be possible to sync the loaded data with objects correctly.
But in a longer run better support would require to make game objects dynamically created rather than rely on static data read from the game file.

Snarky

#4
Quote from: Crimson Wizard on Thu 27/05/2021 16:58:02
Not sure what do you mean by "completely separate set of transforms". They are one set of transforms, it's just that script API does not have a base class to allow sharing them between all objects. And internal implementation is similarly disjointed. But principally this is all same thing.

I mean that I think we're heading towards a situation where some visual effects can only be done via DrawingSurface/DynamicSprite, while others can only be done via settings on game objects. It makes things a lot more complicated if you want to combine different operations, and probably means that some things that should be possible aren't (take, for example, the case of rotating something and then cropping it to a certain bounding box; I don't see how you would do that via the Object rotation properties). Would it not have been possible to instead get improved, hardware accelerated versions of the DS/DS API?

Quote from: Crimson Wizard on Thu 27/05/2021 16:58:02
What other graphical operations, or sprite manipulation API are you refering to?

Scaling and other transforms (e.g. perspective transforms) and distortions, with control over interpolation method; subpixel accuracy in transforms and positioning; filters (e.g. blur, desaturate); composing sprites in various blend modes (e.g. diff); better control over alpha masks; proper 32-bit color handling for RawDrawing; ability to read actual RGB values from bitmap…

There are a lot of things that would be useful to have. We could also ask Dualnames about the various effects he implemented via plugin for Strangeland.

Quote from: Crimson Wizard on Thu 27/05/2021 16:58:02
The support for non-breaking saves is only possible if we remove reliance on global object arrays and enforce a globally unique name for each object. Then it will be possible to sync the loaded data with objects correctly.
But in a longer run better support would require to make game objects dynamically created rather than rely on static data read from the game file.

I thought this was a really promising approach, and even if it still had limitations it would be an improvement. The goal shouldn't be to handle absolutely every case (that's obviously impossible in principle), but to provide some support for typical, simple changes. (And Dave Gilbert's idea of a way to prevent or at least flag changes that will break saves would also be helpful.)

Crimson Wizard

#5
Quote from: Snarky on Thu 27/05/2021 20:04:41
I mean that I think we're heading towards a situation where some visual effects can only be done via DrawingSurface/DynamicSprite, while others can only be done via settings on game objects. It makes things a lot more complicated if you want to combine different operations, and probably means that some things that should be possible aren't (take, for example, the case of rotating something and then cropping it to a certain bounding box; I don't see how you would do that via the Object rotation properties). Would it not have been possible to instead get improved, hardware accelerated versions of the DS/DS API?

I believe that it is practically possible to feature cropping for the whole object. Of course this cannot be done with "Rotation" property alone, but same is with sprite operations, one "rotation" parameter does not achieve that, it's a combination of parameters and operations. E.g. you define a "canvas" size and each operation will be clipped within that canvas. Maybe we could define "canvas size" for a whole object, and clip every operation within likewise.

Hardware accelerated variants of dynamic sprite and drawing surfaces are theoretically possible, except in current state of the engine that would require significantly larger effort and rewrite. Likely there will be two separate implementations for software and ha modes. Or two separate classes for that even: a class that contains a real bitmap and a class that describes a stack of operations over the image.
Of course not only the dynamic sprites themselves should be rewritten, but the way sprites are applied when preparing a render - all that should be changed.

But even having that, individual sprite editing and object transformation are meant for different use cases. Each of these have their purposes.
Like I mentioned above, whole object rotation is for when you want to rotate their whole view without dealing with each separate frame. Or rotate a composite object like GUI which have also child objects on it.

Uniform set of operations in theory may be the final goal. Where same operations may be applied to any component of an object in a hierarchy, complementing and overiding each other in a certain order.
For example: sprite -> frame -> loop -> view -> game object.
Iin principle there should be no difference between rotating and cropping a sprite and rotating and cropping a whole object.

What blocks this is mainly that AGS engine has each object and thing implemented individually, so you have to remake same operation multiple times differently (more or less) for different types. I don't think a good progress is possible without first remaking much of the drawing (and not only drawing) logic, that all game objects would share.

To give an example, GUI currently are drawn using software methods, they have all their controls painted on a bitmap first, then converted to a video texture. This means that it would be impossible to apply a hardware accelerated version of DynamicSprite to GUI or one of its controls without first converting it to a raw bitmap. There may be other similar cases.


EDIT: fixed spelling....


Quote from: Snarky on Thu 27/05/2021 20:04:41
I thought this was a really promising approach, and even if it still had limitations it would be an improvement. The goal shouldn't be to handle absolutely every case (that's obviously impossible in principle), but to provide some support for typical, simple changes. (And Dave Gilbert's idea of a way to prevent or at least flag changes that will break saves would also be helpful.)

I am not going to return to that anymore. The approach was not promising at all, it had very narrow use case and alot of potential for giving false expectations and then screwing things up.

Crimson Wizard

#6
I'd also add that it's theoretically possible to add shader support in a naive way:

Code: ags

builtin managed struct Shader
{
    /// Create pixel shader
    static Shader *Create(const string shader);
};


And then let attach that to an object, or whole screen.

This way the shader will have to be compiled though, and also depend on renderer (DirectX shader, OpenGL shader, and so on will have to have separate shader scripts).
Because compiling a shader is not supported by all the systems, we may have to additionally support loading precompiled shaders from resources.

Anyway, I just realized this all is very much offtopic here. AGS development have long suffered from random ideas thrown in then implemented sporadically or forgotten. That would help if this all would be discussed thorougly to determine a roadmap for these and similar changes.


eri0o

#8
About unicode, do you have an idea on the order to tackle? It's a ton of areas to cover... I guess text display has to come first so we see the results? This could be tested by hardcoding a utf-8 string somewhere near the gfx drivers and seeing what appears on screen... But I mean, we have to start somewhere, it's not possible to do everything at once.

Crimson Wizard

We do not have to do everything at same time of course, some if not all of the mentioned parts could be done separately. It's just that certain texts will get broken until everything is completed.

But if you like to test by seeing fonts on screen, then definitely font renderers is the first thing to do. These are classes TTFFontRenderer and WFNFontRenderer, and any utility code they use (like alfont & freetype library).

Graphic drivers do not deal with the text at the moment, they receive it ready drawn on bitmap.

eri0o

Ah, very cool, everything is in Common then, which is a smaller surface to work with than the engine.

Crimson Wizard

Also opened a proposal list for 4.0.0 milestone: https://github.com/adventuregamestudio/ags/issues/1298

This is a draft for now, but my intent was to emphasize which tasks should be top priority.

eri0o

Accelerated GUIs would still draw sprites of buttons and other elements and then manipulate them in an accelerated HW accelerated I think, at least to work with what's available.

There's a very interesting PR that's cooking for SDL 2.0.16, that adds vertex support for SDL Renderer, it would allow drawing triangles with it. So in the future it may be possible to use this to draw things directly, but there would be some effort to convert things. The API is being done so it would be possible to support imgui in the SDL Renderer which currently isn't possible and is a pain point of many game devs that wants to use both.

Crimson Wizard

#13
Quote from: eri0o on Sat 29/05/2021 02:37:05
Accelerated GUIs would still draw sprites of buttons and other elements and then manipulate them in an accelerated HW accelerated I think, at least to work with what's available.

Sorry, but could you elaborate, because I don't think I understand what you meant here?

eri0o

When no sprite is assigned to a button, AGS draws a gray button Instead. Same for slider. If you resize those in script, they get adjusted too. I imagine if the hardware accelerated part needs to work with the sprites when they are assigned, to make things easier, when there's no sprite assigned the gray version of these GUI Controls would be generated as bitmaps still.

Crimson Wizard

Quote from: eri0o on Sat 29/05/2021 03:45:59
When no sprite is assigned to a button, AGS draws a gray button Instead. Same for slider. If you resize those in script, they get adjusted too. I imagine if the hardware accelerated part needs to work with the sprites when they are assigned, to make things easier, when there's no sprite assigned the gray version of these GUI Controls would be generated as bitmaps still.

Yes of course, in the current system there has to be a raw bitmap created first, so, similar to the text overlays, these controls would have to generate some bitmap to be converted to texture by a renderer.

Crimson Wizard

#16
So, I looked into how Allegro lib supports Unicode, and apparently it has a set of functions that switch their meaning depending on mode. This is not the fastest (perfomance-wise) solution, but this may allow to have a switching mechanism to support both ASCII and UTF-8 modes in one engine with minimal changes to the code.

I did a small experiment to see how much changes would it take to just draw UTF-8 texts loaded from translation file with properly split lines, and basically this is it:
https://github.com/ivan-mogilko/ags-refactoring/commits/ags4--unicode1
(with this test build I was able to display utf-8 encoded TRS with a proper unicode font)

So, theory is, if we could add some data field to the game files to tell their encoding, engine could switch between ascii and utf-8 even in realtime, and thus support both kind of data (thus retaining backward compatibility).

Full unicode support would of course require more changes. For example, any char-by-char string manipulation in scripts will not work correctly with unicode ones - unless we add new API for getting unicode characters. And text input requires different handling.

Still I feel like complete idiot for not trying this years ago...

Mehrdad

It's really great news CW.
If you add it I can write Persian font easily in AGS. I can help you for any test if you want

My official site: http://www.pershaland.com/

Cassiebsg

There are those who believe that life here began out there...

FormosaFalanster

Wait, do I understand correctly I'll be able to use traditional Chinese characters?

SMF spam blocked by CleanTalk