I am not sure if it's because the shim isn't working properly or if it actually loads the GPU that much.Oolite is a sedimentary rock made up of ooids (ooliths) that are cemented together. compiling on to see how far it gets now.Įdit 3: Got it running with glshim, but I am only getting about 0.5-1 FPS. Js compiled fine, but the compile chocked because of some nonsense in OOCPUInfo.h.
Oolite forum Patch#
I've applied the patch to oolite's js source and compiling now to see how it goes.Įdit: To avoid spamming I'll just add this as an edit.
So yeah, spidermonkey compiles fine with gentoo's patch. No need to mess around with CFLAGS either. gs-3.patch ) then running autoconf and configure again fixed everything. When compiling, I got exactly the same errors as Davespice described. To eliminate the possibility of the build failing because of something the oolite folks have done to spidermonkey, I have downloaded plain js-1.8.5. I’ll now list all the steps I have taken to get to this stage if anyone wants to try themselves, any help would be greatly greatly appreciated. assembler/assembler/ARMAssembler.h: In member function "void JSC::ARMAssembler::fdivd_r(int, int, int, JSC::ARMAssembler::Condition)": assembler/assembler/ARMAssembler.h:546:28: error: "JSpew_Insns" is not a member of "js" assembler/assembler/ARMAssembler.h:546:13: error: "JaegerSpew" is not a member of "js" assembler/assembler/ARMAssembler.h: In member function "void JSC::ARMAssembler::fnegd_r(int, int, JSC::ARMAssembler::Condition)": assembler/assembler/ARMAssembler.h:537:28: error: "JSpew_Insns" is not a member of "js" assembler/assembler/ARMAssembler.h:537:13: error: "JaegerSpew" is not a member of "js" assembler/assembler/ARMAssembler.h: In member function "void JSC::ARMAssembler::faddd_r(int, int, int, JSC::ARMAssembler::Condition)": assembler/assembler/ARMAssembler.h:528:28: error: "JSpew_Insns" is not a member of "js" assembler/assembler/ARMAssembler.h:528:13: error: "JaegerSpew" is not a member of "js" assembler/assembler/ARMAssembler.h: In member function "void JSC::ARMAssembler::fcpyd_r(int, int, JSC::ARMAssembler::Condition)": So I’ve probably not done this correctly.Ĭode: Select all. However then I got loads of build errors from the spidermonkey source itself (see below). I edited the libjs.make file (in the root Oolite trunk folder) and added the CFLAGS line to the LIBJS_CONFIG_GLAGS global variable and that allowed the configure stage to complete successfully. I have had a go at trying to find the correct place to put it myself. The building of spidermonkey is part of the overall build script for Oolite so, ideally, it would be good if I could put these in the correct place for the entire build process. The gentleman who posted mentions some makefile settings and I am unfortunately not 100% sure where to put these. So I then spent a whole afternoon Google whacking and came up with this page. Make: Leaving directory `/home/pi/Oolite-dev/trunk' noĬonfigure: error: Your compiler does not follow the C++ specification for temporary object destruction order. noĬhecking for correct temporary object destruction order. yesĬhecking whether C++ compiler has -pedantic long long bug. yesĬhecking whether C compiler supports -fprofile-generate. yesĬhecking for valid optimization flags. usr/bin/nspr-configĬhecking for NSPR - version >= 4.7.0. yesĬhecking for _attribute_((warn_unused_result)). One of the dependencies is spidermonkey which, it seems, doesn’t like being built on ARM.įirst problem I had was that I couldn’t get it past the configure stage, with the error Your compiler does not follow the C++ specification for temporary object destruction orderĬode: Select all checking for _attribute_((always_inline)). I have got as far as checking out the trunk and trying to get the dependencies to build. So I would like to enlist some help from the clever people who browse these forums, if you have the time.
The Oolite developers are unable to help me here because they have too much work going on themselves with getting the next version of the game done. I would like to get to the stage where I can build it on a Pi itself and start seeing the build errors that result from not having standard Open GL.
Oolite forum code#
I am trying to evaluate how much work it would be to port the graphics engine from standard Open GL to Open GL ES, I have had a look around in their SVN and the code does look quite well compartmentalised. The issue might be memory footprint but we’ll see. I also think the Raspberry Pi probably has enough grunt to run it at a decent frame rate.
Oolite forum full#
This is very full featured game which had enormous scope for user modification and creation of content. Ladies and gents, I’m sure the Elite fans among you will be aware of the open source game Oolite (object oriented elite).
0 kommentar(er)
