Gideros 2024.2 Released

hgy29

Hi Giderians,

Newest Gideros is here, this time with nice (IMHO) new features.

TextFields used with cached TTFont (internally known as TTBMFont, the fastest way to draw texts on Gideros), can now be automatically made oblique, underlined or even striked through, by using the new escape sequences below:
- \e[i]Some text\e[!i] for oblique text
- \e[u]Some text\e[!u] for underlined text
- \e[s]Some text\e[!s] for striked through text
Each of these sequences accept an optional parameter, the inclination angle for oblique text, and the line thickness for [u] and [s]. There is also a [l] escape sequence to specify both line placement and line thickness.
Along with existing [color] and [font] tags, this allow showing text with richer formatting more easily.

Second nice new feature is the ability to attach a render target to a viewport. When done so, the Viewport will not be rendered on screen, but on the render target, which can be used later in the scene. This allow shadow maps or any other use case to be computed by Gideros automatically, without needing to do it in lua in each frame.

Third addition, useful for 3D scenes, is the ability to tell Gideros to perform a depth sort of Sprite children in order to render them from the farthest to the nearest, allowing correct translucency effects. This is demonstrated in the updated 3D cube demo.

Have a nice coding!


Full change log:

New features

[export/quest] Implement Scene API
[core/sprite] Add Sprite:setAutoSort(bool) that tells Gideros to depth sort sprite children on draw
[core/viewport] Add Viewport:setTarget(rt) to allow viewports too be rendered automatically to rts
[core/textlayout] Support oblique,underlined and strikethrough styles

Improvements

[backend/gl] Improve buffer management
[core/matrix] Improve API, allow passing vectors on some calls
[core/sprite] Allow passing vectors on some calls
[export/quest] Report menu button press
[export/html5] Better handle WebGL context loss
[examples/cube3d] Use new autosort feature
Fixes


[ios] Clear touches table when a view is dismissed
[plugin/share] Use main lua context for events
[lua/compat] require now assumes dots are path separators
[core/compositefont] Fix space size determination
[core/fontlayout] Tinker with wrappable text layouts handling

Download it from here:
http://giderosmobile.com/download

vitalitymobile

@hgy29
Thank you very much for always taking the time to maintain and update the wonderful features for Gideros! Your passion in your work is always an inspiration to me. Thank you and I wish you lots of health and joy!

pie

Thank you!
May I ask you how to pass the optional parameter in

- \e[i]Some text\e[!i] for oblique text
- \e[u]Some text\e[!u] for underlined text
- \e[s]Some text\e[!s] for striked through text

?

updated wiki https://wiki.gideros.rocks/index.php/TextField

hgy29

@pie, a quick example:

local font = TTFont.new("DejaVuSans.ttf", 20, "", nil, nil)   local tf = TextField.new(font, "Text in \e[u=0.2]Underline\e[!u] Text in \e[i=15]Oblique 15°\e[!i] Custom \e[l=0.3:0.2]line placement and \e[color=#f00]thickness\e[color]\e[!l]") tf:setLayout{w = 400, h = 100, flags = 1280|FontBase.TLF_CENTER|FontBase.TLF_VCENTER} tf:setPosition(0,40) stage:addChild(tf)

For l,s and u, the thickness is a fraction of the text line height.

keszegh

thanks, the viewport rendering stuff should be useful to me too, if it makes this faster. it would be even better if there would be some native way to make multiple render passes. now i need to render to rendertarget in multiple stages which is quite slow.

hgy29

@keszegh, actually there is, through setEffectStack, but maybe it doesn’t suit your needs

keszegh

sounds intriguing, can you give some short example code?

keszegh

this applies or is anything different due to new version?
https://wiki.gideros.rocks/index.php/Sprite:setEffectStack
here i see only one shader, so can you give an example with multiple shaders?

MoKaLux

First of all thank you captain hgy29 for another great release

I am not sure if I found a bug?

local ttf01 = TTFont.new("fonts/arial.ttf", 24, "") local text01 = TextField.new(ttf01, "Now text can be \e[i=15]italic\e[!i], \e[u=0.2]underlined\e[!u], ".. "\e[l=-8.0:0.2]custom line placement\e[!l]\e[l]\e[!l], ".. -- little bug here, need 2 e[l]e[!l] "\e[s=0.3:0.1]strikethrough\e[!s] and a ".. "\e[u=0.2]\e[i=15]\e[color=#f90]mix\e[color]\e[!i]\e[!u]." ) text01:setLayout{ w=400, h=100, flags=1280|FontBase.TLF_CENTER|FontBase.TLF_VCENTER } text01:setPosition(32*1, 64*1) stage:addChild(text01)

When a custom line is in the middle of a string it doesn't seem to catch the closing[!l]? I need to put 2 e[l]e[!l] to stop it.

Viva Gideros

Xman

checks uses of undeclared global variable is not supported?

https://www.lua.org/extras/5.2/strict.lua


In release 2023.5 it still works.

hgy29

@Xman, strict.lua was relying on debug.getinfo to detect top level chunks, which didn't work in luau. I have fixed it for future releases: https://github.com/gideros/luau/commit/a76066717d63b384918ce532042805be1cab79a3

hgy29

MoKaLux said:

I am not sure if I found a bug?

There is a bug indeed, [!l] isn't handled at all. Actually [!u], [!s] and [!l] do all the same since only one line is allowed at a time (you can't have underlined and strikethrough at the same time currently), so you can use [!u] instead, but I'll add [!l] too in a future release. I intend to add a way to add a plain background to parts of texts too in the future.

hgy29

keszegh said:

https://wiki.gideros.rocks/index.php/Sprite:setEffectStack
here i see only one shader, so can you give an example with multiple shaders?

There is a three shader / three rendertargets / four pass demo in Bloom example project.
See effectStack setup at line 139 of effect.lua.

keszegh

i did not digest the example yet completely. one question though, can the same be done with glsl shaders or is it just for lua shaders?

hgy29

It can be done with glsl shaders too

PaulH

Thanks for the update! The sorting of children by distance for 3D rendering sounds promising. I've implemented that directly in one work-in-progress project. I'll be curious to see how the performance compares.

Yan

Very cool!

"Second nice new feature is the ability to attach a render target to a viewport. When done so, the Viewport will not be rendered on screen, but on the render target, which can be used later in the scene. This allow shadow maps or any other use case to be computed by Gideros automatically, without needing to do it in lua in each frame."

@hgy29 explain this please, as I understand if my shadow map is dynamic, I should redraw it any way, isnt?

Now Im doint following:

1) Draw to shader map on temporary RT
2) Apply shade shader
3) Draw to resulting RT
4) Repeat for each light source

Do we have now any performance effort now it this way of drawing?

And one more question, if a want use same feaure with Sprite, do I should create Viewport any way to achieve autodraw?

What I expect is that RT is automatically tooks Viewport as current frame, without needing of using draw. If so does it performs faster, as I have some performance loss in 2024.2 compared to 2024.1 tied with RT draw (details in slack)?

hgy29

@Yan, Yes, this new feature won't bring performance improvements since the same amount of work has to be done on the GPU anyway. The benfits are:
- Done without lua intervention, so slightly faster CPU-wise
- Possibly the RT is computed more closely to its usage, so it could be left in GPU cache and accessed faster by the GPU when rendering
- The RT could be reused several times during the same frame

To use it, assign the Sprite you want to draw on your render target as the content of your viewport (setContent), and sets your render target as the target of the viewport (setTarget). Then add the viewport to your scene in a way that it is drawn before and as close as possible to the Sprite reading in the RT. It won't render anything on screen though.

MoKaLux

@hgy29 can I create a reedit community for Gideros?
I can start it and add anyone of you guys as admins. What do you think?
How should I call it?
- Gideros
- Gideros Mobile
- Gideros Studio
- ???

Thank you!

Yan

MoKaLux said:

@hgy29 can I create a reedit community for Gideros?
I can start it and add anyone of you guys as admins. What do you think?
How should I call it?
- Gideros
- Gideros Mobile
- Gideros Studio
- ???

Thank you!

Would be nice to enlarge Gideros Community, who knows maybe this is next Unity )

PaulH

I'm seeing one odd change in the 3D system. I've got an animated mesh I'm loading and posing bone by bone in the code. Specifically it's a segmented wire with a barbed point on the end, and the code shapes it into various styles of fish hooks. The result is still fine in the 3D scene. My code draws hooks and fishing flies to render targets. If I draw the 3D viewport to a RenderTarget once, it's fine. But if I draw it to any renderTarget again during the same frame the mesh gets distorted, with bones disconnected from one another. It seems as though the system tried to advance an animation after the first time it gets drawn.

Here's a hook drawn that way to two RenderTargets. Ignore the green antenna sticking forward. That's unrelated.

hgy29

PaulH said:

I'm seeing one odd change in the 3D system.

I must say I don't understand what happens here. If animation had advanced one step it should still render ok but in next position. Can you try again with latest Gideros and see if that makes a difference ?

PaulH

My fault. This is with Gideros 2024-2, but I'd forgotten that the project included an older copy of the 3dbase library, since I had added some custom 3d shapes. Bringing in the newest 3DAnimation.lua and G3DFormat.lua solves it. I should move my custom shapes out to different modules and always use the latest copy of the 3D library.

PaulH

The good news is this is fixed in 2024.3. Thanks for that, hgy29!

This has been one of those baffling issues. There's more going on here than just the version of the libraries I was using. With Gideros 2023-2 and its libraries I was still getting displaced geometry in an animated mesh, and not just drawing to a RenderTarget. The distortion of the hook (messed up location of the bones in the animated mesh) only occurs if the scene containing the animated mesh also contains another mesh that's using instancing. What made that really hard to pin down was that it also only happens if there's nothing else to render on the stage, or in the case of drawing to a RenderTarget, if there's nothing else to render in the sprite being drawn to it. If there's even a fully transparent TextField also present, the distortion doesn't happen.

There's one other issue that's still present in Gideros 2024-4, however:

If the code includes (mesh):setInstanceCount() for some mesh but doesn't call setInstanceMatrix() or doesn't call updateInstances(), the player will crash without any error messages to the output window.

hgy29

It could have been caused by the changes in OpenGL buffering strategy introduced in 2024.2 which was causing strange issues depending on GPUs/platforms. It was changed again in 2024.3 in an effort to go back to a known working way while still being smarter in the way buffers are managed. Hopefully its works in all cases now.

PaulH said:

There's one other issue that's still present in Gideros 2024-4, however:

If the code includes (mesh):setInstanceCount() for some mesh but doesn't call setInstanceMatrix() or doesn't call updateInstances(), the player will crash without any error messages to the output window.

Enabling instancing in 3D lua library will make the mesh use a custom shader which expects the per instance matrices to be given to the vertex shader, I guess it crashes in OpenGL driver because the buffer is never bound at all if setInstanceMatrix() wasn't called. I will try to catch this scenario.

PaulH

That makes sense. If haven't done a lot in 2024.3 yet, but so far everything looks good.

Thanks for adding the check for that scenario. It's pretty rare to find a lua error that will crash the player, and I really appreciate that. Debugging would be a lot harder if there were many issues that could crash the player.