Open ivan-mogilko opened 3 years ago
As a "note to self", following tasks may be a priority for me:
1) Script RTTI, which enables managed pointers inside managed structs (#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 #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.
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.
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.
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.
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.
@ivan-mogilko I opened an issue #1838 with a few screenshots
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)
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.
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: https://github.com/adventuregamestudio/ags/issues/1391#issuecomment-1166385188 We might need to create a proper dedicated ticket for this instead.
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:
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.
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.
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.
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
#469, #1008, #1281
Preference tasks
related - #1349
also see comments to this older "post-3.6.0 roadmap" ticket: https://github.com/adventuregamestudio/ags/issues/762#issuecomment-1534268069
#1980, #2501
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.
#1259, #1923