In a few words : 32bit = past, 64bit = the future 
I haven’t enough time to setup a 32bit Ubuntu installation on my computer, setup the development environment, recompile, test and bundle a 32bit version each time I want to release a new GD version
Note that on Windows 32bit and 64bits are both supported because I can create a single executable that is compatible with both.
In this case you should also mention on your indiegogo page what do you mean exactly under “improved Ubuntu version”.
I thought the only problem with Ubuntu version is that, it 64bit only. What need to be improved then if not missing 32bit support?
I guess you don’t want to pay for somebody to compile some 32bit version a few times so what is all about “Ubuntu version improvement”?..
Anyway, as long as Ubuntu 64bit is not get preinstalled by manufacturers on their PC’s, Laptops, 32bit the future as 90% of Linux users, use Linux on old PC’'s with less than 2GB RAM and I mean end-users and as main and only OS. By the end of the day the target of GD is the end-users which is, in case of Windows 64bit, true, this is the future but in case of Ubuntu and any Linux based system, 32bit for now.
Many distros pushing 64bit mainly because of Steam. “Yay we have Steam, we are AAA gaming platform now yupee!”, but this is not quite relevant yet. There are some good games for Linux, and there are some more on the way, but none of them would require a 64bit OS.
Seriously, if you want to make 64bit version only, stop the development of the Linux version for now, and spend your resources on Windows and HTML5 instead, (especially on HTML5) and once a 64bit only version going to make sense in the future, you going to have a lot more polished and improved version to continue with. If you don’t have the necessary resources, you have to make a decision, but the decision you are about to make, is only waste of resources in my opinion as the majority of end-users are using 32bit Linux system.
If you use Ubuntu as your main system on your dev machine, ok I can understand, you have to use 64bit and you don’t want to work with two versions, but if you are using Windows as your main OS, Ubuntu mainly to compile and test GD, in that case, no reason to not install only a 32bit version and keep GD as 32bit only for now, really no point and make no sense to develop a 64bit only Linux game at the moment.
The Ubuntu version is still not polished (graphical glitchs, freezes… I’ve received again a bug report for a not working window on Ubuntu today on the french forum) because I can’t test it properly using my virtual machine and so the improved Ubuntu version means that I’ll be able switch from Windows as the primary OS for GD development to Ubuntu (or at least switch more often between the OS to make test, as for now I have to use a virtual machine which is veerry sloooooow! And it’s not praticable to do full time development on it).
I do not agree with your point of view about the future usage of the 64bit flavor of Ubuntu. All computers bought today have a 64bit CPU and when you download Ubuntu from the offical website, 64bit is the default choice. Clearly, in a few years there won’t be any 32bit computer remaining except for some really old computers.
Feel free to send me statistics. But for example, it’s not the case for steam users: gamingonlinux.com/articles/s … stics.1965
There is a reason: Again, 32bit executables won’t run on the latest 64bit version of Ubuntu.
In the past, executables compiled on Ubuntu 32bit were able to run on Ubuntu 64bit using some compatibilities libraries. These libraries were deleted in Ubuntu 13.04 (not sure about the exact version) and I wasn’t able to run anymore the Game Develop executable on Ubuntu 64bit. 
So I decided to switch the build to support the 64bit flavor. I know I’ll be critized for about a year or so about it but I won’t change it (except if there is an unbelievable amount of people asking for it, but it’s not the case): I know it’s a pity for people using 32bit Ubuntu on old computers, but I can’t say to all people with 64bit computers on Ubuntu that they won’t be able to use GD. (I remember when I compiled GD on Ubuntu 32bit, there was tons of messages about compiling errors on the 64bits version).
Again, I know you can feel bitter about this lack of support for the 32bit version, but you can’t reproach me targeting the flavor that will be or is already the most used.
Hi all,
Just my 2 cents.
I’ll try to confirm about 32bit apps not running on current 64bit Ubuntu, but according to their forums, it should be possible, the method has just changed to install support:
askubuntu.com/questions/359156/h … -of-ubuntu
Brief summary. The ia32-libs has been replaced with a new debian method, multiarch, that only requires an architecture install.
Also, now that GD is open source, I presume we can compile our own 32bit?
A side note, even though I have a decent powered notebook that can support 64bit, for nostalgic reasons I like to run with 32bit for the time being
Cheers
Yes, Game Develop is open source so we can even make a 32 bits version and a 64 bits version.
I am looking forward to someone writing a build script for arch linux and posting it on the AUR repository. 
The one that is currently there simply downloads the ubuntu deb file and converts it.
Gamedevelop seams to be interesting, good idea.
I am also on a 32 bits version and on Ubuntu 12.04, which is very old ! I prefer to wait before installing 13.04 because there are sometimes problems with printers, when you upgrade Linux. For example, I could have installed Ubuntu 12.04 - 64 bits but my printer didn’t like it (no driver) !
I work in a place where I teach computer to beginners on Xubuntu (very light, OK for our old computers) and Ubuntu 12.04. We receive also teenagers who would like to create games, so Gamedevelop interests me a lot.
An HTML5 version would be the best way for everybody to use it, if it’s possible to create one.
By the way, where is the french forum ? The interface of this one is in french but you write on english here.
Here’s french forum: viewforum.php?f=3
Anyway, there is web version of Game Develop, called GDevelop, if it is what you have in mind.
Otherwise, since GD is open source now, you may try to download sources and compile for 32bits yourself. Yes, there is no “official” 32 bit version for Linux, but there are sources 
(it uses common Linux build tools like cmake, by the way).
Compilation GD 3.4.72 on Ubuntu 14.04 64-bit (not the package!)
[code]git clone GitHub - 4ian/GDevelop: GDevelop is an open-source, cross-platform game engine designed to be used by everyone.
sudo apt-get install libopenal-dev libjpeg-dev libglew-dev libudev-dev libxrandr-dev libsndfile1-dev libglu1-mesa-dev
sudo apt-get install libgtk-3-dev libwebkitgtk-3.0-dev[/code]
download wxWidgets-3.0.1.tar.bz2 from wxwidgets.org/downloads/
download compilgames.net/code/GameDev … _1_55_0.7z
download sfml-dev.org/download/sfml/2 … ources.zip
(not works scene editor with SFML-2.1 )
move the files to a folder gd/ExtLibs and and extract them;
rename folders ‘boost_1_55_0’ to ‘boost’ and ‘SFML-2.0’ to ‘SFML’;
install wxWidgets:
cd ExtLibs/wxWidgets-3.0.1/
./configure --enable-ribbon --enable-webview
make
sudo make install
compile SFML:
cd ../ExtLibs/SFML
mkdir build-linux
cd build-linux
cmake ..
make
compile GD:
cd ../../../Binaries
mkdir .build
cd .build
cmake -G "Unix Makefiles" ../..
make
execute scripts:
cd ../../scripts
chmod 775 CopyWindowsToLinuxReleaseFiles.sh
sh CopyWindowsToLinuxReleaseFiles.sh
cd ../GDJS/scripts/
mkdir ../../Binaries/Output/Release_Linux/JsPlatform/Runtime
chmod 775 ./CopyRuntimeToGD.sh
./CopyRuntimeToGD.sh
cd ../../IDE/scripts/
mkdir ../../Binaries/Output/Release_Linux/CppPlatform/include
mkdir ../../Binaries/Output/Release_Linux/CppPlatform/include/boost
mkdir ../../Binaries/Output/Release_Linux/CppPlatform/include/SFML
chmod 775 UpdateHeadersAndPCHRelease.sh
./UpdateHeadersAndPCHRelease.sh
Run:
cd ../..Binaries/Output/Release_Linux/
./GDIDE
Thanks for the detailed message! For compiling the dependencies, I’ve setup a small script here: github.com/4ian/GD/blob/master/ … allDeps.sh
Yes, I’m working on this issue
Hello, and thanks to make a Linux version of Game Develop Linux really need some help to users can create some games. I am a OpenSuse user, but you do not have RPM packages for GDevelop in your site. Are you planning to make an RPM package version?
I’m working on making a PPA containing GDevelop for Ubuntu. If it works, someone could use the work I did to create the Ubuntu source package to create a RPM.
I know that OpenSuse offer a service to build packages: build.opensuse.org/
If I successed in making a source package and a PPA on Launchpad for Ubuntu, I’ll consider working on having a package on OpenSuse build service to have the software available for more distro.
But the best would be that someone having OpenSuse try to download, compile and package GD. Compiling is a matter of downloading the right package and launch CMake, it will be even easier in the next few days when I’ll push some modifications i’m making to GitHub (the compilation process will be easier as no external libraries will need to be manually compiled!)
Here we go ! 
Already downloaded openSUSE (great distro installer by the way). I’m currently building GD.
Here are the dependencies :
[code]Git : git
Compilateur : gcc-c++ (version 4.8)
CMake : cmake
Dépendances : p7zip
Dépendances SFML : libX11-devel, xorg-x11-devel, libudev-devel, glew-devel, libjpeg8-devel, openal-soft-devel, libsndfile-devel
wxWidgets : wxWidgets-3_0-devel (wxWidgets built with GTK+2) or wxGTK3-3_0-devel (GTK3+)
[/code]
The openSUSE wxWidgets version seems to have some problems with wxString conversion from/to std::string (need to make the conversion explicit to make it work). I’m working on the changes, will send a PR.
EDIT : openSUSE wxWidgets version is built using std containers, it needs a little change in GameDevelop_Editor_App.h (using an iterator on wxWindowList instead of Node ONLY if wxWidgets uses std containers).
Can’t you just build self-contained version in tgz archive? Sorta like “no installer” option for Windows (zip archive). I remember there was something like that somewhere in 2.x lifecycle and it worked well enough.
No because some libraries change froma distro to another. The main problem is also the compiler version : if we build that tar.gz package on Ubuntu, the libs will be built with g++ 4.9 : if you use it on a distro with another version of g++, native game will not be built correctly (different versions of g++ are binary incompatible)
Thought GD generates c++ code from events, then compiles it using clang…
No, it uses g++ and link the scene event code with GDCore and GDCpp libs which are already built
Can’t they be just build on the spot?
It’s take about 10 minutes to build them (and even more on Windows) and the GDevelop IDE need them itself (with the same compiler version also). That means that a full rebuild is mandatory.
IDE needs those for previewing game, right? So what I propose would be do what other software like this are doing. When previewing game, just build full executable then run it instead of doing it in editor.
This would also make for more useful testing, because game would run as it would after regular build and things that doesn’t work in Preview mode currently such as:
would work, which would make for more accurate previewing. There are two things that would need to be done differently though. First of all, scene which you are to preview would work as first scene in executable so after you ran you will get right to it instead of menu or whatever your first scene is.
Then there’s debugger. Here it would need to be compiled in into preview executable and to get into it some special keystroke that wouldn’t normally be used in game would be used. Best bet would be Ctrl+Alt+Shift+F12 - no sane person would use it in a game and it’s easy enough to press when you need to bring out debugger. Or attach a debugger to the app in similar way GDB does it.
Then since GD IDE wouldn’t need previewing, it could do full build of GDCpp/GDCore on the spot. And once it’ll be done, it could even cache it for future quicker builds unless linker errors (oops! g++ changed!) comes along, then it would do full rebuild again.