Adventures of Yddar - adventure game demo released

Hello OF people,
didn’t know if selfpromoting someone’s own projects, even if done in OF, is suitable for the forum, but since @mkrebs started the thread about KoS, tagged as examples, I guess there’s nothing wrong about it to do a similar thing…

So, I’m giving to your attention the game I made for AdventureJam2020 DISTANCE - -

Adventures of Yddar, made with OF - Adventures of Yddar demo,
2 Windows versions available for download:
1.) classic version built in OF v.11.0, using msys2 compile flag -march=i686 instead of -march=native to make compatibility with all 32bit windows systems,
2.) legacy build (code copied and built in OF v.0.7.3) for compatibility with older systems like Windows XP…

Linux: built in Fedora 31, doesn’t run out of the box, it would require making a static build for linux to not require all the OF dependencies installed prior to that…

Mac/OS X: There’s currently no Mac version; because I don’t own a Mac, I can’t make an OS X release…

Development took place from April 21st to May 5th, and voting time is until June 5th.
The game is my old concept since 2012 from the times of old versions of OF - 0.7.2 and 0.7.3.

The music in the game is courtesy of Emitremmus, who allowed me to use his music for free -, featuring his album [](Nuclearization - Voyage In The Post Atomic Unknown)

The game is only a demo, since 2 weeks were the limit for any significant development,
but rest assured, after the voting ends, there’s more where this came from…


P.S. I kinda feel guilty about not mentioning the OF developer team in the credits, but definitely plan to amend it in full version of the game.
Thanks a lot to the OF Community and all OF developers/contributors to OF first and foremost!!!
Would have a hard time producing something C++ based like this without this great toolkit. :wink:


Beautiful Game @mr.Bitmap :slight_smile: An adventure game!!! Gonna have loads of fun with this !! Congratulations on making it! So nice to see libof.a properly making game programs. It’s hard enough to make a game, even harder to distribute, and why is linux support not first and foremost?

Unfortunately your game doesn’t run out of the box on any linux system. Under wine is ok, but who needs wine these dayes, short time, that’s why we use other systems like Godot run out of the box anywhere, not so close to the hardware, but hey.

This would be sweet to have:

Anyone knows if this is working?

Looking at your binary, how to fix from ldd linkage?

Everything appears to be there, except from libboost and libglew. I’m sure fixing these to point somewhere, game will run natively.

ldd ./AdventuresOfYddar-demo 
./AdventuresOfYddar-demo: /usr/lib/x86_64-linux-gnu/ version `GLIBCXX_3.4.26' not found (required by ./AdventuresOfYddar-demo)
./AdventuresOfYddar-demo: /lib/x86_64-linux-gnu/ version `GLIBC_2.29' not found (required by ./AdventuresOfYddar-demo) (0x00007ffec230b000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd90936000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd9069d000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd90428000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd900ed000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8fea8000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8fbf4000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8f97b000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8f6dc000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8f45d000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8f240000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8f024000) => not found => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8ed98000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8ea7b000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8e827000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8e510000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8e2b1000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8df79000) => /lib/x86_64-linux-gnu/ (0x00007fbd8dd5a000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8daaa000) => not found => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8d88f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8d506000) => /lib/x86_64-linux-gnu/ (0x00007fbd8d168000) => /lib/x86_64-linux-gnu/ (0x00007fbd8cf50000) => /lib/x86_64-linux-gnu/ (0x00007fbd8cb5f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8c8e3000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8c6df000) => /lib/x86_64-linux-gnu/ (0x00007fbd8c4d7000) => /lib/x86_64-linux-gnu/ (0x00007fbd8c2d3000) => /lib/x86_64-linux-gnu/ (0x00007fbd8c0a1000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8be6f000) => /lib/x86_64-linux-gnu/ (0x00007fbd8bc52000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8b9db000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8b7d2000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8b5a7000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8b2fe000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8b0ee000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8aec9000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8acac000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8aa90000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8a882000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8a5f5000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8a12a000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd89edf000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd89c8d000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd89a7f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd89874000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd89671000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8946b000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd89261000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8905c000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd88d55000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd88b0e000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd888dd000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd88627000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd88382000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8817f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd87f57000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd87d4a000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd87b40000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8792e000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd87726000) => /lib/x86_64-linux-gnu/ (0x00007fbd874b4000)
	/lib64/ (0x00007fbd90b45000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd87294000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8702c000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd86dd6000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd86b03000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8688c000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd86682000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd86419000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd85f55000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd85d12000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd85af4000) => /lib/x86_64-linux-gnu/ (0x00007fbd858df000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd85561000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd851fb000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd84fc7000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd84d91000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd84b10000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8483a000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd84608000) => /lib/x86_64-linux-gnu/ (0x00007fbd84404000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd841f9000) => /lib/x86_64-linux-gnu/ (0x00007fbd83fde000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd83dc3000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd83b82000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8397c000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8372c000) => /usr/lib/x86_64-linux-gnu/pulseaudio/ (0x00007fbd834ae000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd832aa000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd830a4000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd82e70000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd82c18000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd829e9000) => /lib/x86_64-linux-gnu/ (0x00007fbd827c3000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd825b5000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd823ae000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd8207f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd81e6c000) => /lib/x86_64-linux-gnu/ (0x00007fbd81c68000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd81a5f000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd817d2000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd81530000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd812fa000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd810e4000) => /lib/x86_64-linux-gnu/ (0x00007fbd80e97000) => /lib/x86_64-linux-gnu/ (0x00007fbd80c13000) => /lib/x86_64-linux-gnu/ (0x00007fbd80a09000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd80803000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd805da000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd803cb000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd80181000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd7fe78000) => /lib/x86_64-linux-gnu/ (0x00007fbd7fc40000) => /usr/lib/x86_64-linux-gnu/ (0x00007fbd7fa24000) => /lib/x86_64-linux-gnu/ (0x00007fbd7f708000) => /lib/x86_64-linux-gnu/ (0x00007fbd7f4ee000) => /lib/x86_64-linux-gnu/ (0x00007fbd7f2d9000)

Good luck with your game! You must be proud to actually producing a release.


1 Like

Thanks, if I could manage to make Linux builds (I currently have a Fedora as a secondary system, but also would build from Debian to make it compatible with Debian/Ubuntu), it would be a great addition…

Same for Mac. Cousin own a Mac and actively uses OF, but I don’t know whether if you build a project on Mac, will it run out-of-the-box for any Mac? Does it not involve doing some specific operations like it is with Linux?

Did you try AppImages? Last time I had 5mins to spare, tried and failed, might be a good option, but nothing like proper static code that runs 32+64bits any unix system. Here are some pointers, does it work with your code?

For OSX.7, should be a breeze, apps built under this system work on any mac, no probs, it’s the last Mac Machine at the studio, not sure if Xcode nowadays can run on it, most likely not, and you need to codesign binaries, hence a costly annual Apple Developer programmer license.

How did you do it on Windows? Cross compile from linux? Haha, last time we tried, no machine on the studio could support Windows IX, stuck on some XP machine.

Are you doing mobile as well?

1 Like

I am dual-booting Fedora 31 and Windows 10 64bit. I code natively in Linux, cos Unix-based/Unix-like system is better for developement. Once I finish the code, build and run it successfully in Fedora, I copy the project to my Windows system and use Msys2 to make a Windows build from console - as following the tutorial to msys2 on OF main page, using MINGW32… See “Running examples” step here:

Now, I got reports from people that it wasn’t working for them and the OF app couldn’t run. Didn’t know what was the problem until we worked it out with a member from GameJolt to whom I tried to send some other of my compiled stuff in older OF versions… stuff made in v.0.7.3 worked for him, but more recent stuff from versions 0.10.0 opened the console window, but not the App GL window - in the console, he got some exception code, which he googled up as “not built for his CPU”, so by this troubleshooting we have come into conclusion that I need to change makefile flags in msys2 config (OFpath\libs\openFrameworksCompiled\project\msys2 - . So I made a change

# Architecture / Machine Flags (
ifeq ($(shell gcc -march=native -S -o /dev/null -xc /dev/null 2> /dev/null; echo $$?),0)
	#PLATFORM_CFLAGS += -march=native
	PLATFORM_CFLAGS += -march=i686
	PLATFORM_CFLAGS += -mtune=native

by commenting out -march=native (which should mean, built for your native system where you built your app), and adding -march=i686, which should support all 32bit Windows systems.
Eureka! It worked thereafter… (of course, you must not forget to copy all the dlls required :wink: )

Now, there’s this Linux version to resolve, either by AppImage or static build without it? Idk, pretty much relatively new to Linux myself, though not a complete beginner…
So as I see from your list of .so in my demo, these .so files are not sufficient themselves, I guess?
(I’m using nothing else than pure OF with only ofxXmlSettings as the only addon in my game, nothing more, nothing less…)
And, what’s more, aren’t these .so files only compatible with Fedora Linux or its distro family (Red Hat/CentOS) if the build was made in common linux distro? I guess they wouldn’t work with Ubuntu/Debian or something Arch-based, would they?

Nope, not at this time. Haven’t tried to build anything for Android/iOS from OF. It requires setting it up properly to work. Moreover, I’d have to make changes in the code to support mobile interactivity, like touch events etc.
I have Android SDK installed though, cos I tried to build one game example from Godot engine (there are native export options for it, so it forced me to install Android SDK), and it worked quite nicely, so I might try to give it a shot to configure and build OF projects for Android some time as well…

Any 32+64bit unix system you say? :open_mouth: Yum-yumee! I’d definitely want to be able to make such builds… I’ll have to look at these…

Haaaa. Thanks so much! Last time I learned oF in a workshop by @as1er msys was working on the build machine, but not portable, even with the dozens of required dlls in the bin folder, did not work on another machine, This is very good news, thanks for sharing!

Same here, need to know basis;) .AppImage is portable, but it’s not static core proper unix voodoo apps that run everywhere, like imagemagick, for example. Do chime in if you get .AppImages to run though, would be a nice step.

The .so’s with memory addresses are already pointing to the right binaries under my system, the problematic ones on ldd are the ones not found. There is some voodoo magic you can apply, in order to point those linked .so’s in the binary, and make it work on any system.

We had this problem shipping 577Rhea from a game jam, you can find the jam build here: (if you check these linux builds, you will find the same issues – amazing how 7 years already went by, and the issue persists) Another one for Temporary-Babel2D

But if you point the missing/not found .so’s to the right place, it will run out of the box. I just can’t remember how to do that. Perhaps @as1er already knows?

I think they would, if they are pointed to the right place. Main one is the C library. Then your binary is missing something of libboost, something of libglew.

You will need a separate Android Sdk for oF, it doesnt support more recent ones, that you need for Godot, other than that, Android in oF, atm, is very nice, very small binaries, compared to years ago, code cleaner, addon, very nice. But very very nice would be a very smaller footprint oF that could ship to Android OS 4, iOS 5. This would make small but clever programs to be able to run on those systems. But alas…

Err… Build a 32bits version that can run on any 32+64 system :wink: Or perhaps you can glue together 32+64 bins. But I guess oF does not support that anymore. App stores the same. Everyone keeps pushing new incompatible changes, very non-eco friendly.

1 Like

I have a custom oF post 10 running on a 32bit debian based system.

ldd repair guide would be a nice addition.

Haa, 577Rhea & TemporaryBabel2D :wink: But if kids school strike for climate, shouldn’t devs app store strike for the planet?

Code strike for the planet

I have been building cross-platform apps and games to distribute on Windows, MacOS, Android and iOS.

Android was tricky finding the right versions and settings to be able to build and especially to codesign working aps which can be put on the Google Play Store.

MacOS and iOS were less technically difficult but more administratively difficult, because Apple has set up a very large number of baroque imaginative and/or just frustrating hoops to deploy to their latest platforms. But I have managed to do so. Actually porting OF apps to be able to work on MacOS and iOS was extremely easy. Getting them authorized was weeks of head-banging, needing to buy a new Mac, etc etc etc etc etc etc etc etc, etc etc etc… just to overcome Apple’s obstacles.

1 Like

Chiming in :slight_smile: and with good news. I’ve added AppImage Linux 64-bit version to download from my game site:

This needs to be tied to the thread where we were discussing problems concerning AppImages -

In short, to make successful .AppImage build, you have to make .AppDir as per instructions (there are many guidelines about this on the internet, or simply extract some AppImage and look into the contents) and:

  1. have your compiled build in the Linux OS with the lowest possible GLIBC version. For me, it’s currently Ubuntu 16.04 Xenial Xerus (GLIBC version 2.23) as virtual machine. Linux distros with older GLIBC versions cannot run an AppImage that was built in newer GLIBC.

  2. copy all dependencies your OF app uses (using ldd) - these have to be in lib folder inside .AppDir’s usr/lib

  3. exclude (delete) system dependencies from these copied ldd inside .AppDir’s usr/lib, as having these would interfere with target user’s linux system libraries, making the AppImage crash with segmentation fault - here’s the list of libs that should NEVER be included in an AppImage:

  4. when everything’s met, we may run appimagetool on ourOFproject.AppDir and it will render ourOFproject.AppImage out of it.

Enjoy! :wink:

1 Like