glshim


I've been building FreeOrion for my Raspberry Pi 2 and it's been slow. I think I need to build all of boost still.
 
Last edited by a moderator:
I'm still compiling it...
I'd never have guessed...


Is it even possible without huge amounts of swap and a whole day to spare? Those 15.04 ubuntu binaries are not usable on pandora I take it?
It's possible, with swap and a whole day indeed. Ubuntu wil be hardfloat, so not compatible with Pandora.

I have seen a lot a python also, so I'm a bit concerned about performance too.
 
It's possible, with swap and a whole day indeed. Ubuntu wil be hardfloat, so not compatible with Pandora.

I have seen a lot a python also, so I'm a bit concerned about performance too.
Unless you've already used up yours I'd recommend a free trial of google compute engine which you could use to set up a fast cross-compiler available for 2 months.

EDIT:

Congratulations guys, either version of your graces' glshim can handle Naev perfectly!

http://forum.odroid.com/viewtopic.php?f=91&t=16201
 
Last edited by a moderator:
It's possible, with swap and a whole day indeed. Ubuntu wil be hardfloat, so not compatible with Pandora.

I have seen a lot a python also, so I'm a bit concerned about performance too.
Unless you've already used up yours I'd recommend a free trial of google compute engine which you could use to set up a fast cross-compiler available for 2 months.
I have made my fork of glshim more multiplatform friendly. It should now compile and run "out-of-the-box" on the ODroid with "cmake . -DODROID=1"

If you can test and repport.
 
I have made my fork of glshim more multiplatform friendly. It should now compile and run "out-of-the-box" on the ODroid with "cmake . -DODROID=1"

If you can test and repport.
Yes, it builds and works fine.

BTW, C1 is rather low-end - should the same functions be disabled on other odroids, including the new XU4?

Thanks; I'm mainly interested in FOSS projects - could a filter be added along the lines "no additional data packs required"?
 
Last edited by a moderator:
Which reminds me I've also tested ToME 1.3.1:

http://forum.odroid.com/viewtopic.php?f=91&t=16039

The issues mentioned in your repo wiki are gone (or not applicable on Odroid) but all's not sweet. I've managed to find a serious glitch visible in the attached screenshot (all 2d elements are gone). I'm attaching the save in case you wanted to have a look at what the level's supposed to look like on x86 (should go into .t-engine/4.0/tome/save).

tome.jpg 

testsave.zip
 

Attachments

  • testsave.zip
    533.1 KB · Views: 168
Last edited by a moderator:
I have made my fork of glshim more multiplatform friendly. It should now compile and run "out-of-the-box" on the ODroid with "cmake . -DODROID=1"

If you can test and repport.
Sure, any test case suggestions? I'll edit this part later to let you know.

BTW, C1 is rather low-end - should the same functions be disabled on other odroids, including the new XU4?
It is temporary, until I code a proper way to detect GLES capability at load time.

Thanks; I'm mainly interested in FOSS projects - could a filter be added along the lines "no additional data packs required"?
I don't think so.

Which reminds me I've also tested ToME 1.3.1:

http://forum.odroid.com/viewtopic.php?f=91&t=16039

The issues mentioned in your repo wiki are gone (or not applicable on Odroid) but all's not sweet. I've managed to find a serious glitch visible in the attached screenshot (all 2d elements are gone). I'm attaching the save in case you wanted to have a look at what the level's supposed to look like on x86 (should go into .t-engine/4.0/tome/save).

View attachment 12167 

testsave.zip

I am not the owner of this port, and I must confess I never tried this game, so I don't know. I'll try to make a compile to work on glitch you found.
 
 
Thanks; I'm mainly interested in FOSS projects - could a filter be added along the lines "no additional data packs required"?

I don't think so.
Hopefully we didn't have a misunderstanding - I was referring to the search engine you linked to (it already has a commercial games filter) and not glshim itself!
 
Last edited by a moderator:
 
Thanks; I'm mainly interested in FOSS projects - could a filter be added along the lines "no additional data packs required"?

I don't think so.
Hopefully we didn't have a misunderstanding - I was referring to the search engine you linked to (it already has a commercial games filter) and not glshim itself!
Yes, me too. The "additional data" flags doesn't exist to my knowledge (there is nothing like that in the PXML file that you create when creating a PND and that is then used by the repo).
 
So, I finally got FreeOrion to run on the Pandora.
This one is a beast to compile! Really.
I succeed to barely compile natively, but memory issue and compiling time is huge (4Go swap, and sometime it get killed, and days to compile).

So, I reluctantly built a Cross-compile environment, higly experimental, using codeblocks.pnd as base for all arm libs and a Linux Mint x64 VM.. After hours of messing, compiling and patching binutils & GCC, I finaly got something. Once transfered to the Pandora, it works! Yeepi.

Now, The game seems a bit slow (it needs lot of memory and CPU power it seems), and there seems to be missing thing using glshim as reported. I have now to try fix that.

 

preview2.png

preview3.png

preview4.png
 
Last edited by a moderator:
You mean (judging by that last screenshot) all problems are gone? The research screen as well?

Well done, I think I might donate!
 
Last edited by a moderator:
You mean (judging by that last screenshot) all problems are gone? The research screen as well?

Well done, I think I might donate!

Yes, I think I have fixed all the rendering issue. I pushed my changes to the github repo, so it's ready to try.

(You can donate to the Pyra development pool)
 
Judging by that UI, this might be perfect for TinyGLES.
 
Last edited by a moderator:
Judging by that UI, this might be perfect for TinyGLES.

It will be interesting to see how it stacks up against the poorly performing Mali driver.
 

Yes, I think I have fixed all the rendering issue. I pushed my changes to the github repo, so it's ready to try.

(You can donate to the Pyra development pool)

As for FO it's become perfectly playable indeed. One easily remedied performance issue is related to the game itself and SD write performance (triggered by frequent uncompressed autosaves).

Now, the glshim itself has experienced a regression, noticable in foobillardplus (see attachments, after and before)


BTW, the forum link on your github homepage is broken (recent changes here?)


 

Foo_after.jpg

Foo_before.jpg
 
Last edited by a moderator:
FoobillardPlus was running? Last time I tried it was not working well for me (worse than the broken screenshot). I'm surprised, the regression came with just my last commit for FO?
 
FoobillardPlus was running? Last time I tried it was not working well for me (worse than the broken screenshot). I'm surprised, the regression came with just my last commit for FO?

On my Odroid C1? Yes and yes.

EDIT:
Oh, the broken link was meant to lead here...
 
Last edited by a moderator:
Back
Top