Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Gideros 2021.9 Released — Gideros Forum

Gideros 2021.9 Released

hgy29hgy29 Maintainer
edited October 15 in Announcements
Hi folks,

Do you know that feeling, when you've been trying to implement a feature for a long time but you couldn't for a varierty of reasons (complexity, cross platform issues, lack of lower level API, etc), and then you suddenly realise, years later, that you can now do it ?

Well that's what happened a few weeks ago, when I realized that nowadays all platforms Gideros target are supporting C++11. And with C++11 comes a lovely feature: Lambda-expressions. Of course we knew them already in lua (they are closures), but they are relatively new in the C++ world. And thanks to those lambda, writing continuation functions for multithread/deferred/async processing is much much easier.

So that's it, a long awaited feature is finally availble in Gideros 2021.9: the ability to asynchronously load textures. Internally Gideros will do all the heavy stuff in a side thread, not blocking the main rendering thread, and trigger a callback when the Texture is ready to be used. This allows smoother animated loading screens.

Another great thing available in this new version: multi font and even images in TextField.
This was made possible by three changes:
- a new TexturePackFont object that allows to turn a TexturePack into a font, usable by TextField
- a change in CompositeFont, that allows individual fonts to be named
- a new escape code in TextField: "\e[font=name]" that allows you to select which font to use for a chunk of text inside a TextField, if a CompositeFont is used.

You can then build a CompositeFont with several fonts (normal, bold, fancy, texturepackfont) and render all of them in a single TextField. Associated with Gideros powerful text layout options this ease things a lot!

Full list of changes:

New features

[core] Add Texture.loadAsync() call
[core] Add TexturePack.loadAsync() call
[core/font] Allow multiple fonts in a single TextField
[core/font] Allow to turn TexturePacks into Fonts

Improvements

[core] Support grayscale render targets
[core] Add TexturePack:getRegionsNames()
[tools] Associate .tproj and .GApp extensions so that they open the required tool
[plugin/camera] Add a setOrientation() Call (iOS, Android)
[plugin/share] Allow setting of photo library usage (iOS)
[plugin/virtualtntpad] Update
[export/html] Update to latest emscripten (2.0.27)
[export/html] Support APPLICATION_SUSPEND/APPLICATION_RESUME

Fixes

[core] Fix rendering 3D in render target
[player] Allow setting FPS from lua
[player] Fix Open project and Restart project menu actions

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

Don't hesitate to donate while downloading to support Gideros, or anytime using the 'DONATE' link at the top of the forum page.
Tagged:
+1 -1 (+6 / -0 )Share on Facebook
«1

Comments

  • async texture loading is surely a cool thing, thanks @hgy29 .
  • hgy29hgy29 Maintainer
    Forgot to mention, async loading is not working in HTML, due to a limitation of emscripten. The code will run, but synchronously
  • hgy29 said:

    Forgot to mention, async loading is not working in HTML, due to a limitation of emscripten. The code will run, but synchronously

    and i guess the callback will also happen.
  • hgy29hgy29 Maintainer
    yes

    Likes: keszegh

    +1 -1 (+1 / -0 )Share on Facebook
  • Bug report:
    Bump's
    world:project(...)
    does not work
    First, without filter function player just crushes. Second, this function return another function and a number, but should be table and table len.

    Ive added
    world:addResponse(name, function)
    and seems like it works perfectly, but stuck with this "project" function :disappointed:
  • hgy29hgy29 Maintainer
    Yep, just looking at the code I can say there is something wrong in the lua binding of world:project() call. I'll fix that
  • rrraptorrrraptor Member
    edited September 10
    @hgy29
    So, I kinda fixed "project" function, and now it works.

    But there is a problem.

    The implementation is very simple. Response struct:
    struct UserResponse : Response {
        int functionIndex;
        lua_State* _L;
        UserResponse(lua_State* L, int index)
        {
            _L = L;
            luaL_checktype(_L, index, LUA_TFUNCTION);
            functionIndex = luaL_ref(_L, LUA_REGISTRYINDEX);
        }
     
        void ComputeResponse(World*, Collision &col, double x,
                double y, double w, double h, double goalX, double goalY,
                ColFilter*, double &actualX, double &actualY,std::vector<Collision> &cols) {
     
            lua_rawgeti(_L, LUA_REGISTRYINDEX, functionIndex); // get callback_function
            lua_pushvalue(_L, 1); // world instance, g_pushInstance(_L, "BumpWorld", world) does not work for whatever reason...
     
    		pushCollisionData(_L, col); // creates "col" table
    		// add item, other, type, response keys to it
            lua_getfield(_L, -2, "__itemsr");
            lua_rawgeti(_L, -1, col.item);   
            lua_setfield(_L, -3, "item");    
            lua_rawgeti(_L, -1, col.other);  
            lua_setfield(_L, -3, "other");   
            lua_pop(_L, 1);
            lua_pushstring(_L, col.type);
            lua_setfield(_L, -2, "type");
            if ((!strcmp(col.type, "bounce")) || (!strcmp(col.type, "slide"))) {
                lua_newtable(_L);
                lua_pushnumber(_L, col.response.x);
                lua_setfield(_L, -2, "x");
                lua_pushnumber(_L, col.response.y);
                lua_setfield(_L, -2, "y");
                lua_setfield(_L, -2, "response");
            }
            lua_pushnumber(_L, x);
            lua_pushnumber(_L, y);
            lua_pushnumber(_L, w);
            lua_pushnumber(_L, h);
            lua_pushnumber(_L, goalX);
            lua_pushnumber(_L, goalY);
            lua_pushvalue(_L, -11); // MAYBE a filter function, but I have no idea what is that
            lua_call(_L, 9, 3); // call callback, which must return 3 values: x, y, collisions list
     
            actualX = luaL_checknumber(_L, -3);
            actualY = luaL_checknumber(_L, -2);
            luaL_checktype(_L, -1, LUA_TTABLE);
            int size = luaL_getn(_L, -1);
     
    		// loop throught a table at -1, add collisions to cols vector
    		// its just too big to post here )))
        }
     
        ~UserResponse()
        {
            luaL_unref(_L, LUA_REGISTRYINDEX, functionIndex);
        }
    };


    LUA function
    static int worldAddResponse(lua_State *L)
    {
        World *w = (World *) g_getInstance(L, "BumpWorld", 1);
        const char* name = luaL_checkstring(L, 2);
        UserResponse* data = new UserResponse(L, 3);
        w->addResponse(name, data);
        return 0;
    }


    Now the problem is that your response function must look like that:
    function oneWay(world, col, x,y,w,h, goalX, goalY, filter)
        ...
        return x, y, {}
    end
    But I have no idea how to pass filter function to callback function... So I have to manualy pass it:


    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • if there is Timer.pauseAll then there should be a Timer.pause too, no?
    at least i guess timer:stop() resets the timer so that when it is again started it will wait delay time before it triggers the callback. while if we pause it then it should not reset the timer and if we are halfway between two triggers then after resuming it should only wait half the time until the next trigger.

  • hgy29hgy29 Maintainer
    keszegh said:

    if there is Timer.pauseAll then there should be a Timer.pause too, no?

    Well, there is already. I wonder why it isn't documented as it seems to be present in Gideros since a long time.

    Likes: keszegh, E1e5en

    +1 -1 (+2 / -0 )Share on Facebook
  • well I tried it in latest gideros and Timer.pause() doesn't work while Timer:pause() works.
    local pix = Pixel.new(0x00FFaa, 1, 64, 64)
    pix:setAnchorPoint(0.5, 0.5)
    pix:setPosition(128, 128)
    stage:addChild(pix)
     
    local timer = Timer.new(24, 360)
     
    function onTimer(e)
    	pix:setRotation(pix:getRotation() + 0.5)
    	if pix:getRotation() > 90 then
    --		timer.pauseAll()
    --		timer.pause()
    		timer:pause()
    	end
    end
     
    timer:addEventListener(Event.TIMER, onTimer, timer)
    timer:start()
    https://wiki.gideros.rocks/index.php/Timer:pause

    Likes: E1e5en

    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    rrraptor said:
    Which ones are you thinking about ? I guess we can add more but remember that they should have their counterpart in all back ends (Metal and DX too)
  • rrraptorrrraptor Member
    edited September 21
    hgy29 said:

    rrraptor said:
    Which ones are you thinking about ? I guess we can add more but remember that they should have their counterpart in all back ends (Metal and DX too)
    GL_RGBA16F/GL_RGBA32F/GL_RGB16F/GL_RGB32F
    I guess should not be a problem?

    https://docs.microsoft.com/en-us/windows/win32/api/dxgiformat/ne-dxgiformat-dxgi_format
    https://developer.apple.com/documentation/metal/mtlpixelformat
  • keszeghkeszegh Member
    edited September 21
    @hgy29 , i have an issue with wacom tablets (yet again), so far i did not use the pen button in my gui so i did not notice but now in my imgui-based gui i need it. i'm using windows, i'm not sure if this issue is present on mac or not.

    the issue: usually pen button behaves like right-click and that's what i'd want too. but there is a problem. basically there are two ways the tablet can work, which can be set in the wacom driver app:
    1. 'use windows ink' - in this case i have pressure sensitivity but both pen buttons register as a left-click, not good
    2. do not 'use windows ink' - in this case pen button is registered as a right-click, yet pressure sensitivity info is lost, the event when i draw with the pen is registered by gideros as a regular mouse event, not good

    so in both versions something is not working. is it possible to correct that?
    thanks a lot

    btw @rrraptor , in any of the above cases imgui does not seem toget pen pressure info (in the demo window input part)
  • hgy29hgy29 Maintainer
    @keszegh, on which platform is that on windows ? win32 or Qt ?
  • hgy29 said:

    @keszegh, on which platform is that on windows ? win32 or Qt ?

    qt.
  • hgy29hgy29 Maintainer
    Ok, I think I have an idea: it looks like the table touch event has a button field on Qt, but that field isn't used and button is always reported as 0. @keszegh, just to be sure: tablet events are reported as 'none-click' currently, not even left-click, right ?
  • rrraptorrrraptor Member
    edited September 23
    keszegh said:

    btw @rrraptor , in any of the above cases imgui does not seem toget pen pressure info (in the demo window input part)

    ImGui itself dont have any stylus/pen support. The input system works like this:
    io.MouseDown[MouseButtonIndex] = true;
    ...
    io.KeysDown[KeyCode] = true;
    ...
    io.KeyAlt = true;
  • hgy29 said:

    Ok, I think I have an idea: it looks like the table touch event has a button field on Qt, but that field isn't used and button is always reported as 0. @keszegh, just to be sure: tablet events are reported as 'none-click' currently, not even left-click, right ?

    which tablet event? drawing or pressing a button? so far iam not sure what to answer, i think in my previous post ive written what pen drawing and pen buttons do in both settings.
  • hgy29hgy29 Maintainer
    edited September 23
    Yes, but you said pen events were reported as left or right click depending on the case, while they should have been reported as neither left nor right click according to code (button field set to 0) unless they are seen as mouse events from the OS point of view
  • hgy29 said:

    Yes, but you said pen events were reported as left or right click depending on the case, while they should have been reported as neither left nor right click according to code (button field set to 0) unless they are seen as mouse events from the OS point of view

    i will make more elaborate test results and share it here as soon as i can.
  • keszeghkeszegh Member
    edited September 23
    @hgy29 , so here are my test results. the code is the following:
    function onTouch(event)
    	  print(event)
    end
     
    stage:addEventListener(Event.TOUCHES_BEGIN, onTouch,nil)
    the results are the following (notice also that one touch creates two events when windows ink is on (the only way to get pen pressure in gideros at this point), that's a thing i keep bringing up in the hope that it can be corrected too, as now i need to make workarounds to 'notice' this):

    CASE 1 - use windows ink DISABLED:

    pen touches tablet:
    {__target = {__events = {}, __userdata = "userdata: 031E0308"}, __uniqueid = 311, __userdata = "userdata: 031E347C", allTouches = {{id = 1, modifiers = 0, mouseButton = 1, pressure = 0, rx = 451, ry = 199, type = "mouse", x = 451, y = 199}}, touch = nil, touches = {nil}, type = "touchesBegin"}

    pen button pressed:
    {__target = {__events = {}, __userdata = "userdata: 031E0308"}, __uniqueid = 2336, __userdata = "userdata: 031E347C", allTouches = {{id = 1, modifiers = 0, mouseButton = 2, pressure = 0, rx = 528, ry = 241, type = "mouse", x = 528, y = 241}}, touch = nil, touches = {nil}, type = "touchesBegin"}

    CASE 2 - use windows ink ENABLED:

    pen touches tablet:
    {__target = {__events = {}, __userdata = "userdata: 0329A308"}, __uniqueid = 550, __userdata = "userdata: 0329D47C", allTouches = {{id = 1, modifiers = 0, mouseButton = 0, pressure = 0.2626953125, rx = 494, ry = 245, type = "penTablet", x = 494, y = 245}}, touch = nil, touches = {nil}, type = "touchesBegin"}
    {__target = {__events = {}, __userdata = "userdata: 0329A308"}, __uniqueid = 1734, __userdata = "userdata: 0329D47C", allTouches = {{id = 1, modifiers = 0, mouseButton = 1, pressure = 0, rx = 494, ry = 245, type = "mouse", x = 494, y = 245}}, touch = nil, touches = {nil}, type = "touchesBegin"}


    pen button pressed:
    {__target = {__events = {}, __userdata = "userdata: 017DD308"}, __uniqueid = 225, __userdata = "userdata: 017E047C", allTouches = {{id = 1, modifiers = 0, mouseButton = 0, pressure = 0, rx = 429, ry = 312, type = "penTablet", x = 429, y = 312}}, touch = nil, touches = {nil}, type = "touchesBegin"}
    {__target = {__events = {}, __userdata = "userdata: 017DD308"}, __uniqueid = 228, __userdata = "userdata: 017E047C", allTouches = {{id = 1, modifiers = 0, mouseButton = 1, pressure = 0, rx = 429, ry = 312, type = "mouse", x = 429, y = 312}}, touch = nil, touches = {nil}, type = "touchesBegin"}


    i hope this helps.
  • hgy29hgy29 Maintainer
    Yes, so the interesting mode is windows ink enabled, where pen events are reported as such (type=penTablet). Notice that the two events you get in this case are of different types, and they are emitted by the OS, not by Gideros, so this isn’t something that can be fixed at Gideros side. I suppose we could disregard pen events, but that’s what you are interested in.
    So what you need is that the mouseButton field of the pen event have a correct value, not 0, right ?
  • keszeghkeszegh Member
    edited September 24
    hgy29 said:


    So what you need is that the mouseButton field of the pen event have a correct value, not 0, right ?

    yes, when the pen button is pressed. that would do. gideros and also imgui should recognise it as a right click.
  • hgy29hgy29 Maintainer
    About the duplicate event, it looks like it is actually a QT bug: https://bugreports.qt.io/browse/QTBUG-47910, and some devs implement a workaround for that using proximity events: https://stackoverflow.com/questions/31172532/mousepressevent-of-qwidget-gets-called-even-though-qtabletevent-was-accepted

    I can implement the same trick in gideros
  • @hgy29 , that sounds great (i guess also exposing proximity event in the api can be useful).
    the right-click issue seems independent though, right?
  • hgy29hgy29 Maintainer
    Yes, the right-click thing seems to be completely out of the scope of QT or Gideros. From QT point of view, it is just a mouse click.
Sign In or Register to comment.