Anyone for Pi?
Monkey Archive Forums/Monkey Tutorials/Anyone for Pi?
| ||
Just got trans built (and building) on the Raspberry Pi, which is rather cool! I'm running a Debian distro (think there's only the one) which already has the dev tools installed...  Here's the trans C++ source with build instructions: http://www.hi-toro.com/monkey/pi/trans_linux.zip Takes ages to build (probably 5-10 minutes), and building Monkey programs from the resulting trans_linux isn't quick either... and of course Chromium on the Pi runs HTML5 apps very slowly, but it's still cool to see. Need GLFW target now, for accelerated OpenGL! EDIT: The above archive contains the trans C++ code and mini-tutorial but I thought I should post the tutorial text here too: On the Pi, shut down any 'large' programs, eg. web browser and open a terminal. In fact, I'd recommend making a note of the steps and doing this from the initial Pi login terminal before even running the desktop environment... 1) Extract the above archive and cd to the src/ folder; 2) Copy and paste this: g++ trans_linux.cpp -o trans_linux 3) Go make a cup of tea... and tidy the house... and maybe get some shopping done. Maybe mow the lawn? 4) Extract MonkeyPro somewhere on Pi. 5) Place the generated trans_linux binary from step 2 into MonkeyPro/bin folder. 6) Open up MonkeyPro/bin/config.linux.txt in a text editor and add this line: HTML_PLAYER="chromium_browser" 7) cd into a bananas/ example folder, eg. cd ~/Desktop/MonkeyPro58/bananas/hitoro/matrixrocks 8) Build! As we're in a bananas sub-folder, we need the full path to trans: ~/Desktop/MonkeyPro58/bin/trans_linux -target=html5 matrixrocks.monkey 9) Run HTML5-capable web browser and open resulting MonkeyGame.html from build/ folder. 10) Marvel at the glacial gameplay! Or upload the html5 build somewhere and play from a PC... |
| ||
| If I had more time.... I had a RasPi Thank you for sharing! |
| ||
| Nice! Mine is arriving next week. looking forward to trying this out. |
| ||
| @DruggedBunny can you not use the RasPi Virtual Machine to build this quicker? Then just run the final binaries on the thing itself. Not as nerdy as building on the RasPi itself, but nerdy in another way by using virtualisation... |
| ||
| Hi Matt, That's true (haven't tried the VM so far), though I did get trans to build much quicker by doing it from the initial terminal (ie. before running the desktop environment), maybe about 3-4 minutes in total, but once it's built you're done until the next release. My next attempt at building a Monkey project for HTML5 also went much quicker, maybe 10-20 seconds, so it's not too bad. Tried to get GLFW to work using fsoft's patch (thread seems to have vanished from here -- see Google cache link below) but got loads of 'missing declaration' errors! http://webcache.googleusercontent.com/search?q=cache:nccuwk9JJ6IJ:www.monkeycoder.co.nz/Community/posts.php%3Ftopic%3D2260+Anyone+tried+to+compile+GLFW+for+Linux%3F&cd=1&hl=en&ct=clnk&gl=uk&client=ubuntu |
| ||
| Have you installed all the necessary development packages, e.g. libgl1-mesa-dev ? |
| ||
| Good point, though I'm not sure what exactly I need to install, so will have to look into it... EDIT: A little out of my depth with this! If anyone else can step in and explain what needs to be done to build the GLFW target for a generic PC Linux, that would really help! The Pi only has hardware acceleration support for OpenGL ES 2.x, not general OpenGL, though I know we can specify this in the build options... [CORRECTION: Pi supports accelerated OpenGL ES 1.1 and 2.0 at present. 'Full' OpenGL is not supported.] (Also, I just added the tutorial contents of my zip archive to my first post as this shouldn't really have been posted as a 'tutorial' without it.) |
| ||
| Hmm, looking at the error log again, I think it simply can't find the GLFW/OpenAL includes, though they're part of the Monkey install. I suspect mardrag is right, so will try installing any missing dev packages later today. In the meantime, this is what I'm getting -- sound right? Building... In file included from main.cpp:2: main.h:31:21: error: GL/glfw.h: No such file or directory main.h:34:16: error: al.h: No such file or directory main.h:35:17: error: alc.h: No such file or directory ... [tons of GLFW-related "not declared in this scope" errors] TRANS FAILED: TRANS Failed to execute 'g++ -Wall -g main.cpp -o linux/MonkeyGame -I /usr/include/AL -I stb -lGL -lopenal -lglfw -DDebug', return code=256 |
| ||
| @DruggedBunny: Do the following files exist on your system? /usr/include/AL/al.h /usr/include/AL/alc.h /usr/include/GL/glfw.h If not, try apt-get install libopenal-dev libglfw-dev Or create symlinks to the real positions of the files. If the include-files can be found at the right paths then the "not declared in this scope" messages should disappear. On my Ubuntu-Laptop I had the the same errors with fsofts "GLFW for Linux" target, but after installing some development packages they disappeared. Now everything runs flawlessly. I think on Raspberry Pi's Debian distribution this should work the same way. I couldn't test it because I'm still on the waiting list for a Raspberry Pi. |
| ||
| Thanks, mardrag, that was the build problem. I also needed libgl1-mesa-dev and (I think) libglu1-mesa-dev. I can now build an executable and get only two (I believe) harmless warnings in the process. I also had to modify CONFIG.TXT to use OpenGL ES 2.0. On running the exe, I had to turn the sound system on (type "modprobe snd-bcm2835" in a terminal) as that caused loads of errors -- sound is off by default in the Debian distro as the driver is in alpha state. It now opens a window (or full-screen display, depending on settings), but then crashes stating that "Rendering operations can only be performed inside OnRender". This appears to be from graphics.monkey -> DebugRenderDevice (), suggesting the render device isn't available. I believe the 3D driver is available but that you have to access it a certain way, in that you can't directly use X to create a surface: http://benosteen.wordpress.com/2012/04/27/using-opengl-es-2-0-on-the-raspberry-pi-without-x-windows/ I imagine that for us, GLFW would need to be modified to open the display according to the above post. I don't think there's much needed to work around it, but I had a look through GLFW and I'm definitely not competent enough to figure it out! Done for tonight... |
| ||
| OK, contrary to what I said previously, quite a lot is probably needed to get this going, and it'll take someone with far more talent than I possess! Here are just a few bits and pieces I've gathered along the way -- information seems rather scarce on Pi and OpenGL ES so far -- that may help someone more competent to get started. · The Pi does support hardware-accelerated OpenGL ES 1.1 -- I thought it only supported 2.0, but the official simple GL demos provided use 1.1, run very well (ie. they're clearly accelerated) and Broadcom confirm this anyway. · mojo's GLES20 support only applies to Android and 'raw' OpenGL, not mojo-GLFW. (GLFW doesn't yet implement it, though it seems to be planned/partial.) So... no point trying to build any /bananas and ignore my above comment regarding enabling GLES20! · The hello triangle example is easy to follow, but I thought I'd highlight that in order to enable hardware acceleration you must include the Pi's "bcm_host.h" and call "bcm_host_init()" -- not that I've done this (apart from building and running the samples), but it seems others dabbling with GLES have run into this. BTW My other more general top tip for anyone who starts playing with the Pi is to access its desktop via VNC on a main PC rather than directly, as freeing it up from rendering the standard 1080p display seems to speed things up (the desktop is still unaccelerated); note, though, that you will have to switch to the real display to run any accelerated 3D samples. After installing tightvnc, you start it from a terminal with: tightvncserver (The first time it runs it will prompt you to set some login details.) ... then run a VNC session with: vncserver -geometry 1024x768 -depth 32 Modify the geometry and depth values as you see fit, then, assuming the default settings, connect to x.x.x.x::5901 (note double colons) from your PC (eg. using TightVNC), where x.x.x.x is the Pi's IP address. (Get this on the Pi by running ifconfig from a terminal.) Final observation: although the Pi feels slow right now, I think this is mostly due to having to render the 1080p desktop via the CPU; the OpenGLES samples show that it can run full-screen 3D smoothly, and the early port of Quake III runs quite well (until you add CPU-hogging bots -- me and my brother played it with me on PC and him on the Pi for a good hour or two). Once the desktop uses the GPU to render I think it'll all feel much quicker. (Anyone else got one on order, or a delivery date?) |
| ||
| Yeah, I have one ordered and I can see it taking at least a month to come but I am looking forward to having a play with it. Nice tip on the VNC BTW. |
| ||
| Well, it seems GLFW does in fact work, but it's unaccelerated and so very slow indeed. I think I may have just had the CPU/GPU memory split too low on the GPU side before, but I can build and run GLFW stuff now. I did try to hack in the bcm_host_init() call, eventually getting it to build (adding various options/include paths to the G++ call), but it was still unaccelerated. I believe it probably has to be set up as in the init_ogl call here, using EGL, which would mean hacking GLFW's window/context stuff, which is just too scary for me. |
| ||
| Confirmed tonight that you have to use the 'hello_triangle' bcm/egl/dispman setup code to get an accelerated display, and it can only be accelerated in full-screen mode. (Apparently once X is hardware-accelerated, windowed stuff will be more do-able.) The bcm/egl/dispman code itself looks easy enough, but as far as I can see, someone smarter than me will have to hack the bcm/egl context/window stuff into GLFW's context/window creation in order for mojo to work (obviously as an unofficial modification, but that isn't a problem if you're just modifying a copy on the Pi itself). |
| ||
| Hi @DruggedBunny. Any idea how this is coming along? I've had two RPi's for a while now and though one is used as an XBMC unit, the other one is on 24/7, runs Raspbian and is used remotely while at work for general SSH, IRC, etc, while at home I use the full desktop on it. I'd be dead keen to build some monkey games for the Pi (instead of resorting to using Python), and I'd prefer building on my Win7 PC of possible, then just copy across the build (or write a script to copy the folder across or something) to run the test fullscreen on the Pi. Any ideas for a noob like me on how to set Monkey up and the files I need on the Pi to make this work? I did recently (with lots of help from @dawlane) get Monkey running and compiling on my macbook running Ubuntu 13.04 if that helps. :) |
| ||
| Sorry, Sensei, I only saw this post while replying to this one! See that post for all I know -- as far as I can see, Monkey won't really be any use on the Pi until GLFW 3 is implemented, which is in Mark's roadmap. (I'm assuming GLFW still plans to support the Pi, or does already... I think GLFW 3 is actually out but haven't looked into it!) The first post at the top of this thread is all I know about building 'trans' for the Pi, but it was over a year ago, so not sure if it'll still work with the latest Monkey. If GLFW 3 support appears, and runs accelerated on the Pi, I'll be all over it! |
| ||
| Yeah so true. I'd be happy to cross compile and execute like you do frompc to ouya, just in this case to the Pi. |
| ||
| Soooo... Anyone tried the Pi in the last few months with the latest Monkey builds to see if anything has improved since these threads were started? Too late tonight, but I have an idea for an app for the Pi which doesn't need hardware accellerated graphics, so even if it only gets 5fps or less, it should be fine; I'd like to test build using stdcpp but since it doesn't support mojo, what other solutions are there at this point in time? |
| ||
| OK, Monkey X is running now. Click here |
| ||
| Raspberry pi 2 got quadcore with 1GB Ram and it should run well thought! |
| ||
| Its alreayd on my wishlist :) I will see if I can grab one soon. |
| ||
| Hey guys, Man, this has been an insane rollercoaster of scouring the threads on this forum and trying everything I could google and think of and installing all the libraries and files people mentioned. Last thing I tried was from this thread by Pharmhaus: http://www.monkey-x.com/Community/posts.php?topic=8666 Running MonkeyXPro82b. Ted works fine. ./transcc_linux (as downloaded per above thread) works and reports: TRANS monkey compiler V1.71 TRANS Usage: transcc [-update] [-build] [-run] [-clean] [-config=...] [-target=...] [-cfgfile=...] [-modpath=...] <main_monkey_source_file> Valid targets: C++_Tool Desktop_Game_(Glfw3) Desktop_Game_Glfw2 Html5_Game Valid configs: debug release When I try to GLFW2 build in Ted, I get this: "/home/pi/Downloads/MonkeyXPro82b/bin/transcc_linux" -target=Desktop_Game_Glfw2 -config=Debug -run "/home/pi/Downloads/MonkeyXPro82b/bananas/ferdi/snake/snake.monkey" TRANS monkey compiler V1.71 Parsing... Semanting... Translating... Building... g++ -Wno-free-nonheap-object -Wno-deprecated-declarations -Wno-free-nonheap-object -Wno-unused-result -D_GLFW_HAS_GLXGETPROCADDRESS -D_GLFW_USE_LINUX_JOYSTICKS -pthread -I../glfw/include -I../glfw/include/GL -I../glfw/lib -I../glfw/lib/x11 -I../openal/include -I../stb -c -o build/debug/main.o ../main.cpp g++ -o Debug/MonkeyGame build/debug/enable.o build/debug/fullscreen.o build/debug/glext.o build/debug/image.o build/debug/init.o build/debug/input.o build/debug/joystick.o build/debug/stream.o build/debug/tga.o build/debug/thread.o build/debug/time.o build/debug/window.o build/debug/x11_enable.o build/debug/x11_fullscreen.o build/debug/x11_glext.o build/debug/x11_init.o build/debug/x11_joystick.o build/debug/x11_thread.o build/debug/x11_time.o build/debug/x11_window.o build/debug/x11_keysym2unicode.o build/debug/stb_image.o build/debug/stb_vorbis.o build/debug/main.o -lGL -lopenal -lX11 -lpthread /usr/bin/ld: build/debug/x11_time.o: undefined reference to symbol 'clock_gettime@@...' Makefile:43: recipe for target 'Debug/MonkeyGame' failed //lib/arm-linux-gnueabihf/librt.so.1: error adding symbols: DSO missing from command line TRANS FAILED: Error executing 'make CCOPTS="-Wno-free-nonheap-object" OUT="Debug/MonkeyGame"', return code=512 collect2: ld returned 1 exit status make: *** [Debug/MonkeyGame] Error 1 Done. I've looked into this DSO missing issue but I'm not having any luck figuring this one out! Any ideas from you linux gurus? |
| ||
| Open the MakeFile in the templates and add -lrt to LDFLAGS. Some Linux distributions merged librt into glibc sometime ago. Note as you have tried to build you will also have to add this to the MakeFile in the build directory. Edit: That should be LDLIBS not LDFLAGS. But it shouldn't matter. |
| ||
| Never mind, Dawlane answered first. |
| ||
| It worked! Woot, thanks guys! Running all of this on the Pi2 is considerably better than the Pi1 :) Now let's see if my game works... and if I can get the thing to build fullscreen? EDIT: Ok nevermind, I was being daft. Just added: #GLFW_WINDOW_FULLSCREEN = True to the bananas I tried to build and they go full screen fine. (but the framerate remains terrible) :( Not sure this is going to be a doable solution due to the slow speed.. What a disappointment. Saying that, perhaps I could still build small tools for the Pi.. Good news is: my game runs! The bad news is: I get 1FPS, in a window and 0.5FPS full screen :( Still, it's something to see your creation running on the humble Pi :) |
| ||
| Is there a way to make monkey-x utilise hardware openGL? If my understanding is correct, that must be the reason the framerate is slow. When I try compile using GLFW3 I get:
gcc -Wno-free-nonheap-object -Wno-int-to-pointer-cast -Wno-free-nonheap-object -Wno-unused-result -I../glfw3/include -I../openal/include -I../stb -D_GLFW_HAS_GLXGETPROCADDRESS -pthread -c -o build/Debug/context.o ../glfw3/src/context.c
In file included from ../glfw3/src/internal.h:74:0,
from ../glfw3/src/context.c:28:
../glfw3/src/x11_platform.h:37:33: fatal error: X11/Xcursor/Xcursor.h: No such file or directory
compilation terminated.
Makefile:56: recipe for target 'build/Debug/context.o' failed
TRANS FAILED: Error executing 'make CCOPTS="-Wno-free-nonheap-object" OUT="Debug/MonkeyGame"', return code=512
make: *** [build/Debug/context.o] Error 1
|
| ||
| The Pi only has OpenGL ES (not full-fat OpenGL), but my understanding was that GLFW3 would be adding this support... I got bored waiting and checking, so no idea if it works on Pi with acceleration yet! |
| ||
| Does this example (WebGL) run on the Pi using a linux browser? |
| ||
| fatal error: X11/Xcursor/Xcursor.h: No such file or directory You will need a few additional development libraries. The updated HOW TO: Install Monkey on Linux (a rough guide) will list the additional dependencies. As for GPU acceleration, I would check out the Raspberry PI forums. |
| ||
| @Danillo: Thanks for those examples. I tried both the WebGL and Canvas versions in both Epiphany and Chromium on my Pi2, and the Canvas versions worked at about 5fps on Epiphany and nothing at all on Chromium :) Well I guess that means using Monkey-X for ANY kind of game dev is out the window then hoho. Game dev tools are still an option though! |
| ||
| Hi! Has anyone tried monkey with the "experimental OpenGL" driver that was released in february? |
   |