AGS 4.0.0 Milestone proposal

[ivan-mogilko]

I'd like to begin setting up certain milestone for a first ags4 release, to help with prioritizing tasks. IMO there are few tasks that must be done and without which completion there's not much point in releasing ags4, at least not as a major "ags4" version. Then come things that would be very nice to have but that have less priority - I'd call these "preferable".

This list of course does not mean that other things should not be added or worked on, but whenever possible it's best to choose one of the priority tasks.
The list may be amended. Also there's now a new milestone for 4.0.0 to use for related issues.

For the reference, couple of older tickets related to ags4 planning: #450, #1121

---

Priority tasks

Task	Issues	Comments
Unicode support	DONE (3.6.0)	Essential to allow better multilanguage support in games
Open game project format	WIP #469, #1008, #1281	For easier use with source control, teamwork, be able to manage project outside of an editor
Stand-alone build tools	3.* tools milestone	Got to be able to compile full game without launching an editor. NOTE: will be partially done in 3.6 branch, but some tools will be specific for ags4 after the planned project format changes.
Deploy games for Android from the Editor	DONE (3.6.0)	There's an Android building plugin for the editor created by monkey0506 which could be integrated in the editor accompanied with proper instructions in the manual.
Deploy games for Mac OSX from the Editor	#1333
Extended input device support (joystick, touchscreen)	PARTIAL #1364, #1538	Should include script API and script callbacks necessary to code all interactions, similar to keyboard and mouse.

---

Preference tasks

Task	Issues	Comments
Refactor the engine code	TBD	Major refactor and tidy of the code base is long overdue, but sadly stopped years ago (except for few distinct parts). We need to clean up and nicely separate the base engine and game logic code if we want to work in it efficiently.
Separate game update and render threads	TBD; related - #1349	Could be added / backported in 3.6.x update too, if possible without breaking backwards compat. also see comments to this older "post-3.6.0 roadmap" ticket: #762 (comment)
True 32-bit color values in script	#1980	AGS historically has colors converted to 16-bit RGB in all related variables. Some exact colors are not accessible this way. Instead it should be 32-bit, even with alpha channel.
Hardware accelerated GUI controls	DONE (3.6.0)	GUI controls are currently the only objects that are not converted to textures, but always drawn on a parent GUI surface using software method. This is inconvenient for various reasons.
Hardware accelerated DynamicSprite	#2059	Dynamic sprites are currently manipulated in software mode only, writing an implementation for 3D renderers too might enhance rendering perfomance and make further expansion of its API with new effects more interesting. But this may also require adjusting a way of how sprites are refered to and handled in the engine.
Better Audio playback API	TBD	Current API is based on working with AudioChannel (slot) object on which a clip is playing, which is inconvenient for various reasons. One alternative is to implement something like a AudioPlayback object which defines a played instance of a clip resource. AudioChannels may still have some uses, but work more as a way to organize simultaneous playbacks. Another interesting thing to consider is a Audio Mixer, and arbitrary effect support; where possibly user would be able to mix different clips together and add effects to them. This would require some good API plan.
RTTI and full managed pointer support in scripts	DONE; #1259, #1923	There's a new compiler by fernewelten with some good additions, but adding full pointer support in managed structs will resolve a multitude of scripting probems at once.
Parent class for game objects	#1228	Adding new common properties becomes an inconvenient task because we have to add these to each game class separately.
Better translation system	WIP #1780, #1986	Also see comments in an old ticket, and also couple of the forum threads one and two.
Proper modern TTF font render	#1528	Move from using alfont + very old freetype, and start using contemporary TTF render libs; possibly SDL_ttf

[ivan-mogilko]

As a "note to self", following tasks may be a priority for me:

1. Script RTTI, which enables managed pointers inside managed structs (AGS 4: RTTI for AGS script #1259). I did a successful experiment a while ago, but unfortunately got distracted by other tasks and never finished it. The implementation seem not much complicated and mostly requires cleaning up new data format and tidy the code. The experiment was done on an old compiler, but the data format should be the same with the new compiler, perhaps only the way the data is gathered during compilation may differ.
2. [DONE] Fix rotated GUIs. Since the gui controls are now rendered as individual textures, they have to be clipped to GUI borders using Clip/Scissor method in 3D renderers. However this does not work when GUI is rotated, as the scissor rect must be orthogonal on screen. From what I've read this may be resolved either using shaders, or stencils. Stencils, in this case, may be used to create a sort of texture mask of any shape and position. I did a small test before, and this method seem to work, but will require some enhancement to the sprite batch rendering code first (see Make sprite batch parameters more consistent #1708). TODO: write a ticket about this problem. TODO2: also this reminded me that GUI controls are missing individual Rotation. That might be easy to implement with textures (only problem is to update click detection), but there's also software render mode...

Also, if I manage to complete these, I'd look into the new sprites storage in project (#1281). I recall that @persn started working on it, but I have not checked it yet.

[AlanDrake]

For point 2 you could render the whole GUI into a single texture, no?.
Currently, a GUI with some Transparency has its elements overlap opacities individually, instead of just the final result having that set opacity.
Maybe it could be fixed by changing alpha blend modes to replace, but still I think a GUI is best represented by a single texture.

[ivan-mogilko]

For point 2 you could render the whole GUI into a single texture, no?.

Are you referring to making a texture a render target (similar to how the whole game could be rendered to a texture in "native resolution" mode), or to drawing whole gui with controls on a single bitmap which is then converted to a texture?
The point of the recent change was to not draw controls on one bitmap, but render as separate prepared textures, which improves performance in hi-res games, and allows faster render effects (see #988, #1393 for details).
If you mean the render target, that's one method I did not consider, somehow; I may try that too.
EDIT: I remember now, there's a hypothetical issue of rendering texts in the screen resolution (high-res fonts in low-res games), which might conflict with this approach, unless there's some workaround...

Currently, a GUI with some Transparency has its elements overlap opacities individually, instead of just the final result having that set opacity.

GUI control's transparency was just added in 3.6.0, are you saying it's not working right? I recall that the idea was that the actual control's opacity = gui opacity * control opacity.

[AlanDrake]

Are you referring to making a texture a render target

Yes, unless stencils or shaders work better. Unfortunately, I'm weak with render stuff, so I know no better than the simplicity of a texture.
I'd imagine one day we may be able to specify if certain viewports or parts can be rendered at specific resolutions, and positioned around the screen dynamically via script, if we ever get to support non-fixed game resolutions.
Maybe unrelated to this case and not important now, but should be considered for future decisions (or not).

I recall that the idea was that the actual control's opacity = gui opacity * control opacity.

But in that case, with a transparent GUI and a control inside, you get this:

I guess this would be solved by stencils, if I understood what I read.

[ivan-mogilko]

Opened a dedicated ticket about the GUI clipping problem: #1837

@AlanDrake

But in that case, with a transparent GUI and a control inside, you get this:

Could you open a bug ticket, with some information about how gui is composed (or a test game)? I am not certain if this is a transparency bug, or a clipping bug. But there's a chance this is also present in 3.6.0.

[AlanDrake]

@ivan-mogilko I opened an issue #1838 with a few screenshots

[ericoporto]

Hardware accelerated DynamicSprite

I would postpone this (4.2), designing the API for this won't be trivial.

Better Audio playback API

I would postpone this (4.2) too, designing the API would eat a lot of time, plus there's a suggestion of switching how sound works (for effects), let's use what we have at least in the first 4.0 release.

This is only something in 4.0 if we have to make 4.2 compatible with 4.0 for the sound API, which can be hard if the change is too big.

Stand-alone build tools

We can advance this but switching how the editor works for this is something we should postpone for 4.2 if possible.

---

Overall we should reduce the scope, as polishing/bug fixing tends to take twice the time at least from making a new feature and there are a lot of new features.

I would also suggest flipping the new compiler as "the compiler" and the old one as "legacy compiler". We also need to fix autocomplete for the new compiler features (like .Length but I think there are other things)

[ivan-mogilko]

Splitting the above list is fine. This ticket could be renamed into "priority list for 4.+", and a new one opened, with a narrow selection. It should also include tasks for testing and/or fixing existing features. One good example is custom BlendModes, that probably will have to be reimplemented as shaders to work properly (the reasons are explained in #1885).

I also may suggest that for the early development of 4.* the focus should be set on the improvements that affect larger scale, and larger range of users. Meanwhile it's best to not bother with minor additions, and minor issues that already have a solution or a workaround, even if latter are not perfect.

[ivan-mogilko]

There's no actual ticket for this yet, but might leave here for a reference: since there are few major additions planned related to the input (joystick and touch screen API), imho we should also consider reorganize existing mouse & key API and make everything similarly flexible and consistent.

For instance, instead of (or along with) on_key_press and on_mouse_click have separate on_key_down/up and on_mouse_down/up.

Also, perhaps, have an ability to detect whether a device is connected (mouse & keyboard).

In regards to a keyboard, there is a long existing problem of a non-QWERTY keyboards being more difficult to handle in script. This is briefly explained in this comment to ticket #1391:
#1391 (comment)
We might need to create a proper dedicated ticket for this instead.

[ivan-mogilko]

Back to this, I suppose we should beging to wrap the AGS 4 up, and decide on which minimal tasks out of the "big tasks" list should be a part of the 4.0 release.

I think that these two are good candidates:

• True 32-bit color values
• Update TTF renderer (use latest FreeType version)

Because both of them are improving existing and commonly used functionality, while likely to break backwards compatibility.

Also @ericoporto has been working on a touch API, which will also be a nice addition, would it be done in time.

[ericoporto]

The touch "API" is working, the issue is not the API itself, it's multi-touch support on GUIs. :/

Outside of this big issue in ags4 is what to do about the manual.

[ivan-mogilko]

The touch "API" is working, the issue is not the API itself, it's multi-touch support on GUIs. :/

Is the GUI problem blocking touch API somehow, or is it a side problem? Perhaps you could add touch API first to let users use that in script, and leave GUI problem for the later?

EDIT: I think the existing GUI input handling has to be rewritten anyway, there's something wrong about how it's organized in code.