[core] No drawing on macOS Mojave until window is moved

[alexander-matz]

Drawing does not work on macOS mojave until the window is moved.
Pixel seems to have similar issues (documented here), so I suspect maybe glfw might be the ultimate culprit here?

Interestingly enough, using luaJIT + FFI and loading the shared library does not result in this behavior.
Linking against shared vs static does not change anything in C, however.
Below is a minimal example that works in lua (the raylib library is a shoddy pure-FFI binding that just loads the shared library and copies raylib.h, no initialization or anything happens). The equivalent code in C does not draw until the window is moved.

local ffi = require('ffi')
local rl = require('raylib')

local function main()
  rl.InitWindow(800, 450, "luatest")
  rl.SetTargetFPS(60)
  while (not rl.WindowShouldClose()) do
    rl.BeginDrawing()
    rl.ClearBackground(rl.BLACK);
    rl.DrawFPS(20, 20);
    rl.EndDrawing()
  end
  rl.CloseWindow()
end

main()

Any ideas on workarounds or fixes for this?

[raysan5]

Hi @alexander-matz, a workaround for this issue was added in commit 1fe6d9f by @a3f.

By the way, are you using raylib-lua binding, I was porting it to raylib 2.0 but it was not ready yet...

[alexander-matz]

Hey @raysan5 , that was quick, thanks!
Looks like I wasn't exercising due diligence and should have tried a more recent build...

I'm not using raylib-lua, since I'm using luajit anyways and can avoid building another .so by using the pure-ffi binding. My binding is an ffi-cdef containing a verbatim copy of the function prototypes and an (almost verbatim) copy of the defines to declare all constants as variables. It's straight up ignoring build time parameters but worked for me to jump start Raylib development within 5 minutes or so (without even requiring a compiler if you download a binary release). Here's a gist if you're interested: https://gist.github.com/alexander-matz/f8ee4eb9fdf676203d70c1e5e329a6ec

Feel free to do with that whatever you like and thanks for the great library you're building!

[raysan5]

Hey @alexander-matz! Excuse my ignorance, I didn't know about the pure-ffi binding on LuaJIT, it's amazing!

Maintaining raylib-lua binding could be quite cumbersome, tried to create a raylib-parser but there are lots of special cases... What are the downsides of using the pure-ffi alternative? All structs are supported directly? How are data pointers managed by ffi?

Many thanks for sharing your raylib-lua-ffi gist!

[alexander-matz]

The LuaJIT FFI is pretty impressive and probably the closest to a "JustWorksTM" FFI I've seen in a scripting Language. Regarding your questions:

• Yes, structs are supported directly, if the function expects a Vector3, then a lua table with three elements is implicitly translated
• Data pointers can be created from C-structs using either the new function in the FFI library, which are garbage collected and can be associated with a finalizer. Example: local buf = ffi.new("uint8_t[?]", n), buf acts like a lua table with n elements that can be directly accessed and is garbge collected automatically.
• Additionally, native functions can of course return pointers to structures they have allocated. In this case, the pointer is garbage collected, but not the object pointed to. Automatic garbage collection for the pointed to object can be achieved by associating an appropriate finalizer with the pointer (example: local p = ffi.gc(ffi.C.malloc(n), ffi.C.free), when all references to the value behind p are garbage collected, the finalizer ffi.C.free is called on it, freeing the allocation)
• Not a question, but something worth noting: The syntax used to declare prototypes does not support a preprocessor, so all #defines and uses of Macros have to be removed

When it comes to downsides of using the LuaJIT FFI, the main issue is that you're locked into using LuaJIT. Whether that's a problem is up to the individual but this is my take on it.

There's a couple of advantages coming with luaJIT:

• It's FAST, with an incremental garbage collector, making it an okay choice for applications with real-timey requirements
• The FFI is FAST, when the jitter kicks in, native functions calls are essentially free of overhead
• Embedding LuaJIT into an application is about the same effort as embedding the reference implementation

But it also comes with it's downsides:

• It's a one man project and nobody seems willing, able, or allowed to take it up. Whatever the reason, it seems to be more in maintenance mode than in active development.
• It's Lua 5.1 sprinkled with a small selection of more recent features. So for modern lua projects, backporting might be required.

So there's no clear answer. The most worrying part is the (surprising) lack of outside contributions to the project, which makes me wonder how long it will be maintained. For the moment being, I like to use it as a crutch to quickly get a feel for a new library.

If you're interested in the binding, you or I can put it up online and I try my best to maintain it.
Right now it's very crude.
It doesn't really follow Lua idioms (e.g. it should use strings to pass constants), doesn't adjust the XBox gamepad axis for the RPi.

[yago-gt]

Does this work with raylib 2.5? I can't get to display any text with custom fonts

[raysan5]

@yago-gt you should try with latest raylib from github master branch.

[yago-gt]

@raysan5 That's what I tried but I get a segmentation fault error when running a Lua version of the "text_raylib_fonts.c" example, it works fine if I compile with gcc and I tried a couple of other examples in Lua before and it worked ok. The line that seems to be causing the error is rl.DrawTextEx(font, message, position, font.baseSize*2, spacing, color)
Luajit recognize the font as a cdata and the framework prints "Image file loaded correctly as Font", so I don't know.