Gideros 2026.9 release and forum migration

hgy29

Hello everyone,

Two announces in one this time. The first is yet another update of Gideros, with improved support for 3D. Code path for 4x4 matrices and 3D bone animation support has been improved and is now roughly 2x faster. In the future, I'll keep on improving the 3D rendering pipeline. I am convinced that Gideros should be perfectly able to handle 3D worlds.

The second announce is about the forum. We still use today a Vanilla forum v3.3, which relies on php 7.4, which itself is deprecated and probably unsafe. Unfortunately vanilla forum development is now dead, and I have only two choices for an easy migration: Discourse and Flarum. For technical reasons (docker mainly), I'd rather stay away from Discourse, which leaves only one choice: Flarum.

I don't exactly when I will have time to migrate, but this should be done before the end of the year. When this happen, expect some functionality to break. Flarum may be better for some things, and not so good for others. Hopefully we'll get used to it over time.

Gideros 2026.9 Full change list:

Improvements
[general] Speed improvement for 3D computations
[cryptography] Faster unb64 function
[Library/3D] Use improved Gideros functions, imporve GLTF support
[general] Move Key codes for arrow keys outisde of ascii range
[export/ios] Update minimum target to iOS15

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

MoKaLux

Thank you captain 🌸

Flarum looks pretty good 👍.

FYI this is the "fix" for the problem I have on win32 export (minimizing the app window crash) 🙂:

--local ttf = TTFont.new("fonts/Cabin-Italic-TTF.ttf", 64) -- this crashes Gideros local ttf = TTFont.new("fonts/Cabin-Italic-TTF.ttf", 64, "") -- this works fine :-) local tf = TextField.new(ttf, "hello Gideros!") tf:setPosition(4*32, 4*32) stage:addChild(tf)

Viva Gideros, viva captain hgy29 🎉

MoKaLux

hello captain, please check this PR https://github.com/gideros/gideros/pull/578

It seems there are other logs that show in the console which shouldn't. Removing this one as a starter would be great for version 2026.9.1 😋.

For example this one: "*AudioBinder::Sound_create* stack NOT ok begin:1 end:4 delta:1" but I can't find it in the repo yet 🤷‍♂️.

EDIT: I think I found it in gideros\2dsg\gstatus.cpp
#ifndef _WIN32
#define _snprintf snprintf
#endif
I believe I need to comment all the lines containing
-vsnprintf(buffer, 1024, s_errors[errorCode].errorString, args);
-_snprintf(buffer, 1024, s_errors[errorCode].errorString, arg1);

But I am not too sure , can I do it and commit?

EDIT2: this log is funny though:
Warning: Real sample count differs from given gapless sample count. Frankenstein stream?
gideros\libgid\external\mpg123-1.15.3\src\libmpg123\frame.c
FYI: this means Stream consists of carelessly stitched together files (the leading one featuring gapless info).

MoKaLux

I am starting to change some things:

// wprintf(L"szCmdLine=%ls\n",szCmdLine); glog_d("szCmdLine=%ls\n",szCmdLine);

So one could change only one flag in libgid\src\glog.cpp

#ifdef WINSTORE #include string #include Windows.h std::wstring utf8_ws(const char *str); #endif   #ifdef _WIN32 // XXX #include string #include Windows.h std::wstring utf8_ws(const char *str); #endif   #include stdarg.h #include stdio.h   //static int s_level = GLOG_DEBUG; static int s_level = GLOG_ERROR; // XXX   ...   #elif defined(WINSTORE) std::wstring wsTmp=utf8_ws(buffer); OutputDebugString(wsTmp.c_str()); #elif defined(_WIN32) // XXX I dont know what to put in this statement // std::wstring wsTmp=utf8_ws(buffer); // no good here // OutputDebugString(wsTmp.c_str()); // no good here #else printf("%s\n", buffer); #endif

Is this the way to go? 🤔
EDIT: PR done 😋

hgy29

MoKaLux said:

FYI this is the "fix" for the problem I have on win32 export (minimizing the app window crash) 🙂:

Found it: it was caused by the window size being 0, leading to infinite logical scale values and in turn Gideros trying to allocate wrong buffer sizes.

troysandal

Thanks for the new release. I just upgraded to Gideros 2026.9 on macOS 27.0.1 (Golden Gate) and tried to build the Birds Example project for iOS Simulator but hit two snags in Xcode 27.

Bug #1 -
I get the following error. UIAcceleromter was dropped in the min bump to iOS 15 I believe so ginput-ios.o needs to be rebuilt. I worked around this by adding a stub UIAccelerometer implementation for now.

Undefined symbols for architecture arm64: "_OBJC_CLASS_$_UIAccelerometer", referenced from: in libgideros.a[arm64][273](ginput-ios.o) ld: symbol(s) not found for architecture arm64 /Gid2026-9-Birds/Bird Animation/Bird Animation.xcodeproj: Bird Animation iOS: clang++: error: linker command failed with exit code 1 (use -v to see invocation)

Bug #2 -
Can't build for any simulator because libdigeros.a is built only for iOS (not desktop arm64 simulator). The fix is to add arm64 to Excluded Architectures -> Any iOS Simulator. That got the build to succeed but when I try to run it it tells me libgideros.a only has x86-64 in it, no desktop arm code. Any chance we can get libgideros.a to include desktop arm64? Or should we assume we should just switch to working directly on our devices?

troysandal

Next issue - I can't get Gideros Studio to connect to my player that's running on my phone. macOS 27, XCode 27, iOS 27. I've done all the usual things, turned off the Firewall, allowed both Studio and Player to accept network connections, turned off cellular on the phone. Perhaps I'm hitting an issue with iOS 27/XCode 27 and the new virtual tunnel XCode makes to the phone.

I'm still working on it but if anyone else has fixed this let me know.

hgy29

Yes, I feared that would happen. My Mac is too old to support Xcode 27, so I couldn't really test. Thanks for pointing out though.

troysandal

hgy29 said:

Yes, I feared that would happen. My Mac is too old to support Xcode 27, so I couldn't really test. Thanks for pointing out though.

As my mother would say, merde! How can I help figure this out? I've worked a small amount with the Gideros source, perhaps if you give me some tips me and my AI bots will dig in to find a fix? Actually, my first thought is, it could be entitlements. Before I dig into any source, I'll keep trying to get the iOS Player build itself to work. I noticed when I export a project to iOS there's a chg folder that have PlayerMetal-Info.plist that has a ton more settings than my own player app. If that doesn't work, I'll see if building for iOS 26 SDK fixes it.

Let me know if you have other ideas.

troysandal

I just opened a PR that fixes the UIAccelerometer issue on XCode 27. I've tested it on an actual phone and built it using XCode 26 on macOS 15.6, just to make sure.

I am also working on getting iOS arm64 simulator support working. At this point I do not have a PR but I do have Gideros apps that use no plugins building and running in iOS arm64 simulators. With Xcode 27 dropping x86_64 simulators (in theory they work but I cannot get them running) this is going to be critical for us macOS 27 users. My fix moves from single .a libraries to XCFrameworks that have per platform .a files. It's a much more involved change, I'll let you know when the PR is up.