Include aarch64 darwin in the jar?

[ezntek]

I need compatibility for aarch64 macOS for my project for a school assignment, is there a way that you can add that?

[ezntek]

saw the readme note

[electronstudio]

I've added it to the 4.5 release, but it's completely untested.

[ezntek]

there's some crazy glitches regarding raygui, especially with GuiWindowBox. Any container widget in fact, it all jumps raound to random parts of the screen, sometimes to half the screen height minus half the height of the widget, sometimes to (0, 0), and sometimes far outside the screen.

with my custom 4.2.0 build, it is just ridiculously crashy. Random memory allocation errors such as with Metal, OpenGL or the objective-C to C interop layer (malloc) happen. Havent tested custom 4.5.0 builds yet.

[ezntek]

UPDATE: the same memory related crashes still happen,

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000018ae1b7e0, pid=37224, tid=259
#
# JRE version: OpenJDK Runtime Environment Homebrew (17.0.9) (build 17.0.9+0)
# Java VM: OpenJDK 64-Bit Server VM Homebrew (17.0.9+0, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# C  [libobjc.A.dylib+0x77e0]  objc_retain+0x10
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/easontek/Sources/beanmaths/client/app/hs_err_pid37224.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/Homebrew/homebrew-core/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

The code is open source at ezntek/beanmaths (repo beanmaths under my username), and I am running BytePointer.deallocate()'s manually, or else nasty invalid pointer or double free or use after free errors arise from javacpp.

here's some funky glitches with windowbox rendering and generally cursed behavior:

The background is supposed to be raylib's DARKGRAY with opacity set to 100, but it appears red. freak glitch.

THis is the windowbox failing to render.

[electronstudio]

Does this happen on other platforms or just macOS arm64?

Is my 4.5.0-0 build worse than your 4.2 build?

[ezntek]

the memory related crashes do happen on other platforms (namely linux amd64, im using gentoo with a relatively normal system config), and i havent tested the 4.5.0-0 build on my gentoo box yet.

however, there are zero graphics crashes with the 4.2.0 version, yet there are many many graphics bugs in 4.5.0.

Is it possible for you to also update raygui up to 4.0 for compatibility with tools like rguistyler and rguilayout? i had to manually refactor to get it to work with the older bundled raylib 3.6.

[electronstudio]

It sounds like it’s either:

• Bug in javacpp
• Bug in your code, I.e. you aren’t understanding how javacpp does something (which to be fair is very complicated, I don’t understand it all, interfacing a memory managed language to a non memory managed language is difficult)
• Bug in Raygui, I.e. crashes would happen the same if you wrote the program in C.

I wasn’t sure that Raygui 4.0 was compatible with Raylib 4.5. Yes I can update to that if it is.

[ezntek]

raygui 4.0 did get released with raylib 4.5 if i remember correctly, so it should work.

I'm not sure if it is my code, i have a complex hiearchy of managing when objects are being rendered or not and function calls that manages manual instantiation and deallocation of BytePointers (any TypePointer from javacpp really). i'll still check if its an error on my end, but for now, it is a god knows what is happening situation.

These crashes are completely random, too, the exact same input sequence can sometimes crash or not crash.

[electronstudio]

Try disabling Java GC with JVM command line options

-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

And try disabling your own deallocation code.

[ezntek]

i've decided to give up on this project and rewrite it in another language, but i can say that its a tad more stable with those options on and the deinit code disabled.

[electronstudio]

If you want to use Java then Swing, JavaFX and Jetpack Compose are all far superior GUI libraries than RayGUI and they don’t require any C memory management (which seems to be the issue here).

[ezntek]

Yes, but my project's main focus is actually graphics with raylib, and raygui was only an afterthought.

Since I have no more requests, I'm closing this issue.